[Rd] A question on R memory management in .Fortran() calls under Windows
Dear R community,
I have a question on how R manages memory allocation in .Fortran()
calls under Windows.
In brief, apparently, it is not possible to allocate large matrices
inside a Fortran subroutine
unless you pass them as arguments. If you do not act in this way
RGUI crashes with a stack overflow error and acting on memory through
vsize nsize ppsize and memory.limit does not help at all.
Details of the configurations on which I performed testing follow:
R 2.1.1 on WinXP Pro SP2 ITA
PC1: AMD 64 3700+ 1GB RAM
PC2: AMD AthlonXP 2400+ 512Mb RAM
Compaq Visual Fortran pro 6.6C
To give an idea I attach a brief example on how to reproduce this:
Create two simple subroutines 'foo' and 'foobis' that, say, give the
sum of the elements of a matrix:
*** file foo.f90 starts
***
SUBROUTINE foo(X,M,N,S)
!DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'foo_' :: FOO
IMPLICIT NONE
integer:: M,N
real*8:: X(M,N),S
S = sum(X);
END SUBROUTINE foo
SUBROUTINE foobis(M,N,S)
!DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'foobis_' :: FOOBIS
IMPLICIT NONE
integer:: M,N
real*8:: X(M,N),S
X = 1;
S = sum(X);
END SUBROUTINE foobis
*** file foo.f90 ends
***
Notice that the matrix X is an input argument in foo and an internal
variable in foobis.
After compiling and linking turn to R:
**
> dyn.load("foo.dll");
> is.loaded(symbol.For("foo"));
[1] TRUE
> is.loaded(symbol.For("foobis"));
[1] TRUE
> M <- 10;
> N <- 10;
> X <- matrix(1,M,N);
> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S;
[1] 100
> .Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S;
[1] 100
## no problem here with small matrices, let's increase the size
> M <- 3000;
> N <- 100;
> X <- matrix(1,M,N);
> .Fortran("foo",X,as.integer(M),as.integer(N),S=as.double(0))$S;
[1] 3e+05 ## OK
.Fortran("foobis",as.integer(M),as.integer(N),S=as.double(0))$S;
## *** R GUI CRASHES WITH A STACK OVERFLOW ERROR ***
Any suggestion would be greatly appreciated, I apologize if this
problem has already been addressed previously, I did not notice it.
Many thanks in advance,
Simone
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098248 Fax: +39 051 232153
E-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A question on R memory management in .Fortran() calls under Windows
Dear Duncan and Simon, many thanks for your helpful reply. > Duncan Murdoch wrote: > It looks as though your Fortran compiler is allocating the new matrix on > the stack. R doesn't give you a huge stack, and that's causing the > overflow. When you get R to do the allocation, it does it on the heap, > which has no artificial limits. Only a pointer to the object ends up on > the stack. yes, CVF allocates automatic objects on the stack and apparently there is no way of changing it. By the way, increasing the stack of the fortran process when linking does not solve the problem > I'd say your only reasonable workarounds are to tell your compiler to > use the heap for the local matrix allocation (if that's possible), or do > your allocations in R. I might follow the second way, in any case, I am considering switching to Linux, I have also considered changing compiler under Win, any suggestions on the choice would be welcomed. Many thanks again, kind regards, Simone Giannerini __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A question on R memory management in .Fortran() calls under Windows
> I think it's far from the best optimizing compiler, but the Fortran that > comes with MinGW (g77 currently in Windows) is the one used to build R, > so it's the one that will is most likely to work with it without > fiddling. But I don't use Fortran, so I don't know what else is available. > > Duncan Murdoch > Thanks a lot anyway, in a comparative review I've come through recently (http://www.polyhedron.co.uk/compare.html) the Salford compiler seems to be one of the most protected against errors but also one of the slowest. Intel compiler seems to be one of the fastest but not the best on protection. Simone Giannerini __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A question on R memory management in .Fortran() calls under Windows
On 9/12/05, Simon Urbanek <[EMAIL PROTECTED]> wrote: > Simone, > > On Sep 12, 2005, at 4:30 AM, Simone Giannerini wrote: > > > yes, CVF allocates automatic objects on the stack and apparently > > there is no way of changing it. > > Yes, that's bad news. > > > By the way, increasing the stack of the fortran process when > > linking does not solve the problem > > In general the stack size is also governed by the system limits so > you may need to increase those as well, but still, that won't really > solve your problem. > > >> I'd say your only reasonable workarounds are to tell your compiler to > >> use the heap for the local matrix allocation (if that's possible), > >> or do > >> your allocations in R. > >> > > > > I might follow the second way, in any case, I am considering > > switching to Linux, I have also considered changing compiler under > > Win, any suggestions on the choice would be welcomed. > > As Duncan was mentioning g77 is your friend if you can convert your > code to f77. If you don't have that option, you're partially on your > own. GNU Fortran 95 (gfortran) may be an option as it exists both for > unix and Windows (although not as a part of MinGW), but R currently > doesn't provide .f90 target so you'll need to add your own small > Makevars. > > Cheers, > Simon > > Many thanks, I did not know about gfortran for Windows, I will have a look at it. Kind regards, Simone -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] numerical issues in chisq.test(simulate=TRUE) (PR#8224)
Hi, I obtain the same result under Win. XP SP2 on AMD 64 3700+ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major2 minor2.0 year 2005 month10 day 06 svn rev 35749 language R > m <- matrix(c(1,0,7,15),2,2) ; chisq.test(m, sim=TRUE)$p.value [1] 0.3598201 > m <- matrix(c(1,0,7,16),2,2) ; chisq.test(m, sim=TRUE)$p.value [1] 0.0004997501 > m <- matrix(c(1,0,7,17),2,2) ; chisq.test(m, sim=TRUE)$p.value [1] 0.3403298 Ciao Simone On 10/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi, > > This report deals with p-values coming from chisq.test using > the simulate.p=TRUE option. The issue is numerical accuracy > and was brought up in previous bug reports 3486 and 3896. > The bug was considered fixed but apparently was only mostly > fixed. Just the typical problem of two values that are > mathematically equal not ending up numerically equivalent. > > Consider this series of three 2x2 tables: > > [1,]17 > [2,]0 15 > > [1,]17 > [2,]0 16 > > [1,]17 > [2,]0 17 > > > The pvals returned from chisq.test(m, sim=TRUE)$p.value are > 0.3543228, 0.0004997501 and 0.3273363 respectively. > > The 2nd seems a bit unlikely, huh? > > I checked into it and the value I'm getting for the statistic > (calculated in R code) is 4*.Machine$double.eps less than the > value (which should be equal) that is returned from the C-code > that does the simulation. > > > Code for creating/testing the three matrices shown above: > m <- matrix(c(1,0,7,15),2,2) ; chisq.test(m, sim=TRUE)$p.value > m <- matrix(c(1,0,7,16),2,2) ; chisq.test(m, sim=TRUE)$p.value > m <- matrix(c(1,0,7,17),2,2) ; chisq.test(m, sim=TRUE)$p.value > > > Running SuSE9.3 on a AMD Athlon4000+ > > > > version > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status Patched > major2 > minor1.1 > year 2005 > month07 > day 29 > language R > > > Thanks, > Doug > > > Douglas Grove > Statistical Research Associate > Fred Hutchinson Cancer Research Center > Seattle WA 98109 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in RScript.exe for 3.5.0
t the binary builds; I did install it, however
>>>>> the bug still seems to be there in the current build. The workaround you
>>>>> suggested does work:
>>>>>
>>>>> C:\>"C:\Program Files\R\R-devel\bin\x64\Rscript.exe" "C:\foo bar.R"
>>>>> Fatal error: cannot open file 'C:\foo': No such file or directory
>>>>>
>>>>>
>>>>> C:\>"C:\Program Files\R\R-devel\bin\x64\Rscript.exe" --vanilla "C:\foo
>>>>> bar.R"
>>>>> What do you get when you multiply 6 * 9?
>>>>> C:\>
>>>>>
>>>>> -Original Message-
>>>>> From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
>>>>> Sent: Thursday, April 26, 2018 8:35 AM
>>>>> To: Kerry Jackson ; r-devel@r-project.org
>>>>> Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
>>>>>
>>>>> On 04/26/2018 02:23 PM, Kerry Jackson wrote:
>>>>>
>>>>>> Thanks Tomas.
>>>>>>
>>>>>> I confirm the quick workaround works for me in the DOS prompt, and
>>>>>> when having a shortcut to RScript in SendTo, and when used in the Task
>>>>>> Scheduler. I have not tested the R-devel version, due to my
>>>>>> unfamiliarity
>>>>>> with installing from source code.
>>>>>>
>>>>> Thanks, Kerry.
>>>>>
>>>>> There are binary builds for daily snapshots of R-devel
>>>>> (development/unstable version of R) at
>>>>> https://cran.r-project.org/bin/windows/base/rdevel.html
>>>>>
>>>>> At this time the build should already have the fix.
>>>>>
>>>>> Best
>>>>> Tomas
>>>>>
>>>>> -Original Message-
>>>>>> From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
>>>>>> Sent: Thursday, April 26, 2018 6:34 AM
>>>>>> To: Kerry Jackson ; r-devel@r-project.org
>>>>>> Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
>>>>>>
>>>>>> Fixed in R-devel. I will port to R-patched after more testing.
>>>>>> Tomas
>>>>>>
>>>>>> On 04/26/2018 01:52 AM, Tomas Kalibera wrote:
>>>>>>
>>>>>>> Thanks for the report. A quick workaround before this gets fixed is
>>>>>>> to add an extra first argument that has no space in it, e.g.
>>>>>>>
>>>>>>> Rscript --vanilla "foo bar.R"
>>>>>>>
>>>>>>> The problem exists on all systems, not just Windows.
>>>>>>>
>>>>>>> Best
>>>>>>> Tomas
>>>>>>>
>>>>>>> On 04/25/2018 09:55 PM, Kerry Jackson wrote:
>>>>>>>
>>>>>>>> Hi R Developers,
>>>>>>>> I have found what I think is a bug in the RScript.exe in version
>>>>>>>> 3.5.0 of R for Windows.
>>>>>>>> When I call Rscript.exe for Version 3.5 of R, it is unable to open
>>>>>>>> the file if the file name or path has a space in it.
>>>>>>>> As an example of what happens, I saved 2 files with the code:
>>>>>>>> cat("What do you get when you multiply 6 * 9?") as C:\foo bar.R and
>>>>>>>> as C:\foo_bar.R When I in a DOS command window try to run these
>>>>>>>> using version 3.4.3 and 3.5:
>>>>>>>> C:\>"C:\Program Files\R\R-3.4.3\bin\x64\Rscript.exe" "C:\foo bar.R"
>>>>>>>> What do you get when you multiply 6 * 9?
>>>>>>>> C:\>"C:\Program Files\R\R-3.4.3\bin\x64\Rscript.exe" "C:\foo_bar.R"
>>>>>>>> What do you get when you multiply 6 * 9?
>>>>>>>> C:\>"C:\Program Files\R\R-3.5.0\bin\x64\Rscript.exe" "C:\foo bar.R"
>>>>>>>> Fatal error: cannot open file 'C:\foo': No such file or directory
>>>>>>>>
>>>>>>>>
>>>>>>>> C:\>"C:\Program Files\R\R-3.5.0\bin\x64\Rscript.exe" "C:\foo_bar.R"
>>>>>>>> What do you get when you multiply 6 * 9?
>>>>>>>> C:\>
>>>>>>>> When I try to run the file with a space in the name in version
>>>>>>>> 3.5.0 of R, there is a fatal error saying there is no such file.
>>>>>>>>
>>>>>>>>
>>>>>>>> Kerry Jackson
>>>>>>>> Job title: Senior Account Manager, Ipsos Connect US RA Testing GMU
>>>>>>>> Phone: (203) 840-3443
>>>>>>>>
>>>>>>>>
>>>>>>>>[[alternative HTML version deleted]]
>>>>>>>>
>>>>>>>> __
>>>>>>>> R-devel@r-project.org mailing list
>>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>>>>
>>>>>>>
>>>> __
>>>> R-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> _
>
> PHILOSOPHICAL TRANSACTIONS OF THE ROYAL SOCIETY A
> Theme issue ‘DNA as information
> <http://rsta.royalsocietypublishing.org/content/dna-information>’
> edited by Julyan H.E. Cartwright, Simone Giannerini and Diego L. González
> _
>
> Simone Giannerini
> Dipartimento di Scienze Statistiche "Paolo Fortunati"
> Universita' di Bologna
> Via delle belle arti 41 - 40126 Bologna, ITALY
> Tel: +39 051 2098262 Fax: +39 051 232153
> http://www2.stat.unibo.it/giannerini/
> __
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] parRapply and parCapply return a list in corner cases
According to ?parCapply:
parRapply and parCapply always return a vector.
This appears not to be the case in the following minimal reproducible example:
> library(parallel)
> nslaves <- 2
> cl <- makeCluster(nslaves)
> X <- matrix(2,nrow=3,ncol=4)
> X <- rbind(c(1,1,0,1),X)
> tv <- parCapply(cl,X,FUN=function(x){
+ ind <- x[1]
+ y <- x[-1]
+ if(ind==1){
+ r1 <- sum(y)
+ }else{
+ r1 <- logical(0)
+ }
+ return(unlist(as.numeric(c(ind,r1
+ })
> tv
[[1]]
[1] 1
[[2]]
[1] 6
[[3]]
[1] 1
[[4]]
[1] 6
[[5]]
[1] 0
[[6]]
[1] 1 6
> class(tv)
[1] "list"
> sessionInfo()
R version 4.0.0 (2020-04-24)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18363)
Matrix products: default
locale:
[1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252
[3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C
[5] LC_TIME=Italian_Italy.1252
attached base packages:
[1] parallel stats graphics grDevices utils datasets
methods base
loaded via a namespace (and not attached):
[1] compiler_4.0.0
--
_
PHILOSOPHICAL TRANSACTIONS OF THE ROYAL SOCIETY A
Theme issue ‘DNA as information’
edited by Julyan H.E. Cartwright, Simone Giannerini and Diego L. González
_________
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
https://www.unibo.it/sitoweb/simone.giannerini/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
Dear Gabor, I do not agree with your claim "In the case of the R list there is a larger potential demand for free help than resources to answer and without the usual monetary economics to allocate resources I believe that the functional purpose of rudeness here is to ration those resources and minimize duplication of questions" In fact, apart from the fact that rudeness should never be justified, I was amazed at the amount of time dedicated by some people to give unhelpful replies to dumb (and less dumb) questions (at least on R-devel). In my opinion this behaviour causes some damages to the whole R project for at least two reasons: 1. On the bug report side if you want to have a good percentage of true positive reports you should allow for a high percentage of false positive reports. But if people are scared to post you will lose the true positive together with false ones. 2. People that are potentially willing to contribute are discouraged to do it. Kind regards Simone On Fri, Aug 20, 2010 at 8:37 PM, Gabor Grothendieck wrote: > On Fri, Aug 20, 2010 at 2:12 PM, Paul Johnson > wrote: > > On Thu, Aug 19, 2010 at 7:08 PM, Spencer Graves > > wrote: > >> What do you think about adding a "No RTFM" policy to the R mailing > lists? > >> Per, "http://en.wikipedia.org/wiki/RTFM": > >> > > I think this is a great suggestion. > > > > I notice the R mailing list already has a gesture in this direction: > > "Rudeness and ad hominem comments are not acceptable. Brevity is OK." > > > > But the people who behave badly don't care about policies like this > > and they will keep doing what they do. > > Although it may seem hard to justify rudeness its often the case that > even the most bizarre behavior makes sense if you view it from the > perspective of that person. In the case of the R list there is a > larger potential demand for free help than resources to answer and > without the usual monetary economics to allocate resources I believe > that the functional purpose of rudeness here is to ration those > resources and minimize duplication of questions. If that is correct > one can predict that if civility were to become the norm on this list > then other rationing mechanisms would arise to replace it. > > For example, it might become the norm that most questions are not > answered or are answered less thoroughly or the list might be replaced > as the de facto goto medium for R questions by some other list or web > site so we have to be careful about unintended consequences. > > __________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tabulate() does not check for input bounds
Dear all, it looks like that tabulate() does not check for the bounds of the input. Reproducible example: > b <- 1:2 > tabulate(b[1:100]) [1] 1 1 > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status Patched major 2 minor 11.1 year 2010 month 09 day30 svn rev53072 language R version.string R version 2.11.1 Patched (2010-09-30 r53072) > sessionInfo() R version 2.11.1 Patched (2010-09-30 r53072) Platform: i386-pc-mingw32 (32-bit) locale: [1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252 LC_MONETARY=Italian_Italy.1252 [4] LC_NUMERIC=C LC_TIME=Italian_Italy.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] gtools_2.6.2 loaded via a namespace (and not attached): [1] tools_2.11.1 OS: Windows 7 64 bit -- ______ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tabulate() does not check for input bounds
Dear Olaf, thanks for your reply, at first sight I did not link this behaviour to that subsetting feature that I must admit I am not used to. Ciao Simone On Mon, Oct 4, 2010 at 1:13 AM, Olaf Mersmann wrote: > Dear Simone, > > On 04.10.2010, at 01:01, Simone Giannerini wrote: >> it looks like that tabulate() does not check for the bounds of the input. >> Reproducible example: >> >>> b <- 1:2 >>> tabulate(b[1:100]) >> [1] 1 1 > > this looks perfectly reasonable. Consider the result of > >> b <- 1:2 >> b[1:100] > [1] 1 2 NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA > NA > [26] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA > NA > [51] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA > NA > [76] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA > NA > > and check the help page for tabulate (esp. the na.rm argument). > > What was your expected result? > > Cheers, > Olaf > > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning: you may need to use R-patched with recent R distros
I see the problem on my OpenSuse 11.3 box gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] > sessionInfo() R version 2.12.1 Patched (2011-01-10 r53953) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base > z <- 0.2853725+0.3927816i > z2 <- z^(1:20) > z3 <- z^-(1:20) > z0 <- cumprod(rep(z, 20)) > stopifnot(all.equal(z2, z0), all.equal(z3, 1/z0)) Error: all.equal(z2, z0) is not TRUE Simone On Wed, Feb 2, 2011 at 1:45 AM, Dominick Samperi wrote: > On Mon, Jan 31, 2011 at 3:18 PM, Prof Brian Ripley > wrote: > > On Mon, 31 Jan 2011, ken.willi...@thomsonreuters.com wrote: > > > >> For the complex-numbers bug, do you know a reliable way (besides looking > >> at version numbers) to determine whether the bug is present or absent in > a > >> given build? > > > > I know a way: See tests/complex.R in R-devel. > > > > z <- 0.2853725+0.3927816i > > z2 <- z^(1:20) > > z3 <- z^-(1:20) > > z0 <- cumprod(rep(z, 20)) > > stopifnot(all.equal(z2, z0), all.equal(z3, 1/z0)) > > ## z^3 had value z^2 > > > > I tried this under Fedora 14 (GCC 4.5.1) using the released R 2.12.1 and > R-devel (2.13.0 devel) and saw no problems? I compared the numbers with > those generated by Octave, took the cube root of z^3 and got z, ran this > unit test and stopifnot did not terminate, etc. > > At build time the optimization level was O2. > > Dominick > > >> > >> I don't know what version of gcc was used in my build nor the > optimization > >> flags, so I did a few test exponentiations z^n and the results look > okay, > >> but maybe I'm not tickling the right bits. > >> > >> > >> -- > >> Ken Williams > >> Senior Research Scientist > >> Thomson Reuters > >> Phone: 651-848-7712 > >> ken.willi...@thomsonreuters.com > >> http://labs.thomsonreuters.com > >> > >> > >> > >> > >> > >> On 1/31/11 1:48 PM, "Prof Brian Ripley" wrote: > >> > >>> Two things have emerged in testing on x86_64 Fedora 14 which mean that > >>> a recent R-patched is probably needed. > >>> > >>> 1) That OS uses zlib 1.2.5: that claims to be binary-compatible with > >>> zlib 1.2.3 but is not, as we found (painfully) on Windows. The remedy > >>> was to remap _all_ the symbols in R's own copy of zlib (not just those > >>> zlib arranged to remap). > >>> > >>> The symptoms were crashes using packages XML and rgoobi (both of which > >>> link to zlib) and incorrect results in RJaCGH (which contains a copy > >>> of zlib). There may well be other problems > >>> > >>> 2) Fedora 14 uses gcc 4.5.1. With CFLAGS containing the default -O2 > >>> or higher, HAVE_C99_COMPLEX was detected as false because there is a > >>> (genuine) incompatibility between types Rcomplex and C99's double > >>> complex. This means that R's fallback code is used, and regretably > >>> that contains a serious bug in an 'optimization' by a colleague, so > >>> z^n is incorrect for most complex z and integer n (and has been since > >>> 2.10.0). The remedy is to use R-patched or R-devel, or only optimize > >>> to -O. > >>> > >>> We've also seen incorrect results from package mvtnorm when C > >>> optimization was -O3. > >>> > >>> The upshot is that there is likely to be a 2.12.2 to fix these issues. > >>> > >>> -- > >>> Brian D. Ripley, rip...@stats.ox.ac.uk > >>> Professor of Applied Statistics, > >>> http://www.stats.ox.ac.uk/~ripley/<http://www.stats.ox.ac.uk/%7Eripley/> > >>> University of Oxford, Tel: +44 1865 272861 (self) > >>> 1 South Parks Road, +44 1865 272866 (PA) > >>> Oxford OX1 3TG, UKFax: +44 1865 272595 > >>> > >>> __ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>
Re: [Rd] Warning: you may need to use R-patched with recent R distros
I can confirm that the problem is not present anymore in R-patched, same box as before, compiled with standard optimizations flags. thank you Simone gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] > sessionInfo() R version 2.12.1 Patched (2011-02-01 r54197) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.12.1 On Wed, Feb 2, 2011 at 12:03 PM, Prof Brian Ripley wrote: > On Wed, 2 Feb 2011, Simone Giannerini wrote: > > I see the problem on my OpenSuse 11.3 box >> >> gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] >> >> > sessionInfo() >> R version 2.12.1 Patched (2011-01-10 r53953) >> > > Please update this and let us know if it persists with current R-patched. > > > Platform: x86_64-unknown-linux-gnu (64-bit) >> > > DS failed to tell us his platform, and maybe it was not x86_64. > > > locale: >> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C >> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 >> [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 >> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C >> [9] LC_ADDRESS=C LC_TELEPHONE=C >> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> > z <- 0.2853725+0.3927816i >> > z2 <- z^(1:20) >> > z3 <- z^-(1:20) >> > z0 <- cumprod(rep(z, 20)) >> > stopifnot(all.equal(z2, z0), all.equal(z3, 1/z0)) >> Error: all.equal(z2, z0) is not TRUE >> >> Simone >> >> >> On Wed, Feb 2, 2011 at 1:45 AM, Dominick Samperi >> wrote: >> On Mon, Jan 31, 2011 at 3:18 PM, Prof Brian Ripley >> wrote: >> > On Mon, 31 Jan 2011, ken.willi...@thomsonreuters.com wrote: >> > >> >> For the complex-numbers bug, do you know a reliable way (besides >> looking >> >> at version numbers) to determine whether the bug is present or >> absent in a >> >> given build? >> > >> > I know a way: See tests/complex.R in R-devel. >> > >> > z <- 0.2853725+0.3927816i >> > z2 <- z^(1:20) >> > z3 <- z^-(1:20) >> > z0 <- cumprod(rep(z, 20)) >> > stopifnot(all.equal(z2, z0), all.equal(z3, 1/z0)) >> > ## z^3 had value z^2 >> > >> >> I tried this under Fedora 14 (GCC 4.5.1) using the released R 2.12.1 >> and >> R-devel (2.13.0 devel) and saw no problems? I compared the numbers >> with >> those generated by Octave, took the cube root of z^3 and got z, ran >> this >> unit test and stopifnot did not terminate, etc. >> >> At build time the optimization level was O2. >> >> Dominick >> >> >> >> >> I don't know what version of gcc was used in my build nor the >> optimization >> >> flags, so I did a few test exponentiations z^n and the results look >> okay, >> >> but maybe I'm not tickling the right bits. >> >> >> >> >> >> -- >> >> Ken Williams >> >> Senior Research Scientist >> >> Thomson Reuters >> >> Phone: 651-848-7712 >> >> ken.willi...@thomsonreuters.com >> >> http://labs.thomsonreuters.com >> >> >> >> >> >> >> >> >> >> >> >> On 1/31/11 1:48 PM, "Prof Brian Ripley" >> wrote: >> >> >> >>> Two things have emerged in testing on x86_64 Fedora 14 which mean >> that >> >>> a recent R-patched is probably needed. >> >>> >> >>> 1) That OS uses zlib 1.2.5: that claims to be binary-compatible >> with >> >>> zlib 1.2.3 but is not, as we found (painfully) on Windows. The >> remedy >> >>> was to remap _all_ the symbols in R's own copy of zlib (not just >> those >> >>> zlib arranged to remap). >> >>> >> >>> The symptoms were crashes using packages XML and rgoobi (both of >> which >> >>> link to zlib) and incorrect results in RJaCGH (which contains a >>
Re: [Rd] Error in .Fortran Call
add
IMPLICIT NONE
DOUBLE PRECISION X(N),XMEAN
INTEGER N,J
to your subroutine.
Ciao
Simone
P.S. It is best to include IMPLICIT NONE in all of your subroutines and to
avoid underscores in subroutines' names.
On Wed, May 4, 2011 at 2:26 PM, vioravis wrote:
> I have the following FORTRAN code converted to a DLL:
>
> ! my_xmean.f90
> !
> ! FUNCTIONS/SUBROUTINES exported from my_function.dll:
> ! my_function - subroutine
> !
> subroutine my_xmean(X,N,XMEAN)
>
> ! Expose subroutine my_function to users of this DLL
> !
> !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'my_xmean_'::my_xmean
>
> ! Body of my_function
>
> DOUBLE PRECISION X(N)
>
> XMEAN=0D0
> DO J=1,N
> XMEAN=XMEAN+X(J)
> END DO
> XMEAN=XMEAN/N
> RETURN
> end subroutine my_xmean
>
>
>
> When I call this DLL from R, it gets loaded properly but the values of
> XMEAN
> calcualted are way off:
>
>
> x <- 1:6
>
> > .Fortran("my_xmean",as.double(X),as.integer(length(X)),double(1))
>
> [[1]]
> [1] 1 2 3 4 5 6
>
> [[2]]
> [1] 6
>
> $xmean
> [1] 5.336073e-315
>
> Can someone please let me what is causing this huge difference??? Thank
> you.
>
> Ravi
>
>
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/Error-in-Fortran-Call-tp3495319p3495319.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Under Windows, Rgui and Rterm crash if one tries to close the graphic device while identify or locator are running
minimal reproducible example plot(1,1) identify(1,1) # or locator() now, trying to close the window by clicking on the cross of the upper right corner causes Rgui (and Rterm) to crash. I see the same behaviour on 2 different Windows PC (one with Win 8.1 and one with Win 10). I did not see the problem in linux (see below) WINDOWS ** > sessionInfo() R version 3.3.0 beta (2016-04-04 r70420) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 10586) locale: [1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252 [3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base > sessionInfo() R version 3.2.2 Patched (2015-09-29 r69441) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 10240) locale: [1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252 LC_MONETARY=Italian_Italy.1252 [4] LC_NUMERIC=C LC_TIME=Italian_Italy.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_3.2.2 ** LINUX * > sessionInfo() R version 3.2.0 Patched (2015-04-21 r68221) Platform: x86_64-unknown-linux-gnu (64-bit) Running under: openSUSE 13.2 (Harlequin) (x86_64) locale: [1] LC_CTYPE=it_IT.UTF-8 LC_NUMERIC=C [3] LC_TIME=it_IT.UTF-8LC_COLLATE=it_IT.UTF-8 [5] LC_MONETARY=it_IT.UTF-8LC_MESSAGES=it_IT.UTF-8 [7] LC_PAPER=it_IT.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=it_IT.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base -- ______ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] summary.default rounding on numeric seems inconsistent with other R behaviors
John,
I had raised the matter ten years ago, and I was told that the topic was
already very^3 old
https://stat.ethz.ch/pipermail/r-devel/2006-September/042684.html
there is some discussion on its origin and also a declaration of intents to
change the default behaviour, which, unfortunately, remained a declaration.
I agree that R could do better here, let's hope in less than ten years
though. ;-)
Kind regards,
Simone
On Fri, Aug 19, 2016 at 5:04 PM, John Mount wrote:
> I was wondering if it would make sense to change the default behavior of
> the following:
>
> summary(1L)
> ##Min. 1st Qu. MedianMean 3rd Qu.Max.
> ## 15560 15560 15560 15560 15560 15560
>
> summary.default on numeric values rounds values (not just presentation) to
> getOption("digits")-3L (or four) digits by default, making those values
> surprising and less suitable for further calculation. Summary on matrix
> and data.frame do not do so.
>
> It seems it would be nice to have x=1L; summary(x)[['Min.']] == min(x)
> evaluate to TRUE. I know one can alter behavior by changing the global
> “digits” option, but I don’t know what other impacts that might have.
> Ideally I would think summary.default would not round its values at all,
> but use digits to control presentation (by overriding print and such).
> Even in presentation the rounding without switching to scientific notation
> (such as 1.556e+4) is a bit surprising (I understand rounding and
> scientific notation are two different presentation issues, but new users
> are very confused that something that appears to be an integer has been
> rounded).
>
> Example:
>
> summary(data.frame(x=1))
> ##x
> ## Min. :1
> ## 1st Qu.:1
> ## Median :1
> ## Mean :1
> ## 3rd Qu.:1
> ## Max. :1
> summary(1)
> ##Min. 1st Qu. MedianMean 3rd Qu.Max.
> ## 15560 15560 15560 15560 15560 15560
>
> I have a (bit whiny) polemic trying to explain the pain point here
> http://www.win-vector.com/blog/2016/08/my-criticism-of-r-numeric-summary/
> <http://www.win-vector.com/blog/2016/08/my-criticism-of-r-numeric-summary/>
> (I am not trying to be rude, more I am trying to emphasize why this can be
> confusing to new users).
>
>
>
> ---
> John Mount
> http://www.win-vector.com/ <http://www.win-vector.com/>
> Our book: Practical Data Science with R http://www.manning.com/zumel/ <
> http://www.manning.com/zumel/>
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
___
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
___
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parRapply and parCapply return a list in corner cases
For the record: I filed a bug report here
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17807
and this is a more polished minimal example
library(parallel)
nslaves <- 2
cl <- makeCluster(nslaves)
X <- matrix(c(1,0,1),1,3)
res <- parCapply(cl,X,FUN=function(x){
y <- x[1]
if(y==1){
out <- y
}else{
out <- double(0)
}
return(out)
})
> res
[[1]]
[1] 1
[[2]]
numeric(0)
[[3]]
[1] 1
Simone
On Mon, May 18, 2020 at 5:23 PM Simone Giannerini wrote:
>
> According to ?parCapply:
>
> parRapply and parCapply always return a vector.
>
> This appears not to be the case in the following minimal reproducible example:
>
> > library(parallel)
> > nslaves <- 2
> > cl <- makeCluster(nslaves)
> > X <- matrix(2,nrow=3,ncol=4)
> > X <- rbind(c(1,1,0,1),X)
> > tv <- parCapply(cl,X,FUN=function(x){
> + ind <- x[1]
> + y <- x[-1]
> + if(ind==1){
> + r1 <- sum(y)
> + }else{
> + r1 <- logical(0)
> + }
> + return(unlist(as.numeric(c(ind,r1
> + })
> > tv
> [[1]]
> [1] 1
>
> [[2]]
> [1] 6
>
> [[3]]
> [1] 1
>
> [[4]]
> [1] 6
>
> [[5]]
> [1] 0
>
> [[6]]
> [1] 1 6
>
> > class(tv)
> [1] "list"
> > sessionInfo()
> R version 4.0.0 (2020-04-24)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 18363)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252
> [3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C
> [5] LC_TIME=Italian_Italy.1252
>
> attached base packages:
> [1] parallel stats graphics grDevices utils datasets
> methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.0.0
>
> --
> _________
>
> PHILOSOPHICAL TRANSACTIONS OF THE ROYAL SOCIETY A
> Theme issue ‘DNA as information’
> edited by Julyan H.E. Cartwright, Simone Giannerini and Diego L. González
> _
>
> Simone Giannerini
> Dipartimento di Scienze Statistiche "Paolo Fortunati"
> Universita' di Bologna
> Via delle belle arti 41 - 40126 Bologna, ITALY
> Tel: +39 051 2098262 Fax: +39 051 232153
> https://www.unibo.it/sitoweb/simone.giannerini/
> __
--
___
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
https://simonegiannerini.net/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NROW and NCOL on NULL
Dear list, I do not know what would be the 'correct' answer to the following but I think that they should return the same value to avoid potential problems and hard to debug errors. Regards, Simone --- > NCOL(NULL) [1] 1 > NROW(NULL) [1] 0 > sessionInfo() R version 4.3.1 RC (2023-06-08 r84523 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 11 x64 (build 22621) Matrix products: default locale: [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.utf8 time zone: Europe/Rome tzcode source: internal attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.3.1 -- _______ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 https://simonegiannerini.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NROW and NCOL on NULL
I know it's documented and I know there are other ways to guard against this behaviour, once you know about this. The point is whether it might be worth it to make NCOL and NROW return the same value on NULL and make R more consistent/intuitive and possibly less error prone. Regards, Simone On Sat, Sep 23, 2023 at 7:50 PM Duncan Murdoch wrote: > > It's been documented for a long time that NCOL(NULL) is 1. What > particular problems did you have in mind? There might be other ways to > guard against them. > > Duncan Murdoch > > On 23/09/2023 1:43 p.m., Simone Giannerini wrote: > > Dear list, > > > > I do not know what would be the 'correct' answer to the following but > > I think that they should return the same value to avoid potential > > problems and hard to debug errors. > > > > Regards, > > > > Simone > > --- > > > >> NCOL(NULL) > > [1] 1 > > > >> NROW(NULL) > > [1] 0 > > > >> sessionInfo() > > R version 4.3.1 RC (2023-06-08 r84523 ucrt) > > Platform: x86_64-w64-mingw32/x64 (64-bit) > > Running under: Windows 11 x64 (build 22621) > > > > Matrix products: default > > > > > > locale: > > [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 > > [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C > > [5] LC_TIME=Italian_Italy.utf8 > > > > time zone: Europe/Rome > > tzcode source: internal > > > > attached base packages: > > [1] stats graphics grDevices utils datasets methods base > > > > loaded via a namespace (and not attached): > > [1] compiler_4.3.1 > > > -- ___ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 https://simonegiannerini.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NROW and NCOL on NULL
Thank you for your comment, On Sat, Sep 23, 2023 at 9:51 PM Ben Bolker wrote: > > This is certainly worth discussing, but there's always a heavy > burden of back-compatibility; how much better would it be for NCOL and > NROW to both return zero, vs. the amount of old code that would be broken? I do not have an answer to this question but it seems to me that code that relies upon NCOL(NULL) being 1 is not extremely good (and portable). > >Furthermore, the reason for this behaviour is justified as > consistency with the behaviour of as.matrix() and cbind() for > zero-length vectors, from ?NCOL: > > ## as.matrix() produces 1-column matrices from 0-length vectors, > ## and so does cbind() : > > (of course you could argue that this behaviour should be changed as > well ...) > > Yes, it is documented and somehow clashes with the more intuitive behaviour of subsetting matrices > a <- matrix(1:4,2,2) > a [,1] [,2] [1,]13 [2,]24 > a2 <- a[,-(1:2)] > a2 [1,] [2,] > dim(a2) [1] 2 0 NULL is often used to declare an undefined value for the argument of a function. If such an argument is potentially a matrix, then using NULL as the default requires additional code to check for the number of columns and use it in the code. The same holds to a lesser extent for functions that are expected to return a matrix and return NULL instead. Kind regards, Simone > On 2023-09-23 3:41 p.m., Simone Giannerini wrote: > > I know it's documented and I know there are other ways to guard > > against this behaviour, once you know about this. > > The point is whether it might be worth it to make NCOL and NROW return > > the same value on NULL and make R more consistent/intuitive and > > possibly less error prone. > > > > Regards, > > > > Simone > > > > On Sat, Sep 23, 2023 at 7:50 PM Duncan Murdoch > > wrote: > >> > >> It's been documented for a long time that NCOL(NULL) is 1. What > >> particular problems did you have in mind? There might be other ways to > >> guard against them. > >> > >> Duncan Murdoch > >> > >> On 23/09/2023 1:43 p.m., Simone Giannerini wrote: > >>> Dear list, > >>> > >>> I do not know what would be the 'correct' answer to the following but > >>> I think that they should return the same value to avoid potential > >>> problems and hard to debug errors. > >>> > >>> Regards, > >>> > >>> Simone > >>> --- > >>> > >>>> NCOL(NULL) > >>> [1] 1 > >>> > >>>> NROW(NULL) > >>> [1] 0 > >>> > >>>> sessionInfo() > >>> R version 4.3.1 RC (2023-06-08 r84523 ucrt) > >>> Platform: x86_64-w64-mingw32/x64 (64-bit) > >>> Running under: Windows 11 x64 (build 22621) > >>> > >>> Matrix products: default > >>> > >>> > >>> locale: > >>> [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 > >>> [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C > >>> [5] LC_TIME=Italian_Italy.utf8 > >>> > >>> time zone: Europe/Rome > >>> tzcode source: internal > >>> > >>> attached base packages: > >>> [1] stats graphics grDevices utils datasets methods base > >>> > >>> loaded via a namespace (and not attached): > >>> [1] compiler_4.3.1 > >>> > >> > > > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- ___ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 https://simonegiannerini.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NROW and NCOL on NULL
I just saw this r85704 | hornik | 2023-12-19 00:33:07 -0600 (Tue, 19 Dec 2023) | 1 line Changed paths: M /trunk/doc/NEWS.Rd M /trunk/src/library/base/R/matrix.R M /trunk/src/library/base/man/nrow.Rd M /trunk/src/library/profile/Common.R Have NCOL(NULL) return 0 instead of 1. Many thanks to Kurt and the whole R-core team! Simone On Sat, Sep 23, 2023 at 7:43 PM Simone Giannerini wrote: > > Dear list, > > I do not know what would be the 'correct' answer to the following but > I think that they should return the same value to avoid potential > problems and hard to debug errors. > > Regards, > > Simone > --- > > > NCOL(NULL) > [1] 1 > > > NROW(NULL) > [1] 0 > > > sessionInfo() > R version 4.3.1 RC (2023-06-08 r84523 ucrt) > Platform: x86_64-w64-mingw32/x64 (64-bit) > Running under: Windows 11 x64 (build 22621) > > Matrix products: default > > > locale: > [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 > [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C > [5] LC_TIME=Italian_Italy.utf8 > > time zone: Europe/Rome > tzcode source: internal > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.3.1 > > -- > ___ > > Simone Giannerini > Dipartimento di Scienze Statistiche "Paolo Fortunati" > Universita' di Bologna > Via delle belle arti 41 - 40126 Bologna, ITALY > Tel: +39 051 2098262 Fax: +39 051 232153 > https://simonegiannerini.net/ > ___ -- ___ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 https://simonegiannerini.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen(symmetric=TRUE) for complex matrices
1i,1i,2),2,2)# 'C' is symmetric > >> eigen(C,F,T)$values > > [1] 2-1i 2+1i > >> eigen(C,T,T)$values # answers disagree because 'C' is not Hermitian > > [1] 3 1 > >> > > > > This issue, however, I do not understand; ?eigen already has: > > > symmetric: if ‘TRUE’, the matrix is assumed to be symmetric (or > Hermitian if complex) and only its lower triangle (diagonal > included) is used. If ‘symmetric’ is not specified, the > matrix is inspected for symmetry. > > Which part of "Hermitian if complex" is unclear? > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- ___ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in plot.ts?
Dear all, I think I have found a buglet in plot.ts plot.ts(x=1,type="n") # correct: does not show the plot plot.ts(x=1,y=1,type="n") # not correct: does show the plot I did not investigate the problem in depth but it could be related to the switch xy.labels, in fact plot.ts(x=1,y=1,type="n",xy.labels=TRUE) # does show the plot plot.ts(x=1,y=1,type="n",xy.labels=FALSE) # does not show the plot > sessionInfo() R version 2.15.2 Patched (2012-10-26 r61028) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252 [3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.15.2 Kind regards Simone __________ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in plot.ts?
Rui,
thanks for looking into this and adding some relevant info,
to me it looks more like a bug than lack of documentation, in any case
we'll see if anyone of the core team would like to comment.
Ciao
Simone
On Sat, Dec 29, 2012 at 8:22 PM, Rui Barradas wrote:
> Just to add, on documentation, to my previous post. The following
> illustrates my point.
>
> # This is the last instruction in the original post.
> plot.ts(x=1, y=1, type="n", xy.labels=FALSE) # does not show the plot
>
> plot.ts(x=1, y=1, xy.labels=FALSE) # does show the plot, does not label it,
> documented
> plot.ts(x=1, y=1, type="n") # does show the plot (labels it), not properly
> documented
> plot.ts(x=1:151, y=1:151, type="n") # does not show the plot, documented
>
> Rui Barradas
> Em 29-12-2012 19:07, Rui Barradas escreveu:
>>
>> Hello,
>>
>> You're right, it has to do with the argument xy.labels. The relevant
>> lines in the source are
>> (file src/library/stats/R/ts.R, function plot.ts)
>>
>> [...]
>> n <- length(xy $ x) #-> default for xy.l(ines|abels)
>> if(missing(xy.labels)) xy.labels <- (n <= 150)
>> if(!is.logical(xy.labels)) {
>> if(!is.character(xy.labels))
>> stop("'xy.labels' must be logical or character")
>> do.lab <- TRUE
>> } else do.lab <- xy.labels
>> [...]
>> ptype <-
>> if(do.lab) "n" else if(missing(type)) "p" else type
>> plot.default(xy, type = ptype,
>> [...]
>> if(do.lab)
>> text(xy, labels =
>>if(is.character(xy.labels)) xy.labels
>>else if(all(tsp(x) == tsp(y))) formatC(time(x), width = 1)
>>else seq_along(xy$x),
>>col = col, cex = cex)
>> if(xy.lines)
>> lines(xy, col = col, lty = lty, lwd = lwd,
>> type = if(do.lab) "c" else "l")
>> [...]
>>
>> Note that this is executed only if both 'x' and 'y' are passed to plot.ts.
>> The variable 'do.lab' will control the plot.default type and whether the
>> points are labeled using text() and the lines() type.
>> This variable is set according to xy.labels. This behavior is more or
>> less documented in plot.ts:
>>
>> |"xy.labels|||logical, indicating if |text
>> <http://127.0.0.1:29428/library/stats/help/text>()| labels should be
>> used for an x-y plot, /or/ character, supplying a vector of labels to be
>>
>> used. The default is to label for up to 150 points, and not for more."
>>
>> but I believe the documentation could be more clear. It could say that
>> in the case of a y ~ x plot, to supress the plot xy.labels should be set
>> to FALSE.
>>
>> Hope this helps,
>>
>> Rui Barradas
>> Em 29-12-2012 17:04, Simone Giannerini escreveu:
>>>
>>> Dear all,
>>>
>>> I think I have found a buglet in plot.ts
>>>
>>> plot.ts(x=1,type="n") # correct: does not show the plot
>>> plot.ts(x=1,y=1,type="n") # not correct: does show the plot
>>>
>>> I did not investigate the problem in depth but it could be related to
>>> the switch xy.labels, in fact
>>>
>>> plot.ts(x=1,y=1,type="n",xy.labels=TRUE) # does show the plot
>>> plot.ts(x=1,y=1,type="n",xy.labels=FALSE) # does not show the plot
>>>
>>>> sessionInfo()
>>>
>>> R version 2.15.2 Patched (2012-10-26 r61028)
>>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>>>
>>> locale:
>>> [1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252
>>> [3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C
>>> [5] LC_TIME=Italian_Italy.1252
>>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>>
>>> loaded via a namespace (and not attached):
>>> [1] tools_2.15.2
>>>
>>>
>>> Kind regards
>>>
>>> Simone
>>> __
>>>
>>>
>>> Simone Giannerini
>>> Dipartimento di Scienze Statistiche "Paolo Fortunati"
>>> Universita' di Bologna
>>> Via delle belle arti 41 - 40126 Bologna, ITALY
>>> Tel: +39 051 2098262 Fax: +39 051 232153
>>> http://www2.stat.unibo.it/giannerini/
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>> [[alternative HTML version deleted]]
>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
___
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with function in fortran 95
Fabio,
I see two problems with your code:
1. R type numeric corresponds to FORTRAN Real*8 (or double precision)
so that line 4 of your mat.f95 becomes:
REAL*8 :: x, y, res
2. your R code won't ever succeed because you pass integer matrices
(x,y,res) to a subroutine that expects REAL*8 data.
you need to coerce all your matrices to "double" as follows:
storage.mode(x) <- "double"
storage.mode(y) <- "double"
storage.mode(res) <- "double"
Finally, you can call the corrected function:
.Fortran("mymult", x,y,res,as.integer(l),as.integer(c))
[[1]]
[,1] [,2] [,3] [,4]
[1,]16 11 16
[2,]27 12 17
[3,]38 13 18
[4,]49 14 19
[5,]5 10 15 20
[[2]]
[,1] [,2] [,3] [,4] [,5]
[1,] 20 16 1284
[2,] 19 15 1173
[3,] 18 14 1062
[4,] 17 13951
[[3]]
[,1] [,2] [,3] [,4] [,5]
[1,] 604 468 332 196 60
[2,] 678 526 374 222 70
[3,] 752 584 416 248 80
[4,] 826 642 458 274 90
[5,] 900 700 500 300 100
[[4]]
[1] 5
[[5]]
[1] 4
All these issues are discussed in the "Writing R Extensions" manual,
please read it carefully.
Ciao
Simone
On Wed, Aug 12, 2009 at 1:32 PM, Fabio Mathias
Corrêa wrote:
> I am writing a function in fortran 95, but the intrinsic function MATMUL is
> not working properly. Here's an example.
>
> SUBROUTINE mymult(x,y,res,m,n)
> IMPLICIT NONE
> INTEGER :: m,n
> REAL :: x, y, res
> DIMENSION :: x(m,n), y(n,m), res(m,m)
> res = MATMUL(x,y)
> END SUBROUTINE mymult
>
> R CMD SHLIB mat.f95
>
> In R:
>
> dyn.load("mat.so")
> x <- matrix(1:20,5)
> l <- nrow(x)
> c <- ncol(x)
> y <- matrix(20:1,c)
> res <- matrix(0,l,l)
> dim(x)
> dim(y)
> dim(res)
> l
> c
> .Fortran("mymult", x,y,res,l,c)
>
> [[1]]
> [,1] [,2] [,3] [,4]
> [1,] 1 6 11 16
> [2,] 2 7 12 17
> [3,] 3 8 13 18
> [4,] 4 9 14 19
> [5,] 5 10 15 20
>
> [[2]]
> [,1] [,2] [,3] [,4] [,5]
> [1,] 20 16 12 8 4
> [2,] 19 15 11 7 3
> [3,] 18 14 10 6 2
> [4,] 17 13 9 5 1
>
> [[3]]
> [,1] [,2] [,3] [,4] [,5]
> [1,] 0 0 0 0 0
> [2,] 0 0 0 0 0
> [3,] 0 0 0 0 0
> [4,] 0 0 0 0 0
> [5,] 0 0 0 0 0
>
> [[4]]
> [1] 5
>
> [[5]]
> [1] 4
>
>
> Linux Ubuntu 8.04 and use compiler gfortran 4.2.
> The problem is the compiler?
>
> Thanks!
>
> Fábio Mathias Corrêa
> Estatística e Experimentação Agropecuária/UFLA
> Brazil
>
>
>
> ________
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] make fails on R r50499 ( openSuSE 11.0 x86-64)
Dear all, I encountered a problem when compiling the source of R patched 2.10.0 r50499 (19-11-2009) linked to ACML single threaded (4.2.0 or 4.3.0) OS: openSuSE 11.0 x86-64 make fails when it comes to installing mgcv with the following [snip] ** R ** inst ** preparing package for lazy loading Error in loadNamespace(i[[1L]], c(lib.loc, .libPaths())) : non esiste un pacchetto chiamato 'Matrix' package 'Matrix' does not exist ## TRANSLATED BY ME ERROR: lazy loading failed for package ‘mgcv’ * removing ‘/home/giannerini/Desktop/R-patched/library/mgcv’ make[2]: *** [mgcv.ts] Error 1 make[2]: Leaving directory `/home/giannerini/Desktop/R-patched/src/library/Recommended' make[1]: *** [recommended-packages] Error 2 make[1]: Leaving directory `/home/giannerini/Desktop/R-patched/src/library/Recommended' make: *** [stamp-recommended] Error 2 I think that the source of package Matrix is where it is supposed to be so that I have no clues. Compilation and installation on the same machine with both the latest R devel (2.11.0) and the following version were successful > R.version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major 2 minor 10.0 year 2009 month 10 day26 svn rev50208 language R version.string R version 2.10.0 (2009-10-26) > Sys.getlocale() [1] "LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=C;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=C" for the moment we stay with r50208, any hints appreciated, thanks regards Simone -- __________ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make fails on R r50499 ( openSuSE 11.0 x86-64)
Thank you, now it works kind regards, Simone 2009/11/20 Prof Brian Ripley : > What has happened is that mgcv now depends on Matrix, but the author hasn't > told us that. Add to the line in src/library/Recommended/Makefile.in so it > becomes > > mgcv.ts: nlme.ts MASS.ts Matrix.ts > > and it should work. > > The tarballs will catch up in due course. > > On Fri, 20 Nov 2009, Simone Giannerini wrote: > >> Dear all, >> >> I encountered a problem when compiling the source of R patched 2.10.0 >> r50499 (19-11-2009) >> linked to ACML single threaded (4.2.0 or 4.3.0) >> OS: openSuSE 11.0 x86-64 >> >> make fails when it comes to installing mgcv with the following >> >> [snip] >> ** R >> ** inst >> ** preparing package for lazy loading >> Error in loadNamespace(i[[1L]], c(lib.loc, .libPaths())) : >> non esiste un pacchetto chiamato 'Matrix' >> package 'Matrix' does not exist ## TRANSLATED BY ME >> ERROR: lazy loading failed for package ‘mgcv’ >> * removing ‘/home/giannerini/Desktop/R-patched/library/mgcv’ >> make[2]: *** [mgcv.ts] Error 1 >> make[2]: Leaving directory >> `/home/giannerini/Desktop/R-patched/src/library/Recommended' >> make[1]: *** [recommended-packages] Error 2 >> make[1]: Leaving directory >> `/home/giannerini/Desktop/R-patched/src/library/Recommended' >> make: *** [stamp-recommended] Error 2 >> >> I think that the source of package Matrix is where it is supposed to >> be so that I have no clues. >> Compilation and installation on the same machine with both the latest >> R devel (2.11.0) and the following version were successful >>> >>> R.version >> >> _ >> platform x86_64-unknown-linux-gnu >> arch x86_64 >> os linux-gnu >> system x86_64, linux-gnu >> status >> major 2 >> minor 10.0 >> year 2009 >> month 10 >> day 26 >> svn rev 50208 >> language R >> version.string R version 2.10.0 (2009-10-26) >> >>> Sys.getlocale() >> >> [1] >> "LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=C;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=C" >> >> for the moment we stay with r50208, >> any hints appreciated, thanks >> >> regards >> >> Simone >> >> -- >> __ >> >> Simone Giannerini >> Dipartimento di Scienze Statistiche "Paolo Fortunati" >> Universita' di Bologna >> Via delle belle arti 41 - 40126 Bologna, ITALY >> Tel: +39 051 2098262 Fax: +39 051 232153 >> http://www2.stat.unibo.it/giannerini/ >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595 -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling Fortran90 code from R
Dear Hartwig,
I think there are many packages that use F90 code and you should really be
able to call it by following the advices in the R-exts
manual. There are no major differences with F77 and you do not need a C
wrapper. Maybe you might start with a simple example like this one.
start file foo.f90 ***
SUBROUTINE foo(X,M,N,S)
IMPLICIT NONE
integer:: M,N
real*8:: X(M,N),S
S = sum(X);
END SUBROUTINE foo
end file foo.f90 ***
compile:
gfortran -shared foo.f90 -o foo.so
open R
dyn.load("foo.so")
is.loaded("foo")
TRUE
m <- matrix(1,nrow=4,ncol=3)
storage.mode(m) <- "double"
S <- double(1)
.Fortran("foo",m,nrow(m),ncol(m),S)
[[1]]
[,1] [,2] [,3]
[1,]111
[2,]111
[3,]111
[4,]111
[[2]]
[1] 4
[[3]]
[1] 3
[[4]]
[1] 12
ciao
Simone
On Tue, Dec 29, 2009 at 10:26 AM, Hartwig Deneke
wrote:
> Dear all,
>
> I am currently trying to create a package wrapping Fortran90 code, the
> RRTMG radiative transfer model( http://rtweb.aer.com/rrtm_frame.html).
> I am doing this on a Linux workstation, with gcc/gfortran, in case
> this matters. The code heavily relies on F90 features, in particular
> modules, which seem to clash with R's assumptions for calling compiled
> code.
>
> What I have done:
> -compiled the files to mod/object files using gfortran
> -am able to create a dynamic link library "librrtmg.so"
>
> Further experiments:
> - dyn.load('librrtmg.so') works
> -. with "objdump -T librrtmg.so", I have found the following function
> symbols to call:
>1. __rrtmg_lw_init_MOD_rrtmg_lw_ini (the initialization of the code)
>2. __rrtmg_öw_rad_MOD_rrtmg_lw (the actual main function I want
> to call to do the calculations)
> - These symbols are found via "is.loaded", but only without specifying
> "type='FORTRAN'" (I have experimented with upper/lowercase letters as
> well as dropping the leading underscores)
> - I have not been able to call these routines via the ".Fortran" interface.
> - I do managed to call a simple F90 subroutine (with similar argument
> list, for experimentation) via the ".C" interface. However, I am not
> able to pass 2D field of type "DOUBLE", but always get a crash.
>
> Is there any official way for calling Fortran90 libraries which I
> missed (I have both searched through the documentation and this list)?
> Any advice how to go about this? My best idea at the moment seems to
> be to write a simple C wrapper for the Fortran routines, and call the
> wrapper from R. If needed, I can also post some code from my
> experiments. I'd actually like to get something which could be
> submitted to CRAN out of this (are there any other packages depending
> on Fortran90 code?)
>
> Thanks in advance for any help,
> Hartwig Deneke
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling Fortran90 code from R
Dear Hartwig,
glad to know you workarounded your problem, please see my comments
1. if put in a module, the exported symbol of the subroutines may change
with different compilers. Actually, they change for the same compiler in
different platforms. Please see the following
begin file try.f90 ***
MODULE TRY
CONTAINS
SUBROUTINE foo(X,M,N,S)
IMPLICIT NONE
integer:: M,N
real*8:: X(M,N),S
S = sum(X);
END SUBROUTINE foo
END MODULE TRY
end file try.f90 ***
under Win32 with the gfortran of Rtools 2.10 I get the following
gfortran try.f90 -shared -o try.so
nm try.so
[...]
6e841280 T ___try__foo
[...]
the exported symbol is different from yours
> dyn.load("try.so")
> is.loaded("__try__foo")
[1] TRUE
hence, I might be wrong but I am afraid that your code will not be portable.
2. you can avoid using modules by specifying explicit interfaces into the
subroutines that use other subroutines.This is what I do in my packages. I
understand it can be painful if you have to put your hands on big modules.
Kind regards
Simone
On Tue, Dec 29, 2009 at 1:44 PM, Hartwig Deneke wrote:
> 2009/12/29 Simone Giannerini :
> > Dear Hartwig,
> >
> > I think there are many packages that use F90 code and you should really
> be
> > able to call it by following the advices in the R-exts
> > manual. There are no major differences with F77 and you do not need a C
> > wrapper. Maybe you might start with a simple example like this one.
> >
> (helpful example removed)...
> > open R
> > dyn.load("foo.so")
> > is.loaded("foo")
> >
> > TRUE
> Dear Simone (and others reading),
>
> first of all thanks for your helpful example. While I did something
> similar yesterday, it did give me a simple example to start from which
> worked, and find a nice approach to solving my problems. A brief
> summary of the origin of my problems, which are related to the use of
> Fortran90 module declarations.
>
> It is perfectly possible to call Fortran90 code compiled with
> gfortran. Compiling a subroutine/function "foo" will produce a symbol
> "foo_" in the dynamic library. If, however, the subroutine is
> contained in a module named "modname", the symbol will be called
> "__modname_MOD_foo". In this case, it will not be found by the
> ".Fortran" call or a call to "is.loaded", at least I have not found
> any way to do this. However, for my purposes, I have simply added a
> set of wrapper subroutines to the library (which I planned to add
> anyway for other reasons, in particular to reduce the number of
> arguments), which forwards the calls to the module functions, and
> everything seems to work all right.
>
> Kind Regards,
> Hartwig
>
--
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is there any package on CRAN that uses Fortran-90/95
I use F95 code in some functions of the developement version of the package tseriesChaos but I must say we have encountered so many problems with the gfortran compiler (both on Win and Linux) that we are compelled to distribute at least the Win binaries separately. The new version of the package is not on CRAN yet but you may follow its development and download the F90 code here: http://code.google.com/p/tserieschaos/ Regards Simone On 2/26/07, Gorjanc Gregor <[EMAIL PROTECTED]> wrote: > Hi! > > Is there any package on CRAN that uses Fortran-90/95? I would like > to study it. > > Thanks, Gregor > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- ______ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] integrate function (PR#9557)
I think the behaviour is somehow documented, see ?integrate, in any case
I take the opportunity to report some more on integrate:
Under Win XP (AMD 64 3700+ 2Gb RAM)
> integrate(dnorm,0,2,sub=1e+09)
Error: cannot allocate vector of size 1889872 Kb
In addition: Warning messages:
1: Reached total allocation of 1536Mb: see help(memory.size)
2: Reached total allocation of 1536Mb: see help(memory.size)
> integrate(dnorm,0,2,sub=1e+10)
Error in if (limit < 1 || (abs.tol <= 0 && rel.tol < max(50 *
.Machine$double.eps, :
missing value where TRUE/FALSE needed
In addition: Warning message:
NAs introduced by coercion
but .
> integrate(dnorm,0,2,sub=1e+08)
crashes the RGUI with an access violation error
> R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 4.1
year 2006
month 12
day18
svn rev40228
language R
version.string R version 2.4.1 (2006-12-18)
*
Under LINUX SUSE 10.2 (Quad Opteron 8218 32Gb RAM)
> integrate(dnorm,0,2,sub=1e+08)
0.4772499 with absolute error < 5.3e-15
> integrate(dnorm,0,2,sub=1e+09)
*** caught segfault ***
address (nil), cause 'memory not mapped'
Traceback:
1: .External("call_dqags", ff, rho = environment(), as.double(lower),
as.double(upper), as.double(abs.tol), as.double(rel.tol),
limit = limit, PACKAGE = "base")
2: integrate(dnorm, 0, 2, sub = 1e+09)
> R.version
_
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 2
minor 4.1
year 2006
month 12
day18
svn rev40228
language R
version.string R version 2.4.1 (2006-12-18)
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
__
On 3/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Full_Name: Bert De Boeck
> Version: R 2.2.0
> OS: Windows
> Submission from: (NULL) (157.193.193.152)
>
>
> I think there is a bug when using integrate for integrating a function which
> is
> 0 in a whole sub-interval. For example:
>
> #define uniform function
> f<-function(x){ifelse(x<1,0,ifelse(x<3,1,0))}
>
> #this is the correct integral
> integrate(f,-10,10)
>
> #here there is a problem
> integrate(f,-50,50)
> integrate(f,-10,50)
> integrate(f,-50,10)
> integrate(f,-50,50,sub=1)
>
> # I noticed this for a more complex function, but as you see even for a
> trivial
>
> # function there is a serious problem
>
> __________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] is.loaded() and dyn.load()
Dear all,
I am puzzled at the behaviour of is.loaded() when a dyn.load() call to a a
FORTRAN shared library is included in a file to be sourced.
A reproducible example is the following:
1. the attached fortran subroutine try_it.f90 performs a summation of the
elements of a REAL*8 vector
compile with
gfortran try_it.f90 -shared -s -otry_it.dll
2. create a file to be sourced (see the attached try_it.R) containing the
following commands:
BEGIN try_it.R
dyn.load("try_it.dll");
try.it <- function(X){
N <- length(X);
S <- .Fortran("try_it_",as.double(X),as.integer(N),S=as.double(0))$S
return(S)
}
END try_it.R
3. Switch to R
source("try_it.R")
try.it(1:10)
Error in .Fortran("try_it_", as.double(X), as.integer(N), S = as.double(0))
:
Fortran symbol name "try_it_" not in load table
is.loaded("try_it_")
[1] TRUE
try.it(1:10)
[1] 55
it looks like is.loaded() triggers the loading, inserting
is.loaded("try_it_")in
the file try_it.R does the trick but
is this behaviour expected?
Thank you,
Regards
Simone
R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 4.1
year 2006
month 12
day18
svn rev40228
language R
version.string R version 2.4.1 (2006-12-18)
--
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
__
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.loaded() and dyn.load()
Your aggressive tone would be inacceptable even if your comments were
relevant.
What's more they are not.
The point here is that under Windows it is very likely that fortran
compiled code is not being properly loaded unless g77 is used, and that
is.loaded() would trigger the dynamic loading. It is neither a matter of
underscores in variable names nor of fixed form f77.
see the example below
I attach the FORTRAN 77 fixed form source file tryme.f which has been
compiled with Compaq Visual Fortran 6.6c3
# df tryme.f -dll -LINK -RELEASE
then, under R
dyn.load("tryme.dll");
try.me <- function(X){
S <- .Fortran("tryme",as.integer(X),S=as.integer(0))$S #
return(S)
}
try.me(8)
Error in .Fortran("tryme", as.integer(X), S = as.integer(0)) :
Fortran symbol name "tryme" not in load table
is.loaded("tryme")
[1] TRUE
try.me(8)
[1] 9
The problem does not show up if g77 is used:
# g77 tryme.f -shared -s -otryme.dll
dyn.load("tryme.dll");
try.me(8)
[1] 9
The issue does not show up in my OpenSUSE 10.2 box with R patched compiled
with gfortran;
dyn.load("tryme.dll");
try.me <- function(X){
+ S <- .Fortran("tryme",as.integer(X),S=as.integer(0))$S
+ return(S)
+ }
try.me(8)
[1] 9
unlist(R.Version())
platform
"x86_64-unknown-linux-gnu"
arch
"x86_64"
os
"linux-gnu"
system
"x86_64, linux-gnu"
status
"Patched"
major
"2"
minor
"4.1"
year
"2007"
month
"03"
day
"20"
svn rev
"40858"
language
"R"
version.string
"R version 2.4.1 Patched (2007-03-20 r40858)"
All this regardless of the kind of Fortran language used and independently
from the presence of underscores in variable names.
Besided this IMHO it might be interesting to discuss in this list the issues
related to Fortran 90/95 and the use of different compilers in view of a
possible complete support from R also considered that
1. under Linux gfortan is now the default compiler for gcc>4.0.0
2. switching back to F77 might **not** be an option for many people.
My intention here was also to provide the community with some feedback on
this but it is hard to have a proper discussion
in these conditions.
Kind regards,
Simone Giannerini
On 4/5/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
Did you read the comments under ?.Fortran about this? What you are doing
is quite explicitly said not to be supported.
gfortran is not a supported Fortran compiler for R for Windows 2.4.1.
It behaves differently from the supported g77.
The behaviour is adapted to the compiler used when configure is used, and
on Windows that is what the maintainers used, not you are using. If you
follow the advice not to use underscores in names you are much less likely
to confuse yourself and produce portable code.
On Thu, 5 Apr 2007, Simone Giannerini wrote:
> Dear all,
>
> I am puzzled at the behaviour of is.loaded() when a dyn.load() call to a
a
> FORTRAN shared library is included in a file to be sourced.
> A reproducible example is the following:
>
> 1. the attached fortran subroutine try_it.f90 performs a summation of
the
> elements of a REAL*8 vector
> compile with
>
> gfortran try_it.f90 -shared -s -otry_it.dll
>
> 2. create a file to be sourced (see the attached try_it.R) containing
the
> following commands:
>
> BEGIN try_it.R
> dyn.load("try_it.dll");
>
>
> try.it <- function(X){
> N <- length(X);
> S <- .Fortran("try_it_",as.double(X),as.integer(N),S=as.double(0))$S
> return(S)
> }
> END try_it.R
>
>
> 3. Switch to R
>
>> source("try_it.R")
>> try.it(1:10)
> Error in .Fortran("try_it_", as.double(X), as.integer(N), S = as.double
(0))
> :
> F
[Rd] fix() changes the class of mts objects
Dear all, it looks like fix() changes the class of mts objects, here is a reproducible example (tested both on WinXP and Linux): > x <- ts(cbind(1:5,1:5)) > x Time Series: Start = 1 End = 5 Frequency = 1 Series 1 Series 2 111 222 333 444 555 > class(x) [1] "mts" "ts" > edit(x) Series 1 Series 2 [1,]11 [2,]22 [3,]33 [4,]44 [5,]55 > class(x) [1] "mts" "ts" > fix(x) > class(x) [1] "matrix" > x Series 1 Series 2 [1,]11 [2,]22 [3,]33 [4,]44 [5,]55 > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 5.0 year 2007 month 04 day23 svn rev41293 language R version.string R version 2.5.0 (2007-04-23) > R.version platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major 2 minor 5.0 year 2007 month 04 day23 svn rev41293 language R version.string R version 2.5.0 (2007-04-23) __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] fix() changes the class of mts objects
My concern here is that users can be confused from the fact that if one has a single time series fix() uses the default method of edit() and does not change its class > x <- ts(1:5) > fix(x) > class(x) [1] "ts" whereas for mts objects edit.data.frame is used so that in my opinion it might be worth to clarify it in the documentation. Regards Simone On 5/9/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > > Why did you expect otherwise?: fix() is treating it as matrix and > ?edit.matrix says that it only works on 'simple data frames' (and converts > matrices to such). > > Editing R objects can easily change aspects of them, as dput() is not > faithful, environments can get lost and so on. > > On Wed, 9 May 2007, Simone Giannerini wrote: > > > Dear all, > > > > it looks like fix() changes the class of mts objects, here is a > reproducible > > example (tested both on WinXP and Linux): > > > >> x <- ts(cbind(1:5,1:5)) > >> x > > Time Series: > > Start = 1 > > End = 5 > > Frequency = 1 > > Series 1 Series 2 > > 111 > > 222 > > 333 > > 444 > > 555 > >> class(x) > > [1] "mts" "ts" > >> edit(x) > > Series 1 Series 2 > > [1,]11 > > [2,]22 > > [3,]33 > > [4,]44 > > [5,]55 > >> class(x) > > [1] "mts" "ts" > >> fix(x) > >> class(x) > > [1] "matrix" > >> x > > Series 1 Series 2 > > [1,]11 > > [2,]22 > > [3,]33 > > [4,]44 > > [5,]55 > > > >> R.version > > _ > > platform i386-pc-mingw32 > > arch i386 > > os mingw32 > > system i386, mingw32 > > status > > major 2 > > minor 5.0 > > year 2007 > > month 04 > > day23 > > svn rev41293 > > language R > > version.string R version 2.5.0 (2007-04-23) > > > >> R.version > > platform x86_64-unknown-linux-gnu > > arch x86_64 > > os linux-gnu > > system x86_64, linux-gnu > > status > > major 2 > > minor 5.0 > > year 2007 > > month 04 > > day23 > > svn rev41293 > > language R > > version.string R version 2.5.0 (2007-04-23) > > > > __ > > > > Simone Giannerini > > Dipartimento di Scienze Statistiche "Paolo Fortunati" > > Universita' di Bologna > > Via delle belle arti 41 - 40126 Bologna, ITALY > > Tel: +39 051 2098262 Fax: +39 051 232153 > > ______ > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] fix() changes the class of mts objects
I think that a simple statement mentioning the issue in the documentation of fix() would be helpful. regards Simone On 5/9/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > > On Wed, 9 May 2007, Simone Giannerini wrote: > > > My concern here is that users can be confused from the fact that if one > has > > a single time series fix() uses the default method of edit() and does > not > > change > > its class > > > >> x <- ts(1:5) > >> fix(x) > >> class(x) > > [1] "ts" > > > > whereas for mts objects edit.data.frame is used so that in my opinion it > > might be worth to clarify it in the documentation. > > Which documentation do you suggest? That vectors and matrices are treated > differently is there. > > > > > Regards > > > > Simone > > > > On 5/9/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > >> > >> Why did you expect otherwise?: fix() is treating it as matrix and > >> ?edit.matrix says that it only works on 'simple data frames' (and > converts > >> matrices to such). > >> > >> Editing R objects can easily change aspects of them, as dput() is not > >> faithful, environments can get lost and so on. > >> > >> On Wed, 9 May 2007, Simone Giannerini wrote: > >> > >> > Dear all, > >> > > >> > it looks like fix() changes the class of mts objects, here is a > >> reproducible > >> > example (tested both on WinXP and Linux): > >> > > >> >> x <- ts(cbind(1:5,1:5)) > >> >> x > >> > Time Series: > >> > Start = 1 > >> > End = 5 > >> > Frequency = 1 > >> > Series 1 Series 2 > >> > 111 > >> > 222 > >> > 333 > >> > 444 > >> > 555 > >> >> class(x) > >> > [1] "mts" "ts" > >> >> edit(x) > >> > Series 1 Series 2 > >> > [1,]11 > >> > [2,]22 > >> > [3,]33 > >> > [4,]44 > >> > [5,]55 > >> >> class(x) > >> > [1] "mts" "ts" > >> >> fix(x) > >> >> class(x) > >> > [1] "matrix" > >> >> x > >> > Series 1 Series 2 > >> > [1,]11 > >> > [2,]22 > >> > [3,]33 > >> > [4,]44 > >> > [5,]55 > >> > > >> >> R.version > >> > _ > >> > platform i386-pc-mingw32 > >> > arch i386 > >> > os mingw32 > >> > system i386, mingw32 > >> > status > >> > major 2 > >> > minor 5.0 > >> > year 2007 > >> > month 04 > >> > day23 > >> > svn rev41293 > >> > language R > >> > version.string R version 2.5.0 (2007-04-23) > >> > > >> >> R.version > >> > platform x86_64-unknown-linux-gnu > >> > arch x86_64 > >> > os linux-gnu > >> > system x86_64, linux-gnu > >> > status > >> > major 2 > >> > minor 5.0 > >> > year 2007 > >> > month 04 > >> > day23 > >> > svn rev41293 > >> > language R > >> > version.string R version 2.5.0 (2007-04-23) > >> > > >> > __ > >> > > >> > Simone Giannerini > >> > Dipartimento di Scienze Statistiche "Paolo Fortunati" > >> > Universita' di Bologna > >> > Via delle belle arti 41 - 40126 Bologna, ITALY > >> > Tel: +39 051 2098262 Fax: +39 051 232153 > >> > __ > >> > > >> > [[alternative HTML version deleted]] > >> > > >> > __ > >> > R-devel@r-project.org mailing list > >> > https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > >> > >> -- > >> Brian D. Ripley, [EMAIL PROTECTED] > >> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > >> University of Oxford, Tel: +44 1865 272861 (self) > >> 1 South Parks Road, +44 1865 272866 (PA) > >> Oxford OX1 3TG, UKFax: +44 1865 272595 > >> > > > > > > > > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] partial correlation function for multivariate time series
Dear all, I found the following behaviour with pacf() in the multivariate case, set.seed(10) x <- rnorm(1000,sd=1) y <- rnorm(1000,sd=1) pacf(ts(cbind(x,y)),plot=FALSE,lag.max=10) Partial autocorrelations of series 'cbind(x, y)', by lag , , x x y 0.047 ( 1)0.000 ( -1) 0.011 ( 2)0.000 ( -2) 0.005 ( 3)0.000 ( -3) 0.013 ( 4)0.000 ( -4) 0.050 ( 5)0.000 ( -5) 0.034 ( 6)0.000 ( -6) 0.026 ( 7)0.000 ( -7) -0.029 ( 8)0.000 ( -8) -0.010 ( 9)0.000 ( -9) -0.013 ( 10)0.000 (-10) , , y x y 374.052 ( 1) -0.045 ( 1) 66.717 ( 2) -0.024 ( 2) -535.810 ( 3) -0.031 ( 3) 120.802 ( 4) -0.020 ( 4) 142.824 ( 5)0.004 ( 5) -211.711 ( 6) -0.010 ( 6) 201.856 ( 7)0.058 ( 7) 286.079 ( 8) -0.035 ( 8) -134.057 ( 9)0.032 ( 9) -18.200 ( 10)0.019 ( 10) Since there are multiple ways of defining the pacf for multivariate time series (see e.g. G.C. Reinsel, Elements of multivariate time series analysis, II edition, Springer, section 3.3) and given that in ?pacf there is no reference to articles or books regarding its computation I do not know whether this behaviour is expected or it is a bug instead. In the first case could you provide a reference for it? In the second case I might file a bug report. Thank you for the great work you are doing for the scientific community. kind regards, Simone Giannerini WINDOWS platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 5.1 year 2007 month 06 day27 svn rev42083 language R version.string R version 2.5.1 (2007-06-27) LINUX > R.Version() $platform [1] "x86_64-unknown-linux-gnu" $arch [1] "x86_64" $os [1] "linux-gnu" $system [1] "x86_64, linux-gnu" $status [1] "" $major [1] "2" $minor [1] "5.1" $year [1] "2007" $month [1] "06" $day [1] "27" $`svn rev` [1] "42083" $language [1] "R" $version.string [1] "R version 2.5.1 (2007-06-27)" -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in ?kernel
in the example section (line -2 from the bottom) Brockwell and Davies should be Brockwell and Davis Regards, Simone __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] partial correlation function for multivariate time series
Dear Paul,
there is no mention to the pacf in the multivariate setting in the book you
suggested.
As I mentioned in private I suspect that pacf() in the multivariate case
computes the
partial autoregression matrix (in the terminology of Reinsel) rather than
the partial autocorrelation matrix
as the two coincide in the univariate case but are different in the
multivariate case as stated explicitly
in Reisel (Sec. 3.3).
This would explain the coefficients well above 1 (in modulus) in the example
I have given.
To support my statement you can fit A VAR model to the data and compare the
coefficients with the results
from pacf():
set.seed(10)
x <- rnorm(1000,sd=1)
y <- rnorm(1000,sd=1)
library(vars);
mod1 <- VAR(ts(cbind(x,y)),p=4,type="none"); # fit a VAR (OLS)
## Have a look at estimated coefficients
> noquote(formatC(mod1$varresult$x$coefficients,format="f"))
## Edited by me, compare with the first column of the results below from the
pacf (pacf()$acf[,1,])
x.l1 x.l2x.l3x.l4
0.0470.013 0.004 0.014
y.l1 y.l2y.l3y.l4
374.117 72.758 -526.452 126.610
> noquote(formatC(mod1$varresult$y$coefficients,format="f"))
## Edited by me, compare with the second column of the results below from
the pacf (pacf()$acf[,2,])
x.l1x.l2 x.l3x.l4
0.000 -0.000 0.000 0.000
y.l1y.l2 y.l3y.l4
-0.046 -0.025 -0.033 -0.020
pacf(ts(cbind(x,y)),plot=FALSE,lag.max=4)
Partial autocorrelations of series 'ts(cbind(x, y))', by lag
, , x
x y
0.047 ( 1)0.000 (-1)
0.011 ( 2)0.000 (-2)
0.005 ( 3)0.000 (-3)
0.013 ( 4)0.000 (-4)
, , y
x y
374.052 ( 1) -0.045 ( 1)
66.717 ( 2) -0.024 ( 2)
-535.810 ( 3) -0.031 ( 3)
120.802 ( 4) -0.020 ( 4)
As you can see the coefficients fairly agree.
I might file a bug report in some days unless someone will prove me wrong
before.
Regards,
Simone
On 11/09/2007, Paul Gilbert <[EMAIL PROTECTED]> wrote:
>
> I think the reference for pacf is
>
> @BOOK{GraNew77,
>author ={Granger, C. W. J. and Newbold, Paul},
>title = {Forecasting Economic Time Series},
>publisher = {Academic Press},
>year = 1977
>}
>
> It certainly would not be Reisel's book, as parts of the code predate
> that by many years.
>
> Paul Gilbert
>
> Simone Giannerini wrote:
> > Dear all,
> >
> > I found the following behaviour with pacf() in the multivariate case,
> >
> > set.seed(10)
> > x <- rnorm(1000,sd=1)
> > y <- rnorm(1000,sd=1)
> > pacf(ts(cbind(x,y)),plot=FALSE,lag.max=10)
> >
> > Partial autocorrelations of series 'cbind(x, y)', by lag
> >
> > , , x
> >
> > x y
> > 0.047 ( 1)0.000 ( -1)
> > 0.011 ( 2)0.000 ( -2)
> > 0.005 ( 3)0.000 ( -3)
> > 0.013 ( 4)0.000 ( -4)
> > 0.050 ( 5)0.000 ( -5)
> > 0.034 ( 6)0.000 ( -6)
> > 0.026 ( 7)0.000 ( -7)
> >-0.029 ( 8)0.000 ( -8)
> >-0.010 ( 9)0.000 ( -9)
> >-0.013 ( 10)0.000 (-10)
> >
> > , , y
> >
> > x y
> > 374.052 ( 1) -0.045 ( 1)
> >66.717 ( 2) -0.024 ( 2)
> > -535.810 ( 3) -0.031 ( 3)
> > 120.802 ( 4) -0.020 ( 4)
> > 142.824 ( 5)0.004 ( 5)
> > -211.711 ( 6) -0.010 ( 6)
> > 201.856 ( 7)0.058 ( 7)
> > 286.079 ( 8) -0.035 ( 8)
> > -134.057 ( 9)0.032 ( 9)
> > -18.200 ( 10)0.019 ( 10)
> >
> > Since there are multiple ways of defining the pacf for multivariate time
> > series
> > (see e.g. G.C. Reinsel, Elements of multivariate time series analysis,
> II
> > edition, Springer, section 3.3) and given that
> > in ?pacf there is no reference to articles or books regarding its
> > computation
> > I do not know whether this behaviour is expected or it is a bug instead.
> > In the first case could you provide a reference for it? In the second
> case I
> > might file a bug report.
> > Thank you for the great work you are doing for the scientific community.
> >
> > kind regards,
> >
> > Simone Giannerini
> >
> > WINDOWS
> >
> > platform i386-pc-mingw32
> > arch i386
> > os mingw32
> > system i386, mingw32
> > status
> > major 2
> > minor 5.1
> > year 2007
> > month 06
> > day27
> > svn rev42083
> > language
Re: [Rd] Reciprocal Mill's Ratio
Dear Murray, I think you might have to update R in first instance and provide a reproducible example in second place so that people might help you. Regards, Simone On 13/09/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I believe that this may be more appropriate here in r-devel than in > r-help. > > The normal hazard function, or reciprocal Mill's Ratio, may be obtained > in R as dnorm(z)/(1 - pnorm(z)) or, better, as dnorm(z)/pnorm(-z) for > small values of z. The latter formula breaks dowm numerically for me > (running R 2.4.1 under Windows XP 5.1 SP 2) for values of z near 37.4 > or greater. > > Looking at the pnorm documentation I see that it is based on Cody (1993) > and thence, going one step further back, on Cody (1969). Consulting > Cody (1969) I see that the algorithm for pnorm(z) [or actually erf(z)] > is actually based on rational function approximations for the > reciprocal Mill's ratio itself, as I rather expected. > > I wonder if anyone has dug out a function for the reciprocal Mill's > ratio out of the pnorm() code? Anticipating the obvious response I don't > believe that this would be one of the things I might be good at! > > Murray Jorgensen > > References > > Cody, W. D. (1993) > Algorithm 715: SPECFUN A portable FORTRAN package of special function > routines and test drivers. > ACM Transactions on Mathematical Software 19, 2232. > > Cody, W. D. (1969) > Rational Chebyshev Approximations for the Error Function > Mathematics of Computation, Vol. 23, No. 107. (Jul., 1969), pp. 631-637. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] partial correlation function for multivariate time series
Dear Paul,
thanks for the reply,
On 14/09/2007, Paul Gilbert <[EMAIL PROTECTED]> wrote:
>
> Simone Giannerini wrote:
> > Dear Paul,
> >
> > there is no mention to the pacf in the multivariate setting in the book
> > you suggested.
>
> My apologies, I should have looked more carefully and realized the pacf
> discussion in Granger and Newbold is all univariate.
>
> > As I mentioned in private I suspect that pacf() in the multivariate case
> > computes the
> > partial autoregression matrix (in the terminology of Reinsel) rather
> > than the partial autocorrelation matrix
>
> It looks like pacf() uses the calculation in stats:::ar.yw.default , so
> roughly sounds consistent with what you say. I do think parts of this
> code pre-date Reisel's book, so inconsistency with his book would
> probably be imperfect foresight.
>
> BTW, I think bug reports with suggested fixes are usually more useful.
> And, at the very least, it seems the references in the documentation
> could be improved.
Yes, my intention is to have a look at a way to fix the problem once the
problem has been recognized as such.
I did not have a look at the source code yet but if it is C I am afraid I
won't be able to go very far as I use fortran instead.
Regards,
Simone
Paul Gilbert
>
> > as the two coincide in the univariate case but are different in the
> > multivariate case as stated explicitly
> > in Reisel (Sec. 3.3).
> > This would explain the coefficients well above 1 (in modulus) in the
> > example I have given.
> > To support my statement you can fit A VAR model to the data and compare
> > the coefficients with the results
> > from pacf():
> >
> > set.seed(10)
> > x <- rnorm(1000,sd=1)
> > y <- rnorm(1000,sd=1)
> >
> > library(vars);
> > mod1 <- VAR(ts(cbind(x,y)),p=4,type="none"); # fit a VAR (OLS)
> >
> > ## Have a look at estimated coefficients
> >
> >> noquote(formatC(mod1$varresult$x$coefficients,format="f"))
> > ## Edited by me, compare with the first column of the results below from
> > the pacf (pacf()$acf[,1,])
> > x.l1 x.l2x.l3x.l4
> > 0.0470.013 0.004 0.014
> > y.l1 y.l2y.l3y.l4
> > 374.117 72.758 -526.452 126.610
> >> noquote(formatC(mod1$varresult$y$coefficients,format="f"))
> > ## Edited by me, compare with the second column of the results below
> > from the pacf (pacf()$acf[,2,])
> > x.l1x.l2 x.l3x.l4
> > 0.000 -0.000 0.000 0.000
> > y.l1y.l2 y.l3y.l4
> > -0.046 -0.025 -0.033 -0.020
> >
> > pacf(ts(cbind(x,y)),plot=FALSE,lag.max=4)
> >
> > Partial autocorrelations of series 'ts(cbind(x, y))', by lag
> >
> > , , x
> >
> > x y
> > 0.047 ( 1)0.000 (-1)
> > 0.011 ( 2)0.000 (-2)
> > 0.005 ( 3)0.000 (-3)
> > 0.013 ( 4)0.000 (-4)
> >
> > , , y
> >
> > x y
> > 374.052 ( 1) -0.045 ( 1)
> >66.717 ( 2) -0.024 ( 2)
> > -535.810 ( 3) -0.031 ( 3)
> > 120.802 ( 4) -0.020 ( 4)
> >
> > As you can see the coefficients fairly agree.
> > I might file a bug report in some days unless someone will prove me
> > wrong before.
> >
> > Regards,
> >
> > Simone
> >
> >
> >
> > On 11/09/2007, *Paul Gilbert* <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > I think the reference for pacf is
> >
> > @BOOK{GraNew77,
> >author ={Granger, C. W. J. and Newbold, Paul},
> >title = {Forecasting Economic Time Series},
> >publisher = {Academic Press},
> >year = 1977
> >}
> >
> > It certainly would not be Reisel's book, as parts of the code
> predate
> > that by many years.
> >
> > Paul Gilbert
> >
> > Simone Giannerini wrote:
> > > Dear all,
> > >
> > > I found the following behaviour with pacf() in the multivariate
> > case,
> > >
> > > set.seed(10)
> > > x <- rnorm(1000,sd=1)
> > > y <- rnorm(1000,sd=1)
> > > pacf(ts(cbind(x,y)),plot=FALSE,lag.max=10)
> > >
> > > Partial autocorrelations of series 'cbind(x, y)', by lag
> > >
> > > , , x
> > >
> > > x y
> > >
Re: [Rd] corMatrix crashes with corARMA structure (PR#9952)
This is what I get on R 2.6.0, Win XP ciao Simone P.S. you have posted twice > n <- 100 > > # example from Box and Jenkins p. 83 > arcoefs <- c(0.8) > macoefs <- c(-0.6) > p <- length(arcoefs) > q <- length(macoefs) > > require(nlme) > tmp <- corARMA(value=c(arcoefs,macoefs), form=~1, p=p, q=q) > Sigma <- corMatrix(tmp, covariate = 1:n) # segfault Error in corMatrix.corARMA(tmp, covariate = 1:n) : 'object' has not been Initialize()d > noquote(unlist(R.Version())) platform arch os system i386-pc-mingw32 i386 mingw32i386, mingw32 status majorminor year 2 6.0 2007 month day svn rev language 10 0343063R version.string R version 2.6.0 (2007-10-03) > On 10/10/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Full_Name: Benjamin Tyner > Version: 2.6.0 RC 2007-10-01 r43043 > OS: WinXP > Submission from: (NULL) (171.161.224.10) > > > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status RC > major 2 > minor 6.0 > year 2007 > month 10 > day01 > svn rev43043 > language R > version.string R version 2.6.0 RC (2007-10-01 r43043) > > I have seen this in other versions/platforms as well. Brian Ripley informs > me > the segfault is in corStruct.c > > Code to reproduce: > > n <- 100 > > # example from Box and Jenkins p. 83 > arcoefs <- c(0.8) > macoefs <- c(-0.6) > p <- length(arcoefs) > q <- length(macoefs) > > require(nlme) > tmp <- corARMA(value=c(arcoefs,macoefs), form=~1, p=p, q=q) > Sigma <- corMatrix(tmp, covariate = 1:n) # segfault > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
I have experienced the same behaviour (intermittently) on two different WinXP machines. Also savePlot() appears to be affected but not postscript() nor pdf() as you mentioned. On 11/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Full_Name: Jane L. Harvill > Version: 2.6.0 > OS: Microsoft Windows XP Professional, Version 2002, Service Pack 2 > Submission from: (NULL) (129.62.21.93) > > > PROBLEM: The ability to save the contents of an R Graphics window as a > postscript or PDf file through the drop-down menu (File -> Save As -> > Postscript, or File -> Save As -> PDF) results in the error message below > being > printed to the R Console. > > ERROR MESSAGE: > - > Error: Invalid font type > In addition: Warning messages: > 1: font family not found in PostScript font database > 2: font family not found in PostScript font database > > > > - > > TO RECREATE THE PROBLEM: > 1. Using the R Console, create some graph in R; for example, > plot(rnorm(100)). > 2. Select File -> Save As -> PostScript (or File -> Save As -> PDF). > 3. Supply a file name and click the "Save" button. > > FOUR OTHER RELEVANT NOTES: > 1. I checked to see if the same error results when invoking the functions > pdf(file=...) or postscript(file=...). No error results, and the content of > the output (.ps or .pdf) file produces a duplicate of what appears in the R > Graphics window. > > 2. I checked, but did not see any other bug reports in the system that are > relevant to this problem. > > 3. Before I submitted this R Bug Report, I reinstalled the PostScript fonts, > and then reinstalled R Version 2.6.0. This did not change the outcome. > > 4. This problem did not exist in previous versions of R on any of my > computers. > It exists on all computers for version 2.6.0 of R. > > __________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
I looked at the list of bug fixes before writing and I found that the only thing close to it is this o postscript() was not always ignoring .Postscript.Options in the workspace (where it should not have occurred). but I must admit I did not understand whether it had anything to do with this bug report. Thanks Simone On 11/6/07, Uwe Ligges <[EMAIL PROTECTED]> wrote: > This has been reported several times before and has been fixed in > R-patched some weeks ago. > > Uwe Ligges > > > [EMAIL PROTECTED] wrote: > > Full_Name: Jane L. Harvill > > Version: 2.6.0 > > OS: Microsoft Windows XP Professional, Version 2002, Service Pack 2 > > Submission from: (NULL) (129.62.21.93) > > > > > > PROBLEM: The ability to save the contents of an R Graphics window as a > > postscript or PDf file through the drop-down menu (File -> Save As -> > > Postscript, or File -> Save As -> PDF) results in the error message below > > being > > printed to the R Console. > > > > ERROR MESSAGE: > > - > > Error: Invalid font type > > In addition: Warning messages: > > 1: font family not found in PostScript font database > > 2: font family not found in PostScript font database > > - > > > > TO RECREATE THE PROBLEM: > > 1. Using the R Console, create some graph in R; for example, > > plot(rnorm(100)). > > 2. Select File -> Save As -> PostScript (or File -> Save As -> PDF). > > 3. Supply a file name and click the "Save" button. > > > > FOUR OTHER RELEVANT NOTES: > > 1. I checked to see if the same error results when invoking the functions > > pdf(file=...) or postscript(file=...). No error results, and the content > > of > > the output (.ps or .pdf) file produces a duplicate of what appears in the R > > Graphics window. > > > > 2. I checked, but did not see any other bug reports in the system that are > > relevant to this problem. > > > > 3. Before I submitted this R Bug Report, I reinstalled the PostScript > > fonts, > > and then reinstalled R Version 2.6.0. This did not change the outcome. > > > > 4. This problem did not exist in previous versions of R on any of my > > computers. > > It exists on all computers for version 2.6.0 of R. > > > > ______ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
Thank you, I am sorry for my positive contribution to the entropy of R lists ... I missed the fact that somewhere there is a separate list of Windows specific bug fixes. Maybe it would be useful that this list be put in evidence close to the other one. Kind regards Simone On 11/6/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Tue, 6 Nov 2007, Simone Giannerini wrote: > > > I looked at the list of bug fixes before writing and I found that the > > only thing close to it is this > > > > o postscript() was not always ignoring .Postscript.Options in > > the workspace (where it should not have occurred). > > > > but I must admit I did not understand whether it had anything to do > > with this bug report. > > It occurs on Windows only, and the src/gnuwin32/CHANGES file says > > BUG FIXES > > o Saving a plot to Postscript or PDF required the font database > to have been initialized: this is now done if necessary. > > See also > > https://mailman.stat.ethz.ch/pipermail/r-help/2007-October/142414.html > > (over a month ago). > > > > > Thanks > > > > Simone > > > > On 11/6/07, Uwe Ligges <[EMAIL PROTECTED]> wrote: > >> This has been reported several times before and has been fixed in > >> R-patched some weeks ago. > >> > >> Uwe Ligges > >> > >> > >> [EMAIL PROTECTED] wrote: > >>> Full_Name: Jane L. Harvill > >>> Version: 2.6.0 > >>> OS: Microsoft Windows XP Professional, Version 2002, Service Pack 2 > >>> Submission from: (NULL) (129.62.21.93) > >>> > >>> > >>> PROBLEM: The ability to save the contents of an R Graphics window as a > >>> postscript or PDf file through the drop-down menu (File -> Save As -> > >>> Postscript, or File -> Save As -> PDF) results in the error message below > >>> being > >>> printed to the R Console. > >>> > >>> ERROR MESSAGE: > >>> - > >>> Error: Invalid font type > >>> In addition: Warning messages: > >>> 1: font family not found in PostScript font database > >>> 2: font family not found in PostScript font database > >>> - > >>> > >>> TO RECREATE THE PROBLEM: > >>> 1. Using the R Console, create some graph in R; for example, > >>> plot(rnorm(100)). > >>> 2. Select File -> Save As -> PostScript (or File -> Save As -> PDF). > >>> 3. Supply a file name and click the "Save" button. > >>> > >>> FOUR OTHER RELEVANT NOTES: > >>> 1. I checked to see if the same error results when invoking the functions > >>> pdf(file=...) or postscript(file=...). No error results, and the > >>> content of > >>> the output (.ps or .pdf) file produces a duplicate of what appears in the > >>> R > >>> Graphics window. > >>> > >>> 2. I checked, but did not see any other bug reports in the system that > >>> are > >>> relevant to this problem. > >>> > >>> 3. Before I submitted this R Bug Report, I reinstalled the PostScript > >>> fonts, > >>> and then reinstalled R Version 2.6.0. This did not change the outcome. > >>> > >>> 4. This problem did not exist in previous versions of R on any of my > >>> computers. > >>> It exists on all computers for version 2.6.0 of R. > >>> > >>> __ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > > > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving Graphics File as .ps or .pdf (PR#10403)
[snip] > Maybe, but given the way things have been working lately, it might be > better to emphasize > > (a) check the mailinglists > (b) try R-patched > (c) if in doubt, ask, rather than report as bug > > (Ideally, people would try the prerelease versions and problems like > this would be caught before the actual release, but it seems that they > prefer treating x.y.0 as a beta release...) > I am sorry but I do not agree with point (b) for the very simple fact that the average Windows user do not know how to compile the source code and might not even want to learn how to do it. The point is that since (if I am correct) the great majority of R users go Windows you would miss an important part of potential bug reports by requiring point (b) whereas (a) and (c) would suffice IMHO. Maybe if there were Win binaries of the prerelease version available some time before the release you would get much more feedback but I am just guessing. Regards Simone > > > > > On 11/6/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > > > >> On Tue, 6 Nov 2007, Simone Giannerini wrote: > >> > >> > >>> I looked at the list of bug fixes before writing and I found that the > >>> only thing close to it is this > >>> > >>> o postscript() was not always ignoring .Postscript.Options in > >>> the workspace (where it should not have occurred). > >>> > >>> but I must admit I did not understand whether it had anything to do > >>> with this bug report. > >>> > >> It occurs on Windows only, and the src/gnuwin32/CHANGES file says > >> > >> BUG FIXES > >> > >> o Saving a plot to Postscript or PDF required the font database > >> to have been initialized: this is now done if necessary. > >> > >> See also > >> > >> https://mailman.stat.ethz.ch/pipermail/r-help/2007-October/142414.html > >> > >> (over a month ago). > >> > >> > >>> Thanks > >>> > >>> Simone > >>> > >>> On 11/6/07, Uwe Ligges <[EMAIL PROTECTED]> wrote: > >>> > >>>> This has been reported several times before and has been fixed in > >>>> R-patched some weeks ago. > >>>> > >>>> Uwe Ligges > >>>> > >>>> > >>>> [EMAIL PROTECTED] wrote: > >>>> > >>>>> Full_Name: Jane L. Harvill > >>>>> Version: 2.6.0 > >>>>> OS: Microsoft Windows XP Professional, Version 2002, Service Pack 2 > >>>>> Submission from: (NULL) (129.62.21.93) > >>>>> > >>>>> > >>>>> PROBLEM: The ability to save the contents of an R Graphics window as a > >>>>> postscript or PDf file through the drop-down menu (File -> Save As -> > >>>>> Postscript, or File -> Save As -> PDF) results in the error message > >>>>> below being > >>>>> printed to the R Console. > >>>>> > >>>>> ERROR MESSAGE: > >>>>> - > >>>>> Error: Invalid font type > >>>>> In addition: Warning messages: > >>>>> 1: font family not found in PostScript font database > >>>>> 2: font family not found in PostScript font database > >>>>> - > >>>>> > >>>>> TO RECREATE THE PROBLEM: > >>>>> 1. Using the R Console, create some graph in R; for example, > >>>>> plot(rnorm(100)). > >>>>> 2. Select File -> Save As -> PostScript (or File -> Save As -> PDF). > >>>>> 3. Supply a file name and click the "Save" button. > >>>>> > >>>>> FOUR OTHER RELEVANT NOTES: > >>>>> 1. I checked to see if the same error results when invoking the > >>>>> functions > >>>>> pdf(file=...) or postscript(file=...). No error results, and the > >>>>> content of > >>>>> the output (.ps or .pdf) file produces a duplicate of what appears in > >>>>> the R > >>>>> Graphics window. > >>>>> > >>>>> 2. I checked, but did not see any other bug reports in the system that > >>>>> are > >>>>> relevant to this problem. > &g
[Rd] Bug in pacf -- Proposed patch
Dear all, following the thread http://tolstoy.newcastle.edu.au/R/e2/devel/07/09/4338.html regarding the bug in the partial autocorrelation function for multivariate time series. I have prepared a web page with patches and relevant information. http://www2.stat.unibo.it/giannerini/R/pacf.htm Please do not hesitate to contact me for further clarifications regards Simone -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in pacf -- Proposed patch (PR#10455)
Dear all, regarding the bug in pacf I have prepared a patch (attached) and tested it against the latest R devel platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Under development (unstable) major 2 minor 7.0 year 2008 month 01 day 18 svn rev 44040 language R version.string R version 2.7.0 Under development (unstable) (2008-01-18 r44040) Here I reproduce the example I gave in my previous post to trigger the bug > set.seed(10) > > x <- rnorm(1000,sd=1) > y <- rnorm(1000,sd=1) > pacf(ts(cbind(x,y)),plot=FALSE,lag.max=10) Partial autocorrelations of series 'ts(cbind(x, y))', by lag , , x xy 0.049 ( 1) 0.002 ( -1) 0.012 ( 2) -0.072 ( -2) 0.002 ( 3) 0.036 ( -3) 0.014 ( 4) 0.013 ( -4) 0.051 ( 5) 0.003 ( -5) 0.033 ( 6) -0.018 ( -6) 0.027 ( 7) 0.069 ( -7) -0.027 ( 8) 0.028 ( -8) -0.010 ( 9) -0.015 ( -9) -0.013 ( 10) -0.015 (-10) , , y xy 0.041 ( 1) -0.045 ( 1) 0.008 ( 2) -0.027 ( 2) -0.056 ( 3) -0.030 ( 3) 0.013 ( 4) -0.020 ( 4) 0.017 ( 5) 0.004 ( 5) -0.021 ( 6) -0.010 ( 6) 0.022 ( 7) 0.061 ( 7) 0.029 ( 8) -0.034 ( 8) -0.014 ( 9) 0.031 ( 9) -0.002 ( 10) 0.019 ( 10) below you can find relevant info and an example where I reproduce Wei's book results. http://www2.stat.unibo.it/giannerini/R/pacf.htm The routine is pure R, on the website there is also a F95 version. I am willing to write a FORTRAN 77 version of the patch if needed but I think this might replace the bugged routine temporarily. Let me know. Thanks for your attention Simone On Nov 23, 2007 6:35 PM, <[EMAIL PROTECTED]> wrote: > Dear all, > > following the thread > > http://tolstoy.newcastle.edu.au/R/e2/devel/07/09/4338.html > > regarding the bug in the partial autocorrelation function for > multivariate time series. > I have prepared a web page with patches and relevant information. > > http://www2.stat.unibo.it/giannerini/R/pacf.htm > > Please do not hesitate to contact me for further clarifications > > regards > > Simone > > -- > __ > > Simone Giannerini > Dipartimento di Scienze Statistiche "Paolo Fortunati" > Universita' di Bologna > Via delle belle arti 41 - 40126 Bologna, ITALY > Tel: +39 051 2098262 Fax: +39 051 232153 > http://www2.stat.unibo.it/giannerini/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] qf with infinite df
Dear all, I found the following behaviour > rf(5,Inf,Inf) [1] 1 1 1 1 1 but > qf(0.1,Inf,Inf) [1] NaN Warning messages: 1: In qf(0.1, Inf, Inf) : value out of range in 'lgamma' 2: In qf(p, df1, df2, lower.tail, log.p) : NaNs produced incidentally, > pf(1.01,Inf,Inf) [1] 1 > pf(1.0001,Inf,Inf) [1] 0.5 Is this the expected behaviour? Thanks Simone > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status Patched major 2 minor 7.0 year 2008 month 04 day22 svn rev45451 language R version.string R version 2.7.0 Patched (2008-04-22 r45451) platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Patched major 2 minor 6.1 year 2008 month 01 day17 svn rev44036 language R version.string R version 2.6.1 Patched (2008-01-17 r44036) __________ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] qf with infinite df
many thanks for all the clarifications and for the declaration of intents for fixing qf(). For the sake of completeness I stumbled upon the behaviour of qf when preparing statistical tables with R to be put online for my students. I remained a bit surprised in seeing how much the results vary across textbooks at least for the F. Kind regards Simone On Thu, Jun 5, 2008 at 5:13 PM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Thu, 5 Jun 2008, Simone Giannerini wrote: > > Dear all, >> >> I found the following behaviour >> >> rf(5,Inf,Inf) >>> >> [1] 1 1 1 1 1 >> >> but >> >> qf(0.1,Inf,Inf) >>> >> [1] NaN >> Warning messages: >> 1: In qf(0.1, Inf, Inf) : value out of range in 'lgamma' >> 2: In qf(p, df1, df2, lower.tail, log.p) : NaNs produced >> > > Could do better here. > > incidentally, >> >> >> pf(1.01,Inf,Inf) >>> >> [1] 1 >> >>> pf(1.0001,Inf,Inf) >>> >> [1] 0.5 >> >> Is this the expected behaviour? >> > > I think so. 1.0001 is the same as 1 in computer arithmetic, and > pf(1, m, n) = 0.5 for all large m, n. > > >> Thanks >> >> Simone >> >> R.version >>> >> _ >> platform i386-pc-mingw32 >> arch i386 >> os mingw32 >> system i386, mingw32 >> status Patched >> major 2 >> minor 7.0 >> year 2008 >> month 04 >> day22 >> svn rev45451 >> language R >> version.string R version 2.7.0 Patched (2008-04-22 r45451) >> >> platform x86_64-unknown-linux-gnu >> arch x86_64 >> os linux-gnu >> system x86_64, linux-gnu >> status Patched >> major 2 >> minor 6.1 >> year 2008 >> month 01 >> day17 >> svn rev44036 >> language R >> version.string R version 2.6.1 Patched (2008-01-17 r44036) >> >> __ >> >> Simone Giannerini >> Dipartimento di Scienze Statistiche "Paolo Fortunati" >> Universita' di Bologna >> Via delle belle arti 41 - 40126 Bologna, ITALY >> Tel: +39 051 2098262 Fax: +39 051 232153 >> http://www2.stat.unibo.it/giannerini/ >> __ >> >>[[alternative HTML version deleted]] >> >> ______ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, > http://www.stats.ox.ac.uk/~ripley/<http://www.stats.ox.ac.uk/%7Eripley/> > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] arima() bug
I get the same behaviour on R version 2.7.0 Patched (2008-06-05 r45857), Opensuse 10.3 x86_64 (32 Gb RAM) > set.seed(1); x <- ts(20*sin((1:731)*2*pi/365) + 10 + rnorm(731, 0, 4), freq=365) > arima(x, c(1, 0, 1), c(1, 0, 1)) *** caught segfault *** address 0x2aafb83e9f50, cause 'memory not mapped' Traceback: 1: .Call(R_getQ0, phi, theta) 2: makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) 3: arima(x, c(1, 0, 1), c(1, 0, 1)) the problem seems to show up when the seasonal AR part is included > arima(x, c(2, 1, 3), c(0, 0, 0)) Call: arima(x = x, order = c(2, 1, 3), seasonal = c(0, 0, 0)) Coefficients: ar1 ar2 ma1 ma2 ma3 0.0363 0.9477 -0.9434 -0.9468 0.9060 s.e. 0.0291 0.0289 0.0258 0.0397 0.0233 sigma^2 estimated as 18.41: log likelihood = -2100.79, aic = 4213.59 > arima(x, c(0, 0, 0), c(0, 0, 1)) Call: arima(x = x, order = c(0, 0, 0), seasonal = c(0, 0, 1)) Coefficients: sma1 intercept 0. 9.9293 s.e. 0.0724 0.5674 sigma^2 estimated as 78.47: log likelihood = -2832.41, aic = 5670.81 > arima(x, c(0, 0, 0), c(1, 0, 0)) *** caught segfault *** address 0x2b00bf41eae0, cause 'memory not mapped' Traceback: 1: .Call(R_getQ0, phi, theta) 2: makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) 3: arima(x, c(0, 0, 0), c(1, 0, 0)) > arima(x, c(0, 0, 0), c(2, 0, 0)) Errore in makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) : cannot allocate memory block of size 137438953465.2 Gb > arima(x, c(0, 0, 0), c(3, 0, 0)) Errore in optim(init[mask], armaCSS, method = "BFGS", hessian = FALSE, : initial value in 'vmmin' is not finite > R.version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Patched major 2 minor 7.0 year 2008 month 06 day05 svn rev45857 language R version.string R version 2.7.0 Patched (2008-06-05 r45857) On Thu, Jun 12, 2008 at 9:27 AM, Antonio, Fabio Di Narzo < [EMAIL PROTECTED]> wrote: > No segfault with my r-patched version on linux-i686: > > > set.seed(1); x <- ts(20*sin((1:731)*2*pi/365) + 10 + rnorm(731, 0, 4), > freq=365) > > arima(x, c(1, 0, 1), c(1, 0, 1)) > Errore: cannot allocate vector of size 1010.9 Mb > > F. > > > R.version > _ > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status Patched > major 2 > minor 7.0 > year 2008 > month 05 > day29 > svn rev45820 > language R > version.string R version 2.7.0 Patched (2008-05-29 r45820) > > > 2008/6/12 Ray Brownrigg <[EMAIL PROTECTED]>: > > I guess this is more r-devel than r-help. > > > > Note, I am just the messenger - I have no idea what the user is trying to > model here. > > > > arima() crashes R (segfault) with Linux R-2.7.0, Solaris R-2.6.0: > > > > *** caught segfault *** > > address 4240, cause 'memory not mapped' > > > > Traceback: > > 1: .Call(R_getQ0, phi, theta) > > 2: makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) > > 3: arima(x, c(1, 0, 1), c(1, 0, 1)) > > > > Under rw-2.7.0 or R version 2.8.0 Under development (unstable) > (2008-06-10 r45893) > > it gets: > > Error: cannot allocate vector of size 1010.9 Mb > > In addition: Warning messages: > > 1: In makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) : > > Reached total allocation of 447Mb: see help(memory.size) > > 2: In makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) : > > Reached total allocation of 447Mb: see help(memory.size) > > 3: In makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) : > > Reached total allocation of 447Mb: see help(memory.size) > > 4: In makeARIMA(trarma[[1]], trarma[[2]], Delta, kappa) : > > Reached total allocation of 447Mb: see help(memory.size) > > > > Reproduce by: > > > > # 2 years of daily temperature data > > set.seed(1); x <- ts(20*sin((1:731)*2*pi/365) + 10 + rnorm(731, 0, 4), > freq=365) > > arima(x, c(1, 0, 1), c(1, 0, 1)) > > > > Ray Brownrigg > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > -- > Antonio, Fabio Di Narzo > Ph.D. student at > Department of Statistical Sciences > University of Bologna, Italy > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
Re: [Rd] compiling 2.7.0 GNU/Linux | BLAS & Lapack query
Evan, It might depend on the way ACML has been compiled by the AMD people. Your version of gcc/gfortran might be incompatible with ACML 4.1.0. This is known to users and is causing problems. You can see it reported in the ACML forum here (it applies to 4.0.1 but I think the problems have not been solved) http://forums.amd.com/devforum/messageview.cfm?catid=217&threadid=90399&enterthread=y Here I report a part of a post of that thread Begin quote: "The gfortran ACML libraries are currently built with two different GCC/GFORTRAN compilers. The SINGLE THREADED libraries found in /opt/gfortran64 and /opt/gfortran64_int64 are built with 4.1.2. This compiler version is used because it is the most widely supported compiler with most new linux distributions (or was in 2007). The OpenMP MULTI THREADED libraries found in /opt/gfortran64_mp and /opt/gfortran64_mp_int64 are built with 4.2.0. This compiler is used because it was finally released in 2007 and 4.1.2 does not natively support OpenMP. This is mentioned in the release notes, but it's obvious not very clear. When using GCC/GFORTRAN 4.3, you will likely need to use the mp versions of the library. This has not been tested by AMD. When 4.3 releases, AMD may provide a 4.3 build. This issue happens because of the incompatibility between GCC 4.1.2 and 4.2. Now that more distributions are supplying GCC 4.2 AMD may only support GCC 4.2 for 2008 releases. In other words, no more 4.1.2 builds. Both single- and multi-threaded libraries would be built with 4.2. " end quote Se also subsequent replies. Maybe you should try first to see whether the ACML work at all on your system apart from R. Hope this helps Ciao Simone On Fri, Jun 13, 2008 at 5:03 PM, evan cooch <[EMAIL PROTECTED]> wrote: > Greetings - > > For a host of reasons I chose (was forced) to upgrade my multi-Opteron box > from Fedora 7 -> Fedora 8. In the process, I also updated the ACML I had > installed from 4.0.0 to 4.1.0. > > While I get no errors (that I can find) in the config -> make -> make > install sequence, I'm pretty sure (based on some benchmarks) that I'm not > getting BLAS and/or Lapack to compile in. So, either something has changed > from 2.6.2 -> 2.7.0, or something has changed from Fedora 7 -> Fedora 8, or > both. > > Here is the sequence I follow to do the config (which seemed to work > perfectly before - note: using bash shell): > > 1. LD_LIBRARY_PATH=/opt/acml4.1.0/gfortran64/lib > > 2. export LD_LIBRARY_PATH > > 3. ./configure --with-lapack="-L/usr/lib64" > --with-blas="L/opt/acml4.1.0/gfortran64/lib -lacml" > > > However, when I try this, at the end of the config script I'm told > > Interfaces supported: X11 > External libraries: readline > Additional capabilites: PNG, JPEG, iconv, MBCS, NLS, cairo > Options enabled: shared BLAS, R profiling, Java > > > I'm pretty sure that readline being the only external library being > reported > is diagnostic of some sort of issue - normally, I'm given information about > lapack, and generic BLAS being linked. But, no more. > > Suggestions? Points to the obvious? Both ACML and Lapack are where they > should be, so I'm quite frankly puzzled as to what is going on. > > > Thanks very much in advance. > >[[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in cov()? var() fails on NA in R 2.7.2 but not R 2.6.1
This has been changed in 2.7.1
BUG FIXES
o co[rv](use = "complete.obs") now always gives an error if there
are no complete cases: they used to give NA if
method = "pearson" but an error for the other two methods.
(Note that this is pretty arbitrary, but zero-length vectors
always give an error so it is at least consistent.)
Since sd(na.rm=TRUE) and var(na.rm=TRUE) both call cov(use =
"complete.obs"), this applies also to them.
cor(use="pair") used to give diagonal 1 even if the variable
was completely missing for the rank methods but NA for the
Pearson method: it now gives NA in all cases.
cor(use="pair") for the rank methods gave a matrix result with
dimensions > 0 even if one of the inputs had 0 columns.
Regards,
Simone
On Sat, Sep 6, 2008 at 12:38 AM, Andrew Piskorski <[EMAIL PROTECTED]> wrote:
> I recently started using R 2.7.2, and noticed a surprising change in
> the behavior of var() on NA data:
>
> R 2.6.1 (Patched), 2007-11-26, svn.rev 43541, x86_64-unknown-linux-gnu:
>
> > stdev(rep(NA,3), na.rm=F)
> [1] NA
> > stdev(rep(NA,3), na.rm=T)
> [1] NA
> > var(rep(NA,3), na.rm=T, use="complete.obs")
> [1] NA
>
> R 2.7.2 (Patched), 2008-09-02, svn.rev 46491, x86_64-unknown-linux-gnu:
>
> > stdev(rep(NA,3), na.rm=F)
> [1] NA
>
> > stdev(rep(NA,3), na.rm=T)
> Error in var(x, na.rm = na.rm) : no complete element pairs
>
> Enter a frame number, or 0 to exit
> 1: stdev(rep(NA, 3), na.rm = T)
> 2: var(x, na.rm = na.rm)
> Selection: 0
>
> > var(rep(NA,3), na.rm=T, use="complete.obs")
> Error in var(rep(NA, 3), na.rm = T, use = "complete.obs") :
>no complete element pairs
>
> Is this change intentional? Also, what is causing it? Looking, I see
> no changes in var() at all, so the new behavior must be due to a
> change in what this call does:
>
> .Internal(cov(x, y, na.method, FALSE))
>
> The R 2.7.2 cov() also has this weird line:
>
> else if (na.method != 3L) {
>
> Note the "L" in the "3L". A typo? The older 2.6.1 cov() just has "3"
> on that line, no "L".
>
> Interactively redefining cov() to remove the "L" makes no difference in my
> var() calls, but that could b
>
> The original source file seems to be:
>
> src/library/stats/R/cor.R
>
> svn annotate says that 3L line was last changed nearly a year ago, way
> back in rev 43302:
>
>
> r43302 | ripley | 2007-10-29 14:50:18 -0400 (Mon, 29 Oct 2007) | 2 lines
> make cor/cov a little less inconsistent
>
> The strange 3L line occurs twice in that file, in both cor() and cov():
>
> $ grep -n 3L cor.R
> 36:else if (na.method != 3L) {
> 118:else if (na.method != 3L) {
>
> That line might not be the cause of my "no complete element pairs"
> problem (I'm not at all sure), but it does look suspicious.
>
> --
> Andrew Piskorski <[EMAIL PROTECTED]>
> http://www.piskorski.com/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
______
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__
--
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gfortran optimization problems
Dave, yes, we have experienced different results in different platforms, the problem was partly due to the different versions of gfortran installed across platforms, are you using the same version for all the platforms? Clearly, gfortran is undergoing rapid changes so that the results might vary a lot across versions. You might want to contact the developers should you find out a compiler bug. Kind regards Simone On Sat, Oct 25, 2008 at 12:53 AM, Dave Roberts <[EMAIL PROTECTED]> wrote: > Colleagues, > > I have a routine in package labdsv that calls a FORTRAN subroutine. > Recently, I was informed that it sometimes gives different results on a PC > and Mac, and that the PC version is clearly wrong. I tested it on linux > (because I don't have a PC), and I get the same (incorrect) behavior as the > PC. > > Simply by inserting debug WRITE statements in the FORTRAN I would get > different, and correct, results, so I assumed it was an optimization error. > > So, > > 1) R CMD SHLIB duleg.fdoes not work, and produces bogus code > > however, > > 2) gfortran -c alt_duleg.f > gcc -O -std=gnu99 -shared -L/usr/local/lib -o alt_duleg.so >alt_duleg.o -lgfortran -lm -lgcc_s > > does work (note the -O low optimization). Otherwise the gcc command is > identical to the one produced by R CMD SHLIB. > > Has anyone else seen this? Is there a simple way to have my package > enforce no optimization so others don't struggle with this? As far as I > know the same code worked under g77. > > Thanks, Dave Roberts > -- > > David W. Roberts office 406-994-4548 > Professor and Head FAX 406-994-3190 > Department of Ecology email [EMAIL PROTECTED] > Montana State University > Bozeman, MT 59717-3460 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] /bin/windows/base/rpatched.html page out of date
Dear all, it looks like that something is wrong with the /bin/windows/base/rpatched.html page as it seems pointing to the 2.8.1rc version. Also, I do not know if it is relevant but notice the dates of the following files on ftp://ftp.stat.math.ethz.ch/Software/CRAN/bin/windows/base/ R-2.8.1pat-win32.exe 31963 KB 22/12/2008 16.15.00 R-2.8.1rc-win32.exe31991 KB 25/12/2008 9.30.00 thank you Simone -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] legend() in a multiple figure environment
Dear all, there seems to be a problem with displayed legends when a multiple figure environment is used, see the following example: par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); legend(-4,0.3,legend="curve",lty=1,col=4) legend(-4,0.2,legend="curve",lty=1,col=4) On my machines the first time the command legend() is issued the legend box stretches over the curve. Subsequent calls to legend seems to produce a correct box instead. openSuse 11.0 platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Patched major 2 minor 8.1 year 2009 month 01 day07 svn rev47501 language R version.string R version 2.8.1 Patched (2009-01-07 r47501) I see this on the same version of R on Windows VISTA 32 bit as well; I do not see this behaviour on a machine with R 2.8.0. Thank you, Simone -- ______ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu Ribatet wrote: > Dear Simone, > > Did mean that the legend (text and/or box) overlap with the Normal density? no, I mean that the two legend() commands, which are identical in all but the y-coordinates, produce different results, namely boxes with different widths. Ciao Simone > If so then I think there's no problem as the legend is placed where you told > R to do. And R won't check (for you) if it will overlap or not with > pre-existing graphical elements. > > On my computer, I got the expected results - if I understood correctly your > issue though. For information: > > R version 2.8.1 (2008-12-22) > Linux mathieu-laptop 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 > UTC 2008 i686 GNU/Linux (Ubuntu Intrepid) > > Cheers, > Mathieu > > Simone Giannerini a écrit : >> >> Dear all, >> >> there seems to be a problem with displayed legends when a multiple >> figure environment is used, see the following example: >> >> par(mfrow=c(1,2)) >> curve(dnorm,col=4,from=-4,to=4); >> legend(-4,0.3,legend="curve",lty=1,col=4) >> legend(-4,0.2,legend="curve",lty=1,col=4) >> >> >> On my machines the first time the command legend() is issued the >> legend box stretches over the curve. Subsequent calls to legend seems >> to produce a correct box instead. >> >> openSuse 11.0 >> >> platform x86_64-unknown-linux-gnu >> arch x86_64 >> os linux-gnu >> system x86_64, linux-gnu >> status Patched >> major 2 >> minor 8.1 >> year 2009 >> month 01 >> day07 >> svn rev47501 >> language R >> version.string R version 2.8.1 Patched (2009-01-07 r47501) >> >> I see this on the same version of R on Windows VISTA 32 bit as well; I >> do not see this behaviour on a machine with R 2.8.0. >> >> Thank you, >> >> Simone >> -- >> __ >> >> Simone Giannerini >> Dipartimento di Scienze Statistiche "Paolo Fortunati" >> Universita' di Bologna >> Via delle belle arti 41 - 40126 Bologna, ITALY >> Tel: +39 051 2098262 Fax: +39 051 232153 >> http://www2.stat.unibo.it/giannerini/ >> >> ______ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Institute of Mathematics > Ecole Polytechnique Fédérale de Lausanne > STAT-IMA-FSB-EPFL, Station 8 > CH-1015 Lausanne Switzerland > http://stat.epfl.ch/ > Tel: + 41 (0)21 693 7907 > > > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
On linux, I get > dev.cur() null device 1 > str(X11.options()) List of 15 $ display: chr "" $ width : num NA $ height : num NA $ pointsize : num 12 $ bg : chr "transparent" $ canvas : chr "white" $ gamma : num 1 $ colortype : chr "true" $ maxcubesize: num 256 $ fonts : chr [1:2] "-adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*" "-adobe-symbol-medium-r-*-*-%d-*-*-*-*-*-*-*" $ xpos : int NA $ ypos : int NA $ title : chr "" $ type : chr "cairo" $ antialias : num 1 thanks, Simone On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler wrote: >>>>>> "SG" == Simone Giannerini >>>>>> on Thu, 8 Jan 2009 14:08:17 +0100 writes: > >SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu >SG> Ribatet wrote: >>> Dear Simone, >>> >>> Did mean that the legend (text and/or box) overlap with >>> the Normal density? > >SG> no, I mean that the two legend() commands, which are >SG> identical in all but the y-coordinates, produce >SG> different results, namely boxes with different widths. > > I don't see that behavior at all, rather the two boxes have > identical dimensions for me. > > What does dev.cur() say? if anything with "X11..." (as you are > on Linux), what does > > str(X11.options()) > > give? > > >SG> Ciao > >SG> Simone > >>> If so then I think there's no problem as the legend is >>> placed where you told R to do. And R won't check (for >>> you) if it will overlap or not with pre-existing >>> graphical elements. >>> >>> On my computer, I got the expected results - if I >>> understood correctly your issue though. For information: >>> >>> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >>> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >>> i686 GNU/Linux (Ubuntu Intrepid) >>> >>> Cheers, Mathieu >>> >>> Simone Giannerini a écrit : >>>> >>>> Dear all, >>>> >>>> there seems to be a problem with displayed legends when >>>> a multiple figure environment is used, see the following >>>> example: >>>> >>>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>>> legend(-4,0.3,legend="curve",lty=1,col=4) >>>> legend(-4,0.2,legend="curve",lty=1,col=4) >>>> >>>> >>>> On my machines the first time the command legend() is >>>> issued the legend box stretches over the >>>> curve. Subsequent calls to legend seems to produce a >>>> correct box instead. >>>> >>>> openSuse 11.0 >>>> >>>> platform x86_64-unknown-linux-gnu arch x86_64 os >>>> linux-gnu system x86_64, linux-gnu status Patched major >>>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>>> language R version.string R version 2.8.1 Patched >>>> (2009-01-07 r47501) >>>> >>>> I see this on the same version of R on Windows VISTA 32 >>>> bit as well; I do not see this behaviour on a machine >>>> with R 2.8.0. >>>> >>>> Thank you, >>>> >>>> Simone > >>> -- >>>> __ >>>> >>>> Simone Giannerini Dipartimento di Scienze Statistiche >>>> "Paolo Fortunati" Universita' di Bologna Via delle belle >>>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>>> > >>> ______ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> >> -- >> Institute of Mathematics Ecole Polytechnique Fédérale de >>> Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne >>> Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 >>> >>> >>> > > > > -- > __ > >SG> Simone Giannerini Dipartimento di Scienze Statistiche >SG> "Paolo Fortunati" Universita' di Bologna Via delle belle >SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/ > >SG> __ >SG> R-devel@r-project.org mailing list >SG> https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
Now I got how to reproduce it, it has nothing to do with multiple figure environment but rather with figure resizing. Here it is: curve(dnorm,col=4,from=-4,to=4); legend(-4,0.3,legend="curve",lty=1,col=4) # Now expand the figure to full screen legend(-4,0.2,legend="curve",lty=1,col=4) Simone On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler wrote: > > >>>>> "SG" == Simone Giannerini > >>>>> on Thu, 8 Jan 2009 14:08:17 +0100 writes: > >SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu >SG> Ribatet wrote: >>> Dear Simone, >>> >>> Did mean that the legend (text and/or box) overlap with >>> the Normal density? > >SG> no, I mean that the two legend() commands, which are >SG> identical in all but the y-coordinates, produce >SG> different results, namely boxes with different widths. > > I don't see that behavior at all, rather the two boxes have > identical dimensions for me. > > What does dev.cur() say? if anything with "X11..." (as you are > on Linux), what does > > str(X11.options()) > > give? > > >SG> Ciao > >SG> Simone > >>> If so then I think there's no problem as the legend is >>> placed where you told R to do. And R won't check (for >>> you) if it will overlap or not with pre-existing >>> graphical elements. >>> >>> On my computer, I got the expected results - if I >>> understood correctly your issue though. For information: >>> >>> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >>> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >>> i686 GNU/Linux (Ubuntu Intrepid) >>> >>> Cheers, Mathieu >>> >>> Simone Giannerini a écrit : >>>> >>>> Dear all, >>>> >>>> there seems to be a problem with displayed legends when >>>> a multiple figure environment is used, see the following >>>> example: >>>> >>>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>>> legend(-4,0.3,legend="curve",lty=1,col=4) >>>> legend(-4,0.2,legend="curve",lty=1,col=4) >>>> >>>> >>>> On my machines the first time the command legend() is >>>> issued the legend box stretches over the >>>> curve. Subsequent calls to legend seems to produce a >>>> correct box instead. >>>> >>>> openSuse 11.0 > >>> >>>> platform x86_64-unknown-linux-gnu arch x86_64 os >>>> linux-gnu system x86_64, linux-gnu status Patched major >>>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>>> language R version.string R version 2.8.1 Patched >>>> (2009-01-07 r47501) >>>> >>>> I see this on the same version of R on Windows VISTA 32 >>>> bit as well; I do not see this behaviour on a machine >>>> with R 2.8.0. >>>> >>>> Thank you, >>>> >>>> Simone >>>> -- >>>> __________ >>>> >>>> Simone Giannerini Dipartimento di Scienze Statistiche >>>> "Paolo Fortunati" Universita' di Bologna Via delle belle >>>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>>> >>>> __ > >>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> > > -- > > Institute of Mathematics Ecole Polytechnique Fédérale de >>> Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne >>> Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 >>> >>> >>> > > > > -- > __ > >SG> Simone Giannerini Dipartimento di Scienze Statistiche >SG> "Paolo Fortunati" Universita' di Bologna Via delle belle >SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/ > >SG> __ >SG> R-devel@r-project.org mailing list >SG> https://stat.ethz.ch/mailman/listinfo/r-devel -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() in a multiple figure environment
You can find the resulting graph here (produced under win Vista) http://www2.stat.unibo.it/giannerini/R/try.eps (produced under win Vista) platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 8.1 year 2008 month 12 day22 svn rev47281 language R version.string R version 2.8.1 (2008-12-22) On Thu, Jan 8, 2009 at 3:29 PM, Simone Giannerini wrote: > Now I got how to reproduce it, it has nothing to do with multiple > figure environment but rather with figure resizing. Here it is: > > curve(dnorm,col=4,from=-4,to=4); > legend(-4,0.3,legend="curve",lty=1,col=4) > > # Now expand the figure to full screen > > legend(-4,0.2,legend="curve",lty=1,col=4) > > Simone > > On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler > wrote: >> >> >>>>> "SG" == Simone Giannerini >> >>>>> on Thu, 8 Jan 2009 14:08:17 +0100 writes: >> >>SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu >>SG> Ribatet wrote: >>>> Dear Simone, >>>> >>>> Did mean that the legend (text and/or box) overlap with >>>> the Normal density? >> >>SG> no, I mean that the two legend() commands, which are >>SG> identical in all but the y-coordinates, produce >>SG> different results, namely boxes with different widths. >> >> I don't see that behavior at all, rather the two boxes have >> identical dimensions for me. >> >> What does dev.cur() say? if anything with "X11..." (as you are >> on Linux), what does >> >> str(X11.options()) >> >> give? >> >> >>SG> Ciao >> >>SG> Simone >> >>>> If so then I think there's no problem as the legend is >>>> placed where you told R to do. And R won't check (for >>>> you) if it will overlap or not with pre-existing >>>> graphical elements. >>>> >>>> On my computer, I got the expected results - if I >>>> understood correctly your issue though. For information: >>>> >>>> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >>>> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >>>> i686 GNU/Linux (Ubuntu Intrepid) >>>> >>>> Cheers, Mathieu >>>> >>>> Simone Giannerini a écrit : >>>>> >>>>> Dear all, >>>>> >>>>> there seems to be a problem with displayed legends when >>>>> a multiple figure environment is used, see the following >>>>> example: >>>>> >>>>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>>>> legend(-4,0.3,legend="curve",lty=1,col=4) >>>>> legend(-4,0.2,legend="curve",lty=1,col=4) >>>>> >>>>> >>>>> On my machines the first time the command legend() is >>>>> issued the legend box stretches over the >>>>> curve. Subsequent calls to legend seems to produce a >>>>> correct box instead. >>>>> >>>>> openSuse 11.0 >>>>> >>>>> platform x86_64-unknown-linux-gnu arch x86_64 os >>>>> linux-gnu system x86_64, linux-gnu status Patched major >>>>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>>>> language R version.string R version 2.8.1 Patched >>>>> (2009-01-07 r47501) >>>>> >>>>> I see this on the same version of R on Windows VISTA 32 >>>>> bit as well; I do not see this behaviour on a machine >>>>> with R 2.8.0. >>>>> >>>>> Thank you, >>>>> >>>>> Simone >>>>> -- >>>>> __ >>>>> >>>>> Simone Giannerini Dipartimento di Scienze Statistiche >>>>> "Paolo Fortunati" Universita' di Bologna Via delle belle >> >>> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: >>>>> +39 051 232153 http://www2.stat.unibo.it/giannerini/ >>>>> >>>>> ___
Re: [Rd] legend() in a multiple figure environment
Thanks for your clarifications, I use legends only when the plot is at its final size and also had a look at windows() before posting but at first I could not relate the legends' behaviour to the resizing effect. Kind regards, Simone On Thu, Jan 8, 2009 at 4:02 PM, Prof Brian Ripley wrote: > On Thu, 8 Jan 2009, Simone Giannerini wrote: > >> Now I got how to reproduce it, it has nothing to do with multiple >> figure environment but rather with figure resizing. Here it is: >> >> curve(dnorm,col=4,from=-4,to=4); >> legend(-4,0.3,legend="curve",lty=1,col=4) >> >> # Now expand the figure to full screen >> >> legend(-4,0.2,legend="curve",lty=1,col=4) > > When you resize graphics, text stays the same size (on most devices) and > vector graphics does not. You can't expect the figure to be recomputed when > you resize (and if you expect so, your expectations will be unfufilled). > All that happens is that a low-level description is replayed. > > The windows() device does give you more options on resize. > >> >> Simone >> >> On Thu, Jan 8, 2009 at 2:39 PM, Martin Maechler >> wrote: >>> >>>>>>>> "SG" == Simone Giannerini >>>>>>>>on Thu, 8 Jan 2009 14:08:17 +0100 writes: >>> >>> SG> Dear Mathieu, On Thu, Jan 8, 2009 at 12:14 PM, Mathieu >>> SG> Ribatet wrote: >>> >> Dear Simone, >>> >> >>> >> Did mean that the legend (text and/or box) overlap with >>> >> the Normal density? >>> >>> SG> no, I mean that the two legend() commands, which are >>> SG> identical in all but the y-coordinates, produce >>> SG> different results, namely boxes with different widths. >>> >>> I don't see that behavior at all, rather the two boxes have >>> identical dimensions for me. >>> >>> What does dev.cur() say? if anything with "X11..." (as you are >>> on Linux), what does >>> >>> str(X11.options()) >>> >>> give? >>> >>> >>> SG> Ciao >>> >>> SG> Simone >>> >>> >> If so then I think there's no problem as the legend is >>> >> placed where you told R to do. And R won't check (for >>> >> you) if it will overlap or not with pre-existing >>> >> graphical elements. >>> >> >>> >> On my computer, I got the expected results - if I >>> >> understood correctly your issue though. For information: >>> >> >>> >> R version 2.8.1 (2008-12-22) Linux mathieu-laptop >>> >> 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008 >>> >> i686 GNU/Linux (Ubuntu Intrepid) >>> >> >>> >> Cheers, Mathieu >>> >> >>> >> Simone Giannerini a écrit : >>> >>> >>> >>> Dear all, >>> >>> >>> >>> there seems to be a problem with displayed legends when >>> >>> a multiple figure environment is used, see the following >>> >>> example: >>> >>> >>> >>> par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); >>> >>> legend(-4,0.3,legend="curve",lty=1,col=4) >>> >>> legend(-4,0.2,legend="curve",lty=1,col=4) >>> >>> >>> >>> >>> >>> On my machines the first time the command legend() is >>> >>> issued the legend box stretches over the >>> >>> curve. Subsequent calls to legend seems to produce a >>> >>> correct box instead. >>> >>> >>> >>> openSuse 11.0 >>> >>> >>> >>> platform x86_64-unknown-linux-gnu arch x86_64 os >>> >>> linux-gnu system x86_64, linux-gnu status Patched major >>> >>> 2 minor 8.1 year 2009 month 01 day 07 svn rev 47501 >>> >>> language R version.string R version 2.8.1 Patched >>> >>> (2009-01-07 r47501) >>> >>> >>> >>> I see this on the same version of R on Windows VISTA 32 >>> >>> bit as well; I do not see this behaviour on a machine >>> >>> with R 2.8.0. >>> >>> >>> >>> Thank you, >>> >>> >>> >>> Simone >>> >>> -- >>> >>> __
[Rd] quantile(), IQR() and median() for factors
Dear all, from the help page of quantile: "x numeric vectors whose sample quantiles are wanted. Missing values are ignored." from the help page of IQR: "x a numeric vector." as a matter of facts it seems that both quantile() and IQR() do not check for the presence of a numeric input. See the following: set.seed(11) x <- rbinom(n=11,size=2,prob=.5) x <- factor(x,ordered=TRUE) x [1] 1 0 1 0 0 2 0 1 2 0 0 Levels: 0 < 1 < 2 > quantile(x) 0% 25% 50% 75% 100% 0 0 2 Levels: 0 < 1 < 2 Warning messages: 1: In Ops.ordered((1 - h), qs[i]) : '*' is not meaningful for ordered factors 2: In Ops.ordered(h, x[hi[i]]) : '*' is not meaningful for ordered factors > IQR(x) [1] 1 whereas median has the check: > median(x) Error in median.default(x) : need numeric data I also take the opportunity to ask your comments on the following related subject: In my opinion it would be convenient that median() and the like (quantile(), IQR()) be implemented for ordered factors for which in fact they can be well defined. For instance, in this way functions like apply(x,FUN=median,...) could be used without the need of further processing for data frames that contain both numeric variables and ordered factors. If on the one hand, to my limited knowledge, in English introductory statistics textbooks the fact that the median is well defined for ordered categorical variables is only mentioned marginally, on the other hand, in the Italian Statistics literature this is often discussed in detail and this could mislead students and practitioners that might expect median() to work for ordered factors. In this message https://stat.ethz.ch/pipermail/r-help/2003-November/042684.html Martin Maechler considers the possibility of doing such a job by allowing for extra arguments "low" and "high" as it is done for mad(). I am willing to give a contribution if requested, and comments are welcome. Thank you for the attention, kind regards, Simone > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 8.1 year 2008 month 12 day 22 svn rev 47281 language R version.string R version 2.8.1 (2008-12-22) LC_COLLATE=Italian_Italy.1252;LC_CTYPE=Italian_Italy.1252;LC_MONETARY=Italian_Italy.1252;LC_NUMERIC=C;LC_TIME=Italian_Italy.1252 -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] quantile(), IQR() and median() for factors
Dear Greg, thank you for your comments, as Prof. Ripley pointed out, in the case of even sample size the median is not unique and is formed by the two central observations or a function of them, if that makes sense. Dear Prof. Ripley, thank you for your concern, may I notice that (in case of non-negative data) one can get the median from mad() with center=0,constant=1 > mad(1:10,center=0,constant=1) [1] 5.5 > mad(1:10,center=0,constant=1,high=TRUE) [1] 6 > mad(1:10,center=0,constant=1,low=TRUE) [1] 5 so that it seems that part of the code of mad() might be a starting point, at least for median(). I confirm my availability to work on the matter if requested. Kind regards, Simone On Fri, Mar 6, 2009 at 6:36 PM, Prof Brian Ripley wrote: > On Fri, 6 Mar 2009, Greg Snow wrote: > >> I like the idea of median and friends working on ordered factors. Just a >> couple of thoughts on possible implementations. >> >> Adding extra checks and functionality will slow down the function. For a >> single evaluation on a given dataset this slowdown will not be noticeable, >> but inside of a simulation, bootstrap, or other high iteration technique, it >> could matter. I would suggest creating a core function that does just the >> calculations (median, quantile, iqr) assuming that the data passed in is >> correct without doing any checks or anything fancy. Then the user callable >> function (median et. al.) would do the checks dispatch to other functions >> for anything fancy, etc. then call the core function with the clean data. >> The common user would not really notice a difference, but someone >> programming a high iteration technique could clean the data themselves, then >> call the core function directly bypassing the checks/branches. > > Since median and quantile are already generic, adding a 'ordered' method > would be zero cost to other uses. And the factor check at the head of > median.default could be replaced by median.factor if someone could show a > convincing performance difference. > >> Just out of curiosity (from someone who only learned from English >> (Americanized at that) and not Italian texts), what would the median of >> [Low, Low, Medium, High] be? > > I don't think it is 'the' median but 'a' median. (Even English Wikipedia > says the median is not unique for even numbers of inputs.) > >> >> -- >> Gregory (Greg) L. Snow Ph.D. >> Statistical Data Center >> Intermountain Healthcare >> greg.s...@imail.org >> 801.408.8111 >> >> >>> -Original Message- >>> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r- >>> project.org] On Behalf Of Simone Giannerini >>> Sent: Thursday, March 05, 2009 4:49 PM >>> To: R-devel >>> Subject: [Rd] quantile(), IQR() and median() for factors >>> >>> Dear all, >>> >>> from the help page of quantile: >>> >>> "x numeric vectors whose sample quantiles are wanted. Missing >>> values are ignored." >>> >>> from the help page of IQR: >>> >>> "x a numeric vector." >>> >>> as a matter of facts it seems that both quantile() and IQR() do not >>> check for the presence of a numeric input. >>> See the following: >>> >>> set.seed(11) >>> x <- rbinom(n=11,size=2,prob=.5) >>> x <- factor(x,ordered=TRUE) >>> x >>> [1] 1 0 1 0 0 2 0 1 2 0 0 >>> Levels: 0 < 1 < 2 >>> >>>> quantile(x) >>> >>> 0% 25% 50% 75% 100% >>> 0 0 2 >>> Levels: 0 < 1 < 2 >>> Warning messages: >>> 1: In Ops.ordered((1 - h), qs[i]) : >>> '*' is not meaningful for ordered factors >>> 2: In Ops.ordered(h, x[hi[i]]) : '*' is not meaningful for ordered >>> factors >>> >>>> IQR(x) >>> >>> [1] 1 >>> >>> whereas median has the check: >>> >>>> median(x) >>> >>> Error in median.default(x) : need numeric data >>> >>> I also take the opportunity to ask your comments on the following >>> related subject: >>> >>> In my opinion it would be convenient that median() and the like >>> (quantile(), IQR()) be implemented for ordered factors for which in >>> fact >>> they can be well defined. For instance, in this way functions like >>> apply(x,FUN=median,...) could be used without the need of further >>> processing for >>> data frames that contain both nume
Re: [Rd] quantile and IQR do not check for numeric input (PR#13631)
Dear Thomas, On Mon, Mar 30, 2009 at 1:50 PM, Thomas Lumley wrote: > On Mon, 30 Mar 2009 sgianner...@gmail.com wrote: > >> This report follows the post >> >> http://tolstoy.newcastle.edu.au/R/e6/devel/09/03/0760.html >> >> where it is shown that quantile() and IQR() do not work as documented. > > Nothing of the sort is shown! The thread argued that methods for these > functions for ordered factors would be useful. in the original thread I initiated the matters were two (at least in my intention) 1. quantile() and IQR() do not check for numeric input whereas median() has a check (for a factor input). This has nothing to deal with ordered factors 2. the opportunity of having methods for ordered factors for quantile() and the like. If, for some reason, you think that it is ok to have such check for median but not for quantile and IQR then take this as a wishlist. BTW also var() and the like do not check for factor input while mean() has the check. > x <- factor(letters[1:9]) > x [1] a b c d e f g h i Levels: a b c d e f g h i > mean(x) [1] NA Warning message: In mean.default(x) : argument is not numeric or logical: returning NA > var(x) [1] 7.5 Regards Simone > >> In fact they do not check for numeric input even if the documentation says >> = >> : >> >> ?quantile >> x numeric vectors whose sample quantiles are wanted. Missing >> values are ignored. >> >> ?IQR >> >> x a numeric vector. >> > > The documentation says that you are not allowed to pass anything except a > numeric vector to quantile() and IQR(). It doesn't, for example, say you can > pass an arbitrary vector that will be checked to see if it is numeric. If > you have code that passes a factor to IQR(), the bug is in that code. > > On the other hand, as someone else has since reported, the 'missing values > are ignored' statement in ?quantile is wrong (or at least incomplete). > > > -thomas > > Thomas Lumley Assoc. Professor, Biostatistics > tlum...@u.washington.edu University of Washington, Seattle > > > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Running R on dual/quad Opteron machines
Dear all, I am managing a departmental purchase of an Opteron based workstation/server for scientific computing on which we will be running R. The environment will probably be either Unix/Linux or Solaris and the amount of RAM will be 8-16Gb, depending on the number of processors. My main concerns are the following: 1. How much does R benefit from passing from one processor to two/four processor machines? Consider that the typical intensive use of the server will be represented by simulation studies with many repeated loops. 2. How does R cope with parallelization and/or parallelized compiled code ? I would be very grateful if someone could give suggestions and/or point me to information on the above mentioned issues. Regards, Simone Giannerini -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Running R on dual/quad Opteron machines
Dear Sean, many thanks for the suggestion, I will have a look at the packages. Regards, Simone On 3/6/06, Sean Davis <[EMAIL PROTECTED]> wrote: > > > > On 3/6/06 11:50 AM, "Simone Giannerini" <[EMAIL PROTECTED]> wrote: > > > Dear all, > > > > I am managing a departmental purchase of an Opteron based > > workstation/server for scientific computing on which we will be > > running R. > > The environment will probably be either Unix/Linux or Solaris and the > > amount of RAM will be 8-16Gb, depending on the number of processors. > > My main concerns are the following: > > > > 1. How much does R benefit from passing from one processor to > > two/four processor machines? Consider that the typical intensive use > > of the server > > will be represented by simulation studies with many repeated loops. > > You will have to implement some parallelization code yourself in order to > take full advantage of the multiple processors. See below. > > > 2. How does R cope with parallelization and/or parallelized compiled code ? > > You might look at the Rmpi and snow packages for parallelization from within > R. We use Rmpi and snow for analyses like simulation and have found these > applications quite easy to implement in parallel from within R. > > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Running R on dual/quad Opteron machines
On 3/6/06, Thomas Lumley <[EMAIL PROTECTED]> wrote: > On Mon, 6 Mar 2006, Simone Giannerini wrote: > > The environment will probably be either Unix/Linux or Solaris and the > > amount of RAM will be 8-16Gb, depending on the number of processors. > > My main concerns are the following: > > > > 1. How much does R benefit from passing from one processor to > > two/four processor machines? Consider that the typical intensive use > > of the server > > will be represented by simulation studies with many repeated loops. > > The typical way that R is used on multiprocessor systems is running more > than one program, rather than parallel processing. If four people are > using the computer or if one person splits 10,000 iterations of a > simulation into 4 sets of 2,500 you will be using all four processors. > Many thanks, if I have understood correctly, in this case I would need running four separate instances of R, since a single thread cannot exploit more than one cpu, am I correct? Regards, Simone -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Running R on dual/quad Opteron machines
Ok thanks, I am wondering whether running multiple instances of R would be possible without problems in presence of compiled code (shared libraries). Intuitively, while there can be multiple instances of R, all of them would be using the same library, but I am just guessing, I might do a check on this. Ciao Simone > > And let me couch my earlier statements on snow/Rmpi by saying that we use > these tools on a relatively large beowulf cluster (~200 nodes), which is > somewhat different than a single box with 2-4 processors, so it is may not > be worth the trouble outside of a cluster environment. For example, we have > not moved to using Rmpi/snow on our dual-processor G5s because the speed > gain just isn't worth the extra installation trouble, etc. > > Sean > > -- __________ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Running R on dual/quad Opteron machines
Dear prof. Ripley, many thanks for the clarification, now I have good elements for managing the purchase. kind regards, Simone Giannerini On 3/7/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Tue, 7 Mar 2006, Simone Giannerini wrote: > > > Ok thanks, I am wondering whether running multiple instances of R > > would be possible without problems in presence of compiled code > > (shared libraries). > > Intuitively, while there can be multiple instances of R, all of them > > would be using the same library, but I am just guessing, I might do a > > check on this. > > That's what the `shared library' means. The common parts (e.g. code and > static data) are shared, but the data areas are not. > > Different processes run in different address spaces, and modern OSes are > careful only to give a user process write access to its own address space. > > Many of us have servers running multiple copies of R at almost all times. > I typically run R tests with four copies running on a dual-CPU Opteron, > that being about the minimum number needed to get 100% CPU usage since I/O > is also being done. > > > > > Ciao > > > > Simone > > > >> > >> And let me couch my earlier statements on snow/Rmpi by saying that we use > >> these tools on a relatively large beowulf cluster (~200 nodes), which is > >> somewhat different than a single box with 2-4 processors, so it is may not > >> be worth the trouble outside of a cluster environment. For example, we > >> have > >> not moved to using Rmpi/snow on our dual-processor G5s because the speed > >> gain just isn't worth the extra installation trouble, etc. > >> > >> Sean > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] About AHP (Analytic Hierachy process)
To my knowledge there is not such a thing in R, but at http://www.superdecisions.com there is a free multiplatform software implemented by Saaty that does AHP/ANP models. Regards, Simone On 3/17/06, Omrani Hichem <[EMAIL PROTECTED]> wrote: > Dear Sir, > > I wander if, it existes in R,a library or a routine for AHP (Analytic > Hiararchy > Process). AHP is a kind of Multi criteria Analysis approach. > > Thanks, for help. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __________ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inconsistent behaviour when subsetting a ts object with frequency = 12 or 4
Dear All,
I found the following under R 2.3.0 on WINXP (tested on 2 PCs, I do
not have access to the to Linux from this PC, sorry ... )
> set.seed(10)
> x <- ts(rnorm(6),frequency=7)
> x
Time Series:
Start = c(1, 1)
End = c(1, 6)
Frequency = 7
[1] 0.01874617 -0.18425254 -1.37133055 -0.59916772 0.29454513 0.38979430
> x[24] <- NA
> x
Time Series:
Start = c(1, 1)
End = c(1, 6)
Frequency = 7
[1] 0.01874617 -0.18425254 -1.37133055 -0.59916772 0.29454513
0.38979430 NA NA NA NA NA
[12] NA NA NA NA NA
NA NA NA NA NA NA
[23]
## OK
> x <- ts(rnorm(6),frequency=12) # THE SAME BUT WITH frequency = 12
> x
JanFebMarAprMayJun
1 -1.2080762 -0.3636760 -1.6266727 -0.2564784 1.1017795 0.7557815
> x[24] <- NA
> x
Error in matrix(c(rep.int("", start.pad), format(x, ...), rep.int("", :
length of 'dimnames' [1] not equal to array extent
In addition: Warning message:
data length [30] is not a sub-multiple or multiple of the number of
columns [12] in matrix
> x <- ts(rnorm(6),frequency=4) # THE SAME BUT WITH frequency = 4
> x
Qtr1Qtr2Qtr3Qtr4
1 -0.23823356 0.98744470 0.74139013 0.08934727
2 -0.95494386 -0.19515038
> x[24] <- NA
> x
Error in matrix(c(rep.int("", start.pad), format(x, ...), rep.int("", :
length of 'dimnames' [1] not equal to array extent
In addition: Warning message:
data length [26] is not a sub-multiple or multiple of the number of
rows [7] in matrix
Is this behaviour expected for frequencies 12 and 4?
Thank you
Simone
***
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 3.0
year 2006
month 04
day24
svn rev37909
language R
version.string Version 2.3.0 (2006-04-24)
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098248 Fax: +39 051 232153
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inconsistent behaviour when manipulating a ts object with frequency = 12 or 4
Dear All,
I found the following under R 2.3.0 on WINXP (tested on 2 PCs, I do
not have access to Linux from this PC, sorry ... )
> set.seed(10)
> x <- ts(rnorm(6),frequency=7)
> x
Time Series:
Start = c(1, 1)
End = c(1, 6)
Frequency = 7
[1] 0.01874617 -0.18425254 -1.37133055 -0.59916772 0.29454513 0.38979430
> x[24] <- NA
> x
Time Series:
Start = c(1, 1)
End = c(1, 6)
Frequency = 7
[1] 0.01874617 -0.18425254 -1.37133055 -0.59916772 0.29454513
0.38979430 NA NA NA NA NA
[12] NA NA NA NA NA
NA NA NA NA NA NA
[23]
## OK
> x <- ts(rnorm(6),frequency=12) # THE SAME BUT WITH frequency = 12
> x
JanFebMarAprMayJun
1 -1.2080762 -0.3636760 -1.6266727 -0.2564784 1.1017795 0.7557815
> x[24] <- NA
> x
Error in matrix(c(rep.int("", start.pad), format(x, ...), rep.int("", :
length of 'dimnames' [1] not equal to array extent
In addition: Warning message:
data length [30] is not a sub-multiple or multiple of the number of
columns [12] in matrix
> x <- ts(rnorm(6),frequency=4) # THE SAME BUT WITH frequency = 4
> x
Qtr1Qtr2Qtr3Qtr4
1 -0.23823356 0.98744470 0.74139013 0.08934727
2 -0.95494386 -0.19515038
> x[24] <- NA
> x
Error in matrix(c(rep.int("", start.pad), format(x, ...), rep.int("", :
length of 'dimnames' [1] not equal to array extent
In addition: Warning message:
data length [26] is not a sub-multiple or multiple of the number of
rows [7] in matrix
Is this behaviour expected for frequencies 12 and 4?
Thank you
Simone
***
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 3.0
year 2006
month 04
day24
svn rev37909
language R
version.string Version 2.3.0 (2006-04-24)
> Sys.getlocale()
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098248 Fax: +39 051 232153
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistent behaviour when manipulating a ts object with frequency = 12 or 4
many thanks for the reply,
On 5/31/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> Attempting to change element 24 of a length 6 time series is inconsistent!
of course it is, my post was also motivated by the fact that you
obtain different answers also within the same frequency, depending on
the index, for instance:
> x <- ts(rnorm(6),frequency=12)
> x
JanFebMarAprMayJun
1 0.9255213 0.4829785 -0.5963106 -2.1852868 -0.6748659 -2.1190612
> x[7] <- NA
> x
JanFebMarAprMayJunJul
1 0.9255213 0.4829785 -0.5963106 -2.1852868 -0.6748659 -2.1190612 NA
so that I thought maybe it was worth pointing this out even if the
series are invalid.
> You end up with an invalid series, and the print methods are different for
> different frequencies, hence different error messages.
>
> Please do not send the same post repeatedly!
I apologize, I thought there was a problem with the first post.
Regards,
Simone
>
> On Wed, 31 May 2006, Simone Giannerini wrote:
>
> > Dear All,
> >
> > I found the following under R 2.3.0 on WINXP (tested on 2 PCs, I do
> > not have access to Linux from this PC, sorry ... )
> >
> >> set.seed(10)
> >> x <- ts(rnorm(6),frequency=7)
> >> x
> > Time Series:
> > Start = c(1, 1)
> > End = c(1, 6)
> > Frequency = 7
> > [1] 0.01874617 -0.18425254 -1.37133055 -0.59916772 0.29454513 0.38979430
> >> x[24] <- NA
> >> x
> > Time Series:
> > Start = c(1, 1)
> > End = c(1, 6)
> > Frequency = 7
> > [1] 0.01874617 -0.18425254 -1.37133055 -0.59916772 0.29454513
> > 0.38979430 NA NA NA NA NA
> > [12] NA NA NA NA NA
> > NA NA NA NA NA NA
> > [23]
> > ## OK
> >
> >> x <- ts(rnorm(6),frequency=12) # THE SAME BUT WITH frequency = 12
> >> x
> > JanFebMarAprMayJun
> > 1 -1.2080762 -0.3636760 -1.6266727 -0.2564784 1.1017795 0.7557815
> >> x[24] <- NA
> >> x
> > Error in matrix(c(rep.int("", start.pad), format(x, ...), rep.int("", :
> >length of 'dimnames' [1] not equal to array extent
> > In addition: Warning message:
> > data length [30] is not a sub-multiple or multiple of the number of
> > columns [12] in matrix
> >
> >> x <- ts(rnorm(6),frequency=4) # THE SAME BUT WITH frequency = 4
> >> x
> > Qtr1Qtr2Qtr3Qtr4
> > 1 -0.23823356 0.98744470 0.74139013 0.08934727
> > 2 -0.95494386 -0.19515038
> >> x[24] <- NA
> >> x
> > Error in matrix(c(rep.int("", start.pad), format(x, ...), rep.int("", :
> >length of 'dimnames' [1] not equal to array extent
> > In addition: Warning message:
> > data length [26] is not a sub-multiple or multiple of the number of
> > rows [7] in matrix
> >
> >
> > Is this behaviour expected for frequencies 12 and 4?
> >
> > Thank you
> >
> > Simone
> >
> > ***
> > platform i386-pc-mingw32
> > arch i386
> > os mingw32
> > system i386, mingw32
> > status
> > major 2
> > minor 3.0
> > year 2006
> > month 04
> > day24
> > svn rev37909
> > language R
> > version.string Version 2.3.0 (2006-04-24)
> >
> >> Sys.getlocale()
> > [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> > States.1252;LC_MONETARY=English_United
> > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> >
> > __
> >
> > Simone Giannerini
> > Dipartimento di Scienze Statistiche "Paolo Fortunati"
> > Universita' di Bologna
> > Via delle belle arti 41 - 40126 Bologna, ITALY
> > Tel: +39 051 2098248 Fax: +39 051 232153
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
--
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098248 Fax: +39 051 232153
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rgui crash under Windows
Dear all, I found the following on R 2.3.1. for Windows XPpro SP2, tested on 2 PCs AMD 64 3700+, Ati 9700 AMD Athlon 2400+, Matrox G550 Do the following: x <- as.matrix(0); fix(x) pasting a big chunk of data, for instance the one below, into a cell of the editor will crash the RGui. 33 333 333 333 333 platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 3.1 year 2006 month 06 day01 svn rev38247 language R version.string Version 2.3.1 (2006-06-01) * the same does happen under linux (SUSE 10.0), details follow platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major2 minor2.1 year 2005 month12 day 20 svn rev 36812 language R Regards, Simone __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rgui crash under Windows
Dear Duncan, thank you very much for your reply, just for the sake of precision I missed a 'not' in my report, actually I intended: "the same does not happen under linux (SUSE 10.0), details follow" as I was not able to reproduce it under Linux, sorry for the inconvenience. Regards, Simone On 6/12/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 6/11/2006 2:13 PM, Simone Giannerini wrote: > > Dear all, > > I found the following on R 2.3.1. for Windows XPpro SP2, tested on 2 PCs > > AMD 64 3700+, Ati 9700 > > AMD Athlon 2400+, Matrox G550 > > > > > > Do the following: > > > > x <- as.matrix(0); > > fix(x) > > > > pasting a big chunk of data, for instance the one below, into a cell > > of the editor will crash the RGui. > > Confirmed, and fixed. I'll commit the fixes to R-patched and R-devel soon. > > Duncan Murdoch > > > > > 33 > > 333 > > > > 333 > > > > 333 > > 333 > > > > platform i386-pc-mingw32 > > arch i386 > > os mingw32 > > system i386, mingw32 > > status > > major 2 > > minor 3.1 > > year 2006 > > month 06 > > day01 > > svn rev38247 > > language R > > version.string Version 2.3.1 (2006-06-01) > > * > > the same does happen under linux (SUSE 10.0), details follow > > > > platform x86_64-unknown-linux-gnu > > arch x86_64 > > os linux-gnu > > system x86_64, linux-gnu > > status > > major2 > > minor2.1 > > year 2005 > > month12 > > day 20 > > svn rev 36812 > > language R > > > > > > Regards, > > > > Simone > > > > > > __ > > > > Simone Giannerini > > Dipartimento di Scienze Statistiche "Paolo Fortunati" > > Universita' di Bologna > > Via delle belle arti 41 - 40126 Bologna, ITALY > > Tel: +39 051 2098248 Fax: +39 051 232153 > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] digits in summary.default
Dear all,
the number of significant digits in summary default is
digits = max(3, getOption("digits") - 3)
on my platform this results to be 4. The point is that if you have,
say, integer data of magnitude greater than 10^3 the command summary
will produce heavily rounded results.
A simple example follow:
> x <- c(123456,234567,345678)
> x
[1] 123456 234567 345678
> summary(x)
Min. 1st Qu. MedianMean 3rd Qu.Max.
123500 179000 234600 234600 290100 345700
# quite different from
> quantile(x)
0% 25% 50% 75% 100%
123456.0 179011.5 234567.0 290122.5 345678.0
Is it possible to adapt the number of significant digits to the
magnitude of the data?
The first thing that comes into my mind is
digits = nchar(trunc(max(x))) #
If it is not possible then I think it would be nice to mention the
issue in the documentation.
Thanks for the attention,
Simone
> R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 3.1
year 2006
month 06
day01
svn rev38247
language R
version.string Version 2.3.1 (2006-06-01)
> Sys.getlocale()
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
>
______
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CCF and ACF
Dear all, given two numeric vectors x and y, the ACF(x) at lag k is cor(x(t),x(t+k)) while the CCF(x,y) at lag k is cor(x(t),y(t-k)). See below for a simple example. > set.seed(1) > x <- rnorm(10) > y <- rnorm(10) > x [1] -0.6264538 0.1836433 -0.8356286 1.5952808 0.3295078 -0.8204684 0.4874291 0.7383247 0.5757814 -0.3053884 > y [1] 1.51178117 0.38984324 -0.62124058 -2.21469989 1.12493092 -0.04493361 -0.01619026 0.94383621 0.82122120 0.59390132 > x <- x - mean(x); > y <- y -mean(y); ## ACF OF x(t) > print(acf(x,lag=2,plot=F),digits=5)) Autocorrelations of series 'x', by lag 012 1.0 -0.26486 -0.25352 ## For Instance ACF(x) at lag 1 is Corr(x(t),x(t+1)): > sum(x[1:9]*x[2:10])/sum(x^2) [1] -0.2648633 ## whereas CCF(x,y) at lag 1 is Corr(x(t),y(t-1)) > ccf(x,y,lag=2,plot=F) Autocorrelations of series 'X', by lag -2 -1 0 1 2 -0.139 0.593 -0.377 -0.382 0.116 > sum(x[1:9]*y[2:10])/sqrt(sum(x^2)*sum(y^2)) [1] 0.5930216 > sum(x[2:10]*y[1:9])/sqrt(sum(x^2)*sum(y^2)) [1] -0.3822885 from a quick survey on textbooks (Brockwell and Davis, Chatfield, Fuller) it looks like different authors use different conventions so that I think that it would be nice to clarify this in the documentation. Ciao Simone > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status beta major 2 minor 4.0 year 2006 month 09 day20 svn rev39421 language R version.string R version 2.4.0 beta (2006-09-20 r39421) > Sys.getlocale() [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252" __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CCF and ACF
Thank you Gabor, by the way I have checked in the Matlab GARCH toolbox, the crosscorrelation function is reversed with respect to R, I think it would be useful for the users to have documented the way CCF is computed. Simone On 10/2/06, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > Using "ts" objects these can be written in the following consistent > manner: > > > sum(ts(x) * lag(ts(x)) / sum(ts(x)^2)) > [1] -0.2648633 > > > sum(ts(x) * lag(ts(y)) / sqrt(sum(ts(y)^2) * sum(ts(x)^2))) > [1] 0.5930216 > > On 10/2/06, Simone Giannerini <[EMAIL PROTECTED]> wrote: > > Dear all, > > > > given two numeric vectors x and y, the ACF(x) at lag k is > > cor(x(t),x(t+k)) while the CCF(x,y) at lag k is cor(x(t),y(t-k)). See > > below for a simple example. > > > > > set.seed(1) > > > x <- rnorm(10) > > > y <- rnorm(10) > > > x > > [1] -0.6264538 0.1836433 -0.8356286 1.5952808 0.3295078 -0.8204684 > > 0.4874291 0.7383247 0.5757814 -0.3053884 > > > y > > [1] 1.51178117 0.38984324 -0.62124058 -2.21469989 1.12493092 > > -0.04493361 -0.01619026 0.94383621 0.82122120 0.59390132 > > > x <- x - mean(x); > > > y <- y -mean(y); > > > > ## ACF OF x(t) > > > print(acf(x,lag=2,plot=F),digits=5)) > > > > Autocorrelations of series 'x', by lag > > > >012 > > 1.0 -0.26486 -0.25352 > > > > ## For Instance ACF(x) at lag 1 is Corr(x(t),x(t+1)): > > > > > sum(x[1:9]*x[2:10])/sum(x^2) > > [1] -0.2648633 > > > > ## whereas CCF(x,y) at lag 1 is Corr(x(t),y(t-1)) > > > ccf(x,y,lag=2,plot=F) > > > > Autocorrelations of series 'X', by lag > > > >-2 -1 0 1 2 > > -0.139 0.593 -0.377 -0.382 0.116 > > > > > sum(x[1:9]*y[2:10])/sqrt(sum(x^2)*sum(y^2)) > > > > [1] 0.5930216 > > > > > sum(x[2:10]*y[1:9])/sqrt(sum(x^2)*sum(y^2)) > > [1] -0.3822885 > > > > from a quick survey on textbooks (Brockwell and Davis, Chatfield, > > Fuller) it looks like different authors use different conventions so > > that I think that it would be nice to clarify this in the > > documentation. > > > > Ciao > > > > Simone > > > > > R.version > > _ > > platform i386-pc-mingw32 > > arch i386 > > os mingw32 > > system i386, mingw32 > > status beta > > major 2 > > minor 4.0 > > year 2006 > > month 09 > > day20 > > svn rev39421 > > language R > > version.string R version 2.4.0 beta (2006-09-20 r39421) > > > > > Sys.getlocale() > > [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United > > States.1252;LC_MONETARY=English_United > > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252" > > > > > > __ > > > > Simone Giannerini > > Dipartimento di Scienze Statistiche "Paolo Fortunati" > > Universita' di Bologna > > Via delle belle arti 41 - 40126 Bologna, ITALY > > Tel: +39 051 2098262 Fax: +39 051 232153 > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] x86_64, acml-3.5.0-gfortran64 and lme4
I did not try the ACML but I have experienced problems both in configure and in make on my SUSE 10.0 x86_64 with gcc 4.0.2. The problem was due to a bug in gfortran so that I had to update to version 4.2 (I did not update gcc though). I do not know whether this may apply to you but updating the gfortran is highly recommended by the developers. Kind regards, Simone On 10/16/06, Douglas Bates <[EMAIL PROTECTED]> wrote: > I am encountering segfaults when checking the lme4 package on an > Athlon64 system if I use the acml blas. R was built as a 64-bit > application using the GCC 4.0.3 compiler suite including gfortran. > The version of acml is 3.5.0 gfortran64. > > I do not encounter the segfaults when I compile R with R's built-in > BLAS. The errors occur in the first example in lme4 in a call to > lmer. It looks like they would occur in any call to lmer. Running > under the debugger shows that the segfault occurs in a call to dtrsm > (a level-3 BLAS routine to solve a triangular system of equations) > that is called from within a cholmod (sparse matrix library) routine. > > Has anyone succeeded in running R CMD check on the lme4 package with > accelerated BLAS? I'm trying to pin down is this occurs only with > ACML or also with Atlas and/or Goto's BLAS. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
