Re: [Rd] [R] Problem compiling in extra/xdr
1) The current R-patched should compile src/extra/xdr on 32-bit Linux systems. 2) Longer-term or on a 64-bit platform the solution is to make use of libtirpc: you would need both this installed (common now) and its headers (unlikely). Then if you arrange for /usr/include/tirpc to be in the C include path (not easy to do portably, but using C_INCLUDE_PATH will work on Linux), the tirpc versions should be found. On Tue, 19 Jul 2011, Prof Brian Ripley wrote: On Mon, 18 Jul 2011, Allin Cottrell wrote: On Mon, 18 Jul 2011, Prof Brian Ripley wrote: 1) R-help is the wrong list: see the posting guide. I've moved this to R-devel. 2) A glibc system should not be compiling in that directory. glibc 2.14 is rather recent and NEWS does say * The RPC implementation in libc is obsoleted. Old programs keep working but new programs cannot be linked with the routines in libc anymore. Programs in need of RPC functionality must be linked against TI-RPC. The TI-RPC implementation is IPv6 enabled and there are other benefits. Visible changes of this change include (obviously) the inability to link programs using RPC functions without referencing the TI-RPC library and the removal of the RPC headers from the glibc headers. Implemented by Ulrich Drepper. So the answer seems to be that your libc is too new. OK, thanks. I should have remembered the info about RPC in the glibc-2.14 news. Then there will presumably be a problem building current R on current Fedora? What is 'current Fedora'? glibc 2.14 postdates the current release, Fedora 15, which uses 2.13. I do not know what Fedora 16 will use in several months The main problem will be that the xdr included in R is only for platforms with 32-bit longs -- but that may be true for your i686 Linux. It needs _X86_ defined to compile for i686: I would have expected that to be true on your platform, but am testing a cleaned-up version. If that works it will appear in R-patched within 24 hours. On Mon, 18 Jul 2011, Allin Cottrell wrote: I'm building R 2.13.1 on i686-pc-linux-gnu, using gcc 4.6.1 and with glibc 2.14. I get this error: In file included from xdr.c:61:0: ./rpc/types.h:63:14: error: conflicting types for 'malloc' make[4]: *** [xdr.o] Error 1 I can make the build proceed some by commenting out the declaration "extern char *malloc();" in xdr/rpc/types.h, but then I get a slew of other errors: xdr_float.c: In function 'xdr_float': xdr_float.c:119:21: error: storage size of 'is' isn't known xdr_float.c:120:20: error: storage size of 'vs' isn't known and so on. config.log is rather big to post here; I'm putting it at http://www.wfu.edu/~cottrell/tmp/R.config.log . -- Allin Cottrell Department of Economics Wake Forest University, NC __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. -- Allin Cottrell Department of Economics Wake Forest University -- 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, UKFax: +44 1865 272595 -- 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Manipulating single-precision (float) arrays in .Callfunctions
"Duncan Murdoch" wrote in message news:4e259600.5070...@gmail.com... > On 11-07-19 7:48 AM, Matthew Dowle wrote: >> >> "Prof Brian Ripley" wrote in message >> news:alpine.lfd.2.02.1107190640280.28...@gannet.stats.ox.ac.uk... >>> On Mon, 18 Jul 2011, Alireza Mahani wrote: >>> Simon, Thank you for elaborating on the limitations of R in handling float types. I think I'm pretty much there with you. As for the insufficiency of single-precision math (and hence limitations of GPU), my personal take so far has been that double-precision becomes crucial when some sort of error accumulation occurs. For example, in differential equations where boundary values are integrated to arrive at interior values, etc. On the other hand, in my personal line of work (Hierarchical Bayesian models for quantitative marketing), we have so much inherent uncertainty and noise at so many levels in the problem (and no significant error accumulation sources) that single vs double precision issue is often inconsequential for us. So I think it really depends on the field as well as the nature of the problem. >>> >>> The main reason to use only double precision in R was that on modern >>> CPUs >>> double precision calculations are as fast as single-precision ones, and >>> with 64-bit CPUs they are a single access. >>> So the extra precision comes more-or-less for free. >> >> But, isn't it much more of the 'less free' when large data sets are >> considered? If a double matrix takes 3GB, it's 1.5GB in single. >> That might alleviate the dreaded out-of-memory error for some >> users in some circumstances. On 64bit, 50GB reduces to 25GB >> and that might make the difference between getting >> something done, or not. If single were appropriate, of course. >> For GPU too, i/o often dominates iiuc. >> >> For space reasons, is there any possibility of R supporting single >> precision (and single bit logical to reduce memory for logicals by >> 32 times)? I guess there might be complaints from users using >> single inappropriately (or worse, not realising we have an instable >> result due to single). > > You can do any of this using external pointers now. That will remind you > that every single function to operate on such objects needs to be > rewritten. > > It's a huge amount of work, benefiting very few people. I don't think > anyone in R Core will do it. > > Duncan Murdoch I've been informed off list about the 'bit' package, which seems great and answers my parenthetic complaint (at least). http://cran.r-project.org/web/packages/bit/index.html Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] apply() returning a list?
Hi devel list, I searched for past posts about this issue and found none, so my apologies if this has been addressed before. The sapply() function has an argument 'simplify', and the mapply() function has an argument 'SIMPLIFY'. I am surprised that the apply() argument does not have a similar argument. Is there a reason for this? Here's a simple example: > x = matrix(1:12, 3, 4) > apply(x, 1, sum) [1] 22 26 30 This is what I would like to see: > apply(x, 1, sum, simplify = FALSE) [[1]] [1] 22 [[2]] [1] 26 [[3]] [1] 30 Looking at the function definition of apply(), I imagine it wouldn't be too hard to add such an argument. Add an argument 'simplify' with default value TRUE, and include the following line in the function definition. if(simplify == FALSE) return (ans) Is this a good idea? Would this be a good addition to R's apply() function? Are there stability issues in making this change (for example, what if some previous code threw a 'simplify' argument into the '...')? Best, -David Johnston -- View this message in context: http://r.789695.n4.nabble.com/apply-returning-a-list-tp3679619p3679619.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
Re: [Rd] Randomness not due to seed
> Date: Tue, 19 Jul 2011 06:13:01 -0700
> From: jeroen.o...@stat.ucla.edu
> To: r-devel@r-project.org
> Subject: [Rd] Randomness not due to seed
>
> I am working on a reproducible computing platform for which I would like to
> be able to _exactly_ reproduce an R object. However, I am experiencing
> unexpected randomness in some calculations. I have a hard time finding out
> exactly how it occurs. The code below illustrates the issue.
>
> mylm1 <- lm(dist~speed, data=cars);
> mylm2 <- lm(dist~speed, data=cars);
> identical(mylm1, mylm2); #TRUE
>
> makelm <- function(){
> return(lm(dist~speed, data=cars));
> }
>
> mylm1 <- makelm();
> mylm2 <- makelm();
> identical(mylm1, mylm2); #FALSE
>
> When inspecting both objects there seem to be some rounding differences.
> Setting a seed does not make a difference. Is there any way I can remove
> this randomness and exactly reproduce the object every time?
I don't know if anyone had a specific answer for this but in general floating
point is not
something for which you want to make bitwise equality tests. You can check the
Intel
website for some references but IIRC the FPU can start your calculation with
bits or
settings ( flushing denorms to zero for example) left over from the last user
although I can't document that.
for example, you can probably find more like this suggesting that changes in
alignmnet
and rounding in preamble code can be significant,
http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler/
and of course if your algorithm is numerically sensitive results could change a
lot. Now
its also possible you have unitiliazed or corrupt memory, but you would need to
consider that you will not get bit wise reproduvibility. You can of course go
to java
if you really want that LOL.
>
>
>
>
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/Randomness-not-due-to-seed-tp3678082p3678082.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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Randomness not due to seed
On 11-07-19 8:01 PM, Mike Marchywka wrote:
Date: Tue, 19 Jul 2011 06:13:01 -0700
From: jeroen.o...@stat.ucla.edu
To: r-devel@r-project.org
Subject: [Rd] Randomness not due to seed
I am working on a reproducible computing platform for which I would like to
be able to _exactly_ reproduce an R object. However, I am experiencing
unexpected randomness in some calculations. I have a hard time finding out
exactly how it occurs. The code below illustrates the issue.
mylm1<- lm(dist~speed, data=cars);
mylm2<- lm(dist~speed, data=cars);
identical(mylm1, mylm2); #TRUE
makelm<- function(){
return(lm(dist~speed, data=cars));
}
mylm1<- makelm();
mylm2<- makelm();
identical(mylm1, mylm2); #FALSE
When inspecting both objects there seem to be some rounding differences.
Setting a seed does not make a difference. Is there any way I can remove
this randomness and exactly reproduce the object every time?
I don't know if anyone had a specific answer for this
I think Bill Dunlap's answer addressed it: the claim appears to be false.
Duncan Murdoch
but in general floating point is not
something for which you want to make bitwise equality tests. You can check the
Intel
website for some references but IIRC the FPU can start your calculation with
bits or
settings ( flushing denorms to zero for example) left over from the last user
although I can't document that.
for example, you can probably find more like this suggesting that changes in
alignmnet
and rounding in preamble code can be significant,
http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler/
and of course if your algorithm is numerically sensitive results could change a
lot. Now
its also possible you have unitiliazed or corrupt memory, but you would need to
consider that you will not get bit wise reproduvibility. You can of course go
to java
if you really want that LOL.
--
View this message in context:
http://r.789695.n4.nabble.com/Randomness-not-due-to-seed-tp3678082p3678082.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
__
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
Re: [Rd] Randomness not due to seed
>> I think Bill Dunlap's answer addressed it: the claim appears to be false. Here is another example where there is randomness that is not due to the seed. On the same machine, the same R binary, but through another interface. First directly in the shell: > sessionInfo() R version 2.13.1 (2011-07-08) Platform: i686-pc-linux-gnu (32-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 > set.seed(123) > print(coef(lm(dist~speed, data=cars)),digits=22) (Intercept) speed -17.579094890510951643137 3.932408759124087715975 # And this is through eclipse (java) > sessionInfo() R version 2.13.1 (2011-07-08) Platform: i686-pc-linux-gnu (32-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 [9] LC_ADDRESS=en_US.UTF-8LC_TELEPHONE=en_US.UTF-8 [11] LC_MEASUREMENT=en_US.UTF-8LC_IDENTIFICATION=en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] rj_0.5.2-1 loaded via a namespace (and not attached): [1] rJava_0.9-1 tools_2.13.1 > set.seed(123) > print(coef(lm(dist~speed, data=cars)),digits=22) (Intercept)speed -17.57909489051087703615 3.93240875912408460735 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Randomness not due to seed
On 20 July 2011 at 14:03, Jeroen Ooms wrote: | >> I think Bill Dunlap's answer addressed it: the claim appears to be false. | | Here is another example where there is randomness that is not due to | the seed. On the same machine, the same R binary, but through another | interface. First directly in the shell: | | > sessionInfo() | R version 2.13.1 (2011-07-08) | Platform: i686-pc-linux-gnu (32-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 | | > set.seed(123) | > print(coef(lm(dist~speed, data=cars)),digits=22) | (Intercept) speed | -17.579094890510951643137 3.932408759124087715975 That's PBKAC --- even double precision does NOT get you 22 digits precision. You may want to read up on 'what every computer scientist should know about floating point arithmetic' by Goldberg (which is both a true internet classic) and ponder why a common setting for the various 'epsilon' settings of general convergence is set to of the constants supplied by the OS and/or its C library. R has #define SINGLE_EPS FLT_EPSILON [...] #define DOUBLE_EPS DBL_EPSILON in Constants.h. You can then chase the definition of FLT_EPSILON and DBL_EPSILON through your system headers (which is a good exercise). One place you may end up in the manual -- the following from the GNU libc documentationon :Floating Point Parameters" FLT_EPSILON This is the minimum positive floating point number of type float such that 1.0 + FLT_EPSILON != 1.0 is true. It's supposed to be no greater than 1E-5. DBL_EPSILON LDBL_EPSILON These are similar to FLT_EPSILON, but for the data types double and long double, respectively. The type of the macro's value is the same as the type it describes. The values are not supposed to be greater than 1E-9. So there -- nine digits. Dirk | # And this is through eclipse (java) | | > sessionInfo() | R version 2.13.1 (2011-07-08) | Platform: i686-pc-linux-gnu (32-bit) | | locale: | [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C | [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 | [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 | [7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 | [9] LC_ADDRESS=en_US.UTF-8LC_TELEPHONE=en_US.UTF-8 | [11] LC_MEASUREMENT=en_US.UTF-8LC_IDENTIFICATION=en_US.UTF-8 | | attached base packages: | [1] stats graphics grDevices utils datasets methods base | | other attached packages: | [1] rj_0.5.2-1 | | loaded via a namespace (and not attached): | [1] rJava_0.9-1 tools_2.13.1 | | > set.seed(123) | > print(coef(lm(dist~speed, data=cars)),digits=22) | (Intercept)speed | -17.57909489051087703615 3.93240875912408460735 | | __ | R-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel -- Gauss once played himself in a zero-sum game and won $50. -- #11 at http://www.gaussfacts.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Randomness not due to seed
I would guess the error below is because of Java messing around in the hardware. It's pretty common on Windows for DLLs to attempt to change the precision setting on the floating point processor; I hadn't seen that before on Linux, but that would be my guess as to the cause. It's also possible that one of the attached packages has messed with R functions somehow, e.g. by replacing the default print() or show() method. A third possibility is that different math libraries are being used. So I would consider the differences in the results to be a bit of a bug, but not one that is likely under our control, and not one that is so large that I would worry about working around it. Duncan Murdoch On 20/07/2011 8:03 AM, Jeroen Ooms wrote: >> I think Bill Dunlap's answer addressed it: the claim appears to be false. Here is another example where there is randomness that is not due to the seed. On the same machine, the same R binary, but through another interface. First directly in the shell: > sessionInfo() R version 2.13.1 (2011-07-08) Platform: i686-pc-linux-gnu (32-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 > set.seed(123) > print(coef(lm(dist~speed, data=cars)),digits=22) (Intercept) speed -17.579094890510951643137 3.932408759124087715975 # And this is through eclipse (java) > sessionInfo() R version 2.13.1 (2011-07-08) Platform: i686-pc-linux-gnu (32-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 [9] LC_ADDRESS=en_US.UTF-8LC_TELEPHONE=en_US.UTF-8 [11] LC_MEASUREMENT=en_US.UTF-8LC_IDENTIFICATION=en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] rj_0.5.2-1 loaded via a namespace (and not attached): [1] rJava_0.9-1 tools_2.13.1 > set.seed(123) > print(coef(lm(dist~speed, data=cars)),digits=22) (Intercept)speed -17.57909489051087703615 3.93240875912408460735 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Randomness not due to seed
Hi,
Even using the same math libraries you can get different results,
depending on what sorts of instructions those libraries use, see the
following (none R related) blog article:
http://blog.nag.com/2011/02/wandering-precision.html.
Martyn
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
Sent: 20 July 2011 14:47
To: Jeroen Ooms
Cc: r-devel@r-project.org
Subject: Re: [Rd] Randomness not due to seed
I would guess the error below is because of Java messing around in the
hardware. It's pretty common on Windows for DLLs to attempt to change
the precision setting on the floating point processor; I hadn't seen
that before on Linux, but that would be my guess as to the cause.
It's also possible that one of the attached packages has messed with R
functions somehow, e.g. by replacing the default print() or show()
method.
A third possibility is that different math libraries are being used.
So I would consider the differences in the results to be a bit of a bug,
but not one that is likely under our control, and not one that is so
large that I would worry about working around it.
Duncan Murdoch
On 20/07/2011 8:03 AM, Jeroen Ooms wrote:
> >> I think Bill Dunlap's answer addressed it: the claim appears to
be false.
>
> Here is another example where there is randomness that is not due to
> the seed. On the same machine, the same R binary, but through another
> interface. First directly in the shell:
>
> > sessionInfo()
> R version 2.13.1 (2011-07-08)
> Platform: i686-pc-linux-gnu (32-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
>
> > set.seed(123)
> > print(coef(lm(dist~speed, data=cars)),digits=22)
>(Intercept) speed
> -17.579094890510951643137 3.932408759124087715975
>
>
>
> # And this is through eclipse (java)
>
> > sessionInfo()
> R version 2.13.1 (2011-07-08)
> Platform: i686-pc-linux-gnu (32-bit)
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8
> [9] LC_ADDRESS=en_US.UTF-8LC_TELEPHONE=en_US.UTF-8
> [11] LC_MEASUREMENT=en_US.UTF-8LC_IDENTIFICATION=en_US.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] rj_0.5.2-1
>
> loaded via a namespace (and not attached):
> [1] rJava_0.9-1 tools_2.13.1
>
> > set.seed(123)
> > print(coef(lm(dist~speed, data=cars)),digits=22)
> (Intercept)speed
> -17.57909489051087703615 3.93240875912408460735
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
This e-mail has been scanned for all viruses by Star.\ _...{{dropped:12}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Randomness not due to seed
On 20/07/2011 9:59 AM, Martyn Byng wrote: Hi, Even using the same math libraries you can get different results, depending on what sorts of instructions those libraries use, see the following (none R related) blog article: http://blog.nag.com/2011/02/wandering-precision.html. That's another cause that I hadn't considered, also mostly out of our control. (Whoever compiles R does have some control over what optimizations the compiler does, but they might not be aware of them all.) Duncan Murdoch Martyn -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch Sent: 20 July 2011 14:47 To: Jeroen Ooms Cc: r-devel@r-project.org Subject: Re: [Rd] Randomness not due to seed I would guess the error below is because of Java messing around in the hardware. It's pretty common on Windows for DLLs to attempt to change the precision setting on the floating point processor; I hadn't seen that before on Linux, but that would be my guess as to the cause. It's also possible that one of the attached packages has messed with R functions somehow, e.g. by replacing the default print() or show() method. A third possibility is that different math libraries are being used. So I would consider the differences in the results to be a bit of a bug, but not one that is likely under our control, and not one that is so large that I would worry about working around it. Duncan Murdoch On 20/07/2011 8:03 AM, Jeroen Ooms wrote: > >> I think Bill Dunlap's answer addressed it: the claim appears to be false. > > Here is another example where there is randomness that is not due to > the seed. On the same machine, the same R binary, but through another > interface. First directly in the shell: > > > sessionInfo() > R version 2.13.1 (2011-07-08) > Platform: i686-pc-linux-gnu (32-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 > > > set.seed(123) > > print(coef(lm(dist~speed, data=cars)),digits=22) > (Intercept) speed > -17.579094890510951643137 3.932408759124087715975 > > > > # And this is through eclipse (java) > > > sessionInfo() > R version 2.13.1 (2011-07-08) > Platform: i686-pc-linux-gnu (32-bit) > > locale: >[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C >[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 >[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 >[7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 >[9] LC_ADDRESS=en_US.UTF-8LC_TELEPHONE=en_US.UTF-8 > [11] LC_MEASUREMENT=en_US.UTF-8LC_IDENTIFICATION=en_US.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > other attached packages: > [1] rj_0.5.2-1 > > loaded via a namespace (and not attached): > [1] rJava_0.9-1 tools_2.13.1 > > > set.seed(123) > > print(coef(lm(dist~speed, data=cars)),digits=22) >(Intercept)speed > -17.57909489051087703615 3.93240875912408460735 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel This e-mail has been scanned for all viruses by Star. The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] testing a Windows custom installer
Dear R-devel list members, For several years, I've created a custom R installer for my students who use Windows. When I test the installer on my own Windows machines, selections in the installation dialogs reflect my previous choices, which I suppose are saved in the Windows registry. I'd like to be able to see what a student who has never installed R before will see, to verify that an installation that takes all defaults in the custom installer produces the desired result. In the past, I've dealt with this problem by finding a Windows machine on which R has never been installed, but that's inconvenient (and, as R proliferates will, I hope, become impossible!). Is there a better approach? Thanks, John John Fox Senator William McMaster Professor of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Randomness not due to seed
It does not look like your calculation is using the random number generator, so
the other responses are probably more to the point.
However, beware that setting the seed is not enough to guarantee the same
random numbers. You need to also make sure you are using the same uniform RNG
and any other generators you use, such as the normal generator. R has a large
selection of possibilities. Your start up settings could change the default
behaviour. Also, relying on the default will be a bit risky if you are
interested in reproducible calculations, because the R default could change in
the future (as it has in the past, and as has the Splus generator in the past).
If the RNG is important for your reproducible calculations then you might want
to look at the examples and tests in the setRNG package.
Paul
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
> project.org] On Behalf Of jeroen00ms
> Sent: July 19, 2011 9:13 AM
> To: r-devel@r-project.org
> Subject: [Rd] Randomness not due to seed
>
> I am working on a reproducible computing platform for which I would
> like to
> be able to _exactly_ reproduce an R object. However, I am experiencing
> unexpected randomness in some calculations. I have a hard time finding
> out
> exactly how it occurs. The code below illustrates the issue.
>
> mylm1 <- lm(dist~speed, data=cars);
> mylm2 <- lm(dist~speed, data=cars);
> identical(mylm1, mylm2); #TRUE
>
> makelm <- function(){
> return(lm(dist~speed, data=cars));
> }
>
> mylm1 <- makelm();
> mylm2 <- makelm();
> identical(mylm1, mylm2); #FALSE
>
> When inspecting both objects there seem to be some rounding
> differences.
> Setting a seed does not make a difference. Is there any way I can
> remove
> this randomness and exactly reproduce the object every time?
>
>
>
>
>
> --
> View this message in context: http://r.789695.n4.nabble.com/Randomness-
> not-due-to-seed-tp3678082p3678082.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
La version française suit le texte anglais.
This email may contain privileged and/or confidential information, and the Bank
of
Canada does not waive any related rights. Any distribution, use, or copying of
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately
from
your system and notify the sender promptly by email that you have done so.
Le présent courriel peut contenir de l'information privilégiée ou
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite. Si vous
recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans
délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de
votre
ordinateur toute copie du courriel reçu.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] testing a Windows custom installer
On Wed, 2011-07-20 at 10:29 -0400, John Fox wrote: > For several years, I've created a custom R installer for my students > who use Windows. When I test the installer on my own Windows machines, > selections in the installation dialogs reflect my previous choices, > which I suppose are saved in the Windows registry. > > I'd like to be able to see what a student who has never installed R > before will see, to verify that an installation that takes all > defaults in the custom installer produces the desired result. In the > past, I've dealt with this problem by finding a Windows machine on > which R has never been installed, but that's inconvenient (and, as R > proliferates will, I hope, become impossible!). Is there a better > approach? I keep a Windows XP virtual machine image around in a 'clean' state for things like this. I spin up the 'clean' image, test what I need to test, and shut down the Windows image without snapshotting it. Regards, - Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] testing a Windows custom installer
On 20/07/2011 10:29 AM, John Fox wrote: Dear R-devel list members, For several years, I've created a custom R installer for my students who use Windows. When I test the installer on my own Windows machines, selections in the installation dialogs reflect my previous choices, which I suppose are saved in the Windows registry. I'd like to be able to see what a student who has never installed R before will see, to verify that an installation that takes all defaults in the custom installer produces the desired result. In the past, I've dealt with this problem by finding a Windows machine on which R has never been installed, but that's inconvenient (and, as R proliferates will, I hope, become impossible!). Is there a better approach? The settings are saved to the registry by the installer, Inno Setup, and restored automatically (for most of them), or using its "GetPreviousData" function (for the R specific ones). I don't think there is a way to tell the installer to ignore the previous data, but there might be. I believe if you uninstall R then the settings will be forgotten, because the settings are saved in locations like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\R for Windows 2.13.0_is1 in string values named "Inno Setup: *" for the ones used internally, and "Inno Setup Codefile: *" for the ones specific to R. It's probably okay to delete that whole key and then it will forget the old settings, but that seems risky. There's a command line option to the installer called "/SAVEINF" which saves the settings to a file and "/LOADINF" which loads them from a file, but I don't see how to tell it to just ignore the registry settings. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apply() returning a list?
On Jul 19, 2011, at 7:34 PM, David A. Johnston wrote: Hi devel list, I searched for past posts about this issue and found none, so my apologies if this has been addressed before. The sapply() function has an argument 'simplify', and the mapply() function has an argument 'SIMPLIFY'. I am surprised that the apply() argument does not have a similar argument. Is there a reason for this? Here's a simple example: x = matrix(1:12, 3, 4) apply(x, 1, sum) [1] 22 26 30 This is what I would like to see: apply(x, 1, sum, simplify = FALSE) [[1]] [1] 22 [[2]] [1] 26 [[3]] [1] 30 Probably no one thought it was that difficult to type the more concise and equally expressive: > as.list(apply(x, 1, sum)) [[1]] [1] 22 [[2]] [1] 26 [[3]] [1] 30 -- David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Randomness not due to seed
On Jul 20, 2011, at 15:38 , Dirk Eddelbuettel wrote: > > On 20 July 2011 at 14:03, Jeroen Ooms wrote: > | >> I think Bill Dunlap's answer addressed it: the claim appears to be > false. > | > | Here is another example where there is randomness that is not due to > | the seed. On the same machine, the same R binary, but through another > | interface. First directly in the shell: > | > | > sessionInfo() > | R version 2.13.1 (2011-07-08) > | Platform: i686-pc-linux-gnu (32-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 > | > | > set.seed(123) > | > print(coef(lm(dist~speed, data=cars)),digits=22) > | (Intercept) speed > | -17.579094890510951643137 3.932408759124087715975 > > That's PBKAC --- even double precision does NOT get you 22 digits precision. Hmm, yes, but you would expect the SAME function on the SAME data to yield the same floating point number, and give the SAME printout on the SAME R on the SAME hardware... FWIW all the Mac versions that I can access give the same results as the eclipse version. Let's look at the numbers side-by-side -17.579094890510951643137 3.932408759124087715975 -17.579094890510877036153.93240875912408460735 ! ! 12.345678901234567890123 1.234567890123456789012 so we're seeing differences around the 15th/16th significant digit. This is consistent with a difference of about one unit of least precision in the actual objects, but there could conceivably be other explanations, e.g. the print() function picking up random garbage. Jeroen: Could you save() the results from the two cases, load() them in a new session and compute the difference? > > > You may want to read up on 'what every computer scientist should know about > floating point arithmetic' by Goldberg (which is both a true internet classic) > and ponder why a common setting for the various 'epsilon' settings of general > convergence is set to of the constants supplied by the OS and/or its C > library. R has > > #define SINGLE_EPS FLT_EPSILON > [...] > #define DOUBLE_EPS DBL_EPSILON > > in Constants.h. You can then chase the definition of FLT_EPSILON and > DBL_EPSILON through your system headers (which is a good exercise). > > One place you may end up in the manual -- the following from the GNU libc > documentationon :Floating Point Parameters" > > FLT_EPSILON > This is the minimum positive floating point number of type float such that > 1.0 + FLT_EPSILON != 1.0 is true. It's supposed to be no greater than > 1E-5. > > DBL_EPSILON > LDBL_EPSILON > These are similar to FLT_EPSILON, but for the data types double and long > double, respectively. The type of the macro's value is the same as the > type > it describes. The values are not supposed to be greater than 1E-9. > > So there -- nine digits. > > Dirk > > > | # And this is through eclipse (java) > | > | > sessionInfo() > | R version 2.13.1 (2011-07-08) > | Platform: i686-pc-linux-gnu (32-bit) > | > | locale: > | [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C > | [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 > | [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 > | [7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 > | [9] LC_ADDRESS=en_US.UTF-8LC_TELEPHONE=en_US.UTF-8 > | [11] LC_MEASUREMENT=en_US.UTF-8LC_IDENTIFICATION=en_US.UTF-8 > | > | attached base packages: > | [1] stats graphics grDevices utils datasets methods base > | > | other attached packages: > | [1] rj_0.5.2-1 > | > | loaded via a namespace (and not attached): > | [1] rJava_0.9-1 tools_2.13.1 > | > | > set.seed(123) > | > print(coef(lm(dist~speed, data=cars)),digits=22) > | (Intercept)speed > | > | > | __ > | R-devel@r-project.org mailing list > | https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Gauss once played himself in a zero-sum game and won $50. > -- #11 at http://www.gaussfacts.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard 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
[Rd] Compiling R-2.13.1 with MKL in windows 7 64bit
Hi I don't know how to complie R-2.13.1 with MKL in windows 7 64bit. I can compile normal R in windows using Rtools under R-admin.html description. but, this way doesn't use ./configure file.(use MkRules.local file as setting.). In 'R-admin.html' description, use ./configure --with-blas="$MKL" in which case with MKL compile. But, There is no description when I use MkRules.local setting file. So, I don't understand what I could describe in MkRules.local file in case of compile R-2.13.1 with MKL in windows. Does anyone know how to complie R with MKL in windows? Thanks! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] The C function getQ0 returns a non-positive covariance matrix and causes errors in arima()
Hi,
the function makeARIMA(), designed to construct some state space
representation of an ARIMA model, uses a C function called getQ0,
which can be found at the end of arima.c in R source files (library
stats). getQ0 takes two arguments, phi and theta, and returns the
covariance matrix of the state prediction error at time zero. The
reference for getQ0 (cited by help(arima)) is:
Gardner, G, Harvey, A. C. and Phillips, G. D. A. (1980) Algorithm
AS154. An algorithm for exact maximum likelihood estimation of
autoregressive-moving average models by means of Kalman filtering.
_Applied Statistics_ *29*, 311-322.
where it is called subroutine STARMA (and coded in fortran 77).
My problem is that getQ0 returns incorrect covariance matrices in
certain cases. Indeed, below is an example of a
SARIMA(1,0,1)x(1,0,0)_12 where getQ0 gives a covariance matrix which
possess negative eigenvalues ! Below, I obtain getQ0 results through
makeARIMA().
Example:
s <- 12
phis <- 0.95
phi1 <- 0.0001
phi <- c(phi1,rep(0,s-2),phis,-phi1*phis)
theta <- 0.7
out <- makeARIMA(phi,theta,NULL)
min(eigen(out$Pn)$value)
[1] -19.15890
There are consequences of this "bug" in the functions KalmanLike() and
arima(). Indeed, arima() in its default behaviour uses first CSS
method to get the initial value for an MLE search through optim. To
compute the likelihood, it uses getQ0 at the initialization of the
Kalman Filter. It may happen that getQ0 returns a covariance matrix
which possesses negative eigenvalues and that this gives a negative
gain in the Kalman filter, which in turn gives a likelihood equal to
NaN. Here is a reproducible example where I forced the use of 'ML'.
set.seed(1)
x <- arima.sim(100,model=list(ar=phi,ma=theta))
KalmanLike(x,mod=out,fast=FALSE)
$Lik
ssq
NaN
$s2
ssq
0.971436
arima(x,order=c(1,0,1),seasonal=list(period=12,order=c(1,0,0)),include.mean=FALSE,init=c(phi1,theta,phis),method='ML')
Erreur dans optim(init[mask], armafn, method = optim.method, hessian =
TRUE, :
valeur non-finie fournie par optim
If needed, I can send a more natural example in which the above
behaviour is obtained. This error message ("Error in optim ...
non-finite finite-difference value") was already noted in the
following message, which remained without answer:
https://stat.ethz.ch/pipermail/r-devel/2009-February/052009.html
I could not figure out whether there is a real bug in getQ0 or if this
is due to some numerical instability. However, I tried to replace
getQ0 in two ways. The first one is to compute first the covariance
matrix of (X_{t-1},...,X_{t-p},Z_t,...,Z_{t-q}) and this is achieved
through the method of difference equations (page 93 of Brockwell and
Davis). This way was apparently suggested by a referee to Gardner et
al. paper (see page 314 of their paper).
Q0bis <- function(phi,theta){
## Computes the initial covariance matrix for the state space
representation of Gardner et al.
p <- length(phi)
q <- length(theta)
r <- max(p,q+1)
ttheta <- c(1,theta,rep(0,max(p,q+1)-q-1))
A1 <- matrix(0,r,p)
B <- (col(A1)+row(A1)<=p+1)
C <- (col(A1)+row(A1)-1)
A1[B] <- phi[C[B]]
A2 <- matrix(0,r,q+1)
C <- (col(A2)+row(A2)-1)
B <- (C<=q+1)
A2[B] <- ttheta[C[B]]
A <- cbind(A1,A2)
if (p==0) {
S <- diag(q+1)
}
else {
## Compute the autocovariance function of U, the AR part of X
r2 <- max(p+q,p+1)
tphi <- c(1,-phi)
C1 <- matrix(0,r2,r2)
F <- row(C1)-col(C1)+1
E <- (1<=F)&(F<=p+1)
C1[E] <- tphi[F[E]]
C2 <- matrix(0,r2,r2)
F <- col(C2)+row(C2)-1
E <- (F<=p+1) & col(C2)>=2
C2[E] <- tphi[F[E]]
Gam <- (C1+C2)
g <- matrix(0,r2,1)
g[1] <- 1
rU <- solve(Gam,g)
SU <- toeplitz(rU[1:(p+q),1])
## End of the difference equations method
## Then, compute correlation matrix of X
A2 <- matrix(0,p,p+q)
C <- col(A2)-row(A2)+1
B <- (1<=C)&(C<=q+1)
A2[B] <- ttheta[C[B]]
SX <- A2%*%SU%*%t(A2)
## Now, compute correlation matrix between X and Z
C1 <- matrix(0,q,q)
F <- row(C1)-col(C1)+1
E <- (F>=1) & (F<=p+1)
C1[E] <- tphi[F[E]]
g <- matrix(0,q,1)
if (q) g[1:q,1] <- ttheta[1:q]
rXZ <- forwardsolve(C1,g)
SXZ <- matrix(0, p, q+1)
F <- col(SXZ)-row(SXZ)
E <- F>=1
SXZ[E] <- rXZ[F[E]]
S <- rbind(cbind(SX,SXZ),cbind(t(SXZ),diag(q+1)))
}
Q0 <- A%*%S%*%t(A)
}
The second way is to resolve brutally the equation of Gardner et al.
in the form (12), page 314 of their paper.
Q0ter <- function(phi,theta){
p <- length(phi)
q <- length(theta)
r <- max(p,q+1)
T <- matrix(0,r,r)
if (p) T[1:p,1] <- phi
if (r) T[1:(r-1),2:r] <- diag(r-1)
V <- matrix(0,r,r)
ttheta <- c(1,theta)
V[1:(q+1),1:(q+1)] <- ttheta%x%t(ttheta)
V <- matrix(V,ncol=1)
S <- diag(r*r)-T%x%T
Q0 <- solve(S,V)
Q0 <- matrix(Q0,ncol=r)
}
My conclusion for now is that these two other ways give the same
answers (as returned by all.equ
Re: [Rd] testing a Windows custom installer
Dear Duncan, First, thanks to Duncan and others for addressing my question. In light of Duncan's remarks, I've arrived at the following procedure, which seems to work: (1) Install R using my custom installer. (2) Uninstall the newly installed R. This clears the registry but leaves my other installed versions of R undisturbed. (3) Reinstall R using the custom installer. BTW, following this procedure, I found that an option in the installer that wasn't set the way I want and was able to fix it. Best, John > -Original Message- > From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com] > Sent: July-20-11 10:57 AM > To: John Fox > Cc: R-devel@r-project.org > Subject: Re: [Rd] testing a Windows custom installer > > On 20/07/2011 10:29 AM, John Fox wrote: > > Dear R-devel list members, > > > > For several years, I've created a custom R installer for my students > > who use Windows. When I test the installer on my own Windows machines, > > selections in the installation dialogs reflect my previous choices, > > which I suppose are saved in the Windows registry. > > > > I'd like to be able to see what a student who has never installed R > > before will see, to verify that an installation that takes all > > defaults in the custom installer produces the desired result. In the > > past, I've dealt with this problem by finding a Windows machine on > > which R has never been installed, but that's inconvenient (and, as R > > proliferates will, I hope, become impossible!). Is there a better > approach? > > The settings are saved to the registry by the installer, Inno Setup, and > restored automatically (for most of them), or using its > "GetPreviousData" function (for the R specific ones). I don't think > there is a way to tell the installer to ignore the previous data, but > there might be. > > I believe if you uninstall R then the settings will be forgotten, > because the settings are saved in locations like > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\R > for Windows 2.13.0_is1 in string values named "Inno Setup: *" for the > ones used internally, and "Inno Setup Codefile: > *" for the ones specific to R. > > It's probably okay to delete that whole key and then it will forget the > old settings, but that seems risky. > > There's a command line option to the installer called "/SAVEINF" which > saves the settings to a file and "/LOADINF" which loads them from a > file, but I don't see how to tell it to just ignore the registry > settings. > > Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Randomness not due to seed
On 20 July 2011 at 18:02, peter dalgaard wrote: | | On Jul 20, 2011, at 15:38 , Dirk Eddelbuettel wrote: | | > | > On 20 July 2011 at 14:03, Jeroen Ooms wrote: | > | >> I think Bill Dunlap's answer addressed it: the claim appears to be false. | > | | > | Here is another example where there is randomness that is not due to | > | the seed. On the same machine, the same R binary, but through another | > | interface. First directly in the shell: | > | | > | > sessionInfo() | > | R version 2.13.1 (2011-07-08) | > | Platform: i686-pc-linux-gnu (32-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 | > | | > | > set.seed(123) | > | > print(coef(lm(dist~speed, data=cars)),digits=22) | > | (Intercept) speed | > | -17.579094890510951643137 3.932408759124087715975 | > | > That's PBKAC --- even double precision does NOT get you 22 digits precision. | | Hmm, yes, but you would expect the SAME function on the SAME data to yield the same floating point number, and give the SAME printout on the SAME R on the SAME hardware... | | FWIW all the Mac versions that I can access give the same results as the eclipse version. | | Let's look at the numbers side-by-side | | -17.579094890510951643137 3.932408759124087715975 | -17.579094890510877036153.93240875912408460735 | ! ! | 12.345678901234567890123 1.234567890123456789012 | | so we're seeing differences around the 15th/16th significant digit. This is consistent with a difference of about one unit of least precision in the actual objects, but there could conceivably be other explanations, e.g. the print() function picking up random garbage. Jeroen: Could you save() the results from the two cases, load() them in a new session and compute the difference? Yes 15 to 16 is common. I should have added that to my post when I said '22 is too much'. And I did not want to give the impression that nine is what one gets, nine is the minimum as per the libc docs I quoted but as you illustrate, 15 to 16 can often be had. Thanks for the follow-up. Dirk | > You may want to read up on 'what every computer scientist should know about | > floating point arithmetic' by Goldberg (which is both a true internet classic) | > and ponder why a common setting for the various 'epsilon' settings of general | > convergence is set to of the constants supplied by the OS and/or its C | > library. R has | > | > #define SINGLE_EPS FLT_EPSILON | > [...] | > #define DOUBLE_EPS DBL_EPSILON | > | > in Constants.h. You can then chase the definition of FLT_EPSILON and | > DBL_EPSILON through your system headers (which is a good exercise). | > | > One place you may end up in the manual -- the following from the GNU libc | > documentationon :Floating Point Parameters" | > | > FLT_EPSILON | > This is the minimum positive floating point number of type float such that | > 1.0 + FLT_EPSILON != 1.0 is true. It's supposed to be no greater than 1E-5. | > | > DBL_EPSILON | > LDBL_EPSILON | > These are similar to FLT_EPSILON, but for the data types double and long | > double, respectively. The type of the macro's value is the same as the type | > it describes. The values are not supposed to be greater than 1E-9. | > | > So there -- nine digits. | > | > Dirk | > | > | > | # And this is through eclipse (java) | > | | > | > sessionInfo() | > | R version 2.13.1 (2011-07-08) | > | Platform: i686-pc-linux-gnu (32-bit) | > | | > | locale: | > | [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C | > | [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 | > | [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 | > | [7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 | > | [9] LC_ADDRESS=en_US.UTF-8LC_TELEPHONE=en_US.UTF-8 | > | [11] LC_MEASUREMENT=en_US.UTF-8LC_IDENTIFICATION=en_US.UTF-8 | > | | > | attached base packages: | > | [1] stats graphics grDevices utils datasets methods base | > | | > | other attached packages: | > | [1] rj_0.5.2-1 | > | | > | loaded via a namespace (and not attached): | > | [1] rJava_0.9-1 tools_2.13.1 | > | | > | > set.seed(123) | > | > print(coef(lm(dist~speed, data=cars)),digits=22) | > | (Intercept)speed | > | | | > | | > | __ | > | R-devel@r-project.org mailing list | > | https://stat.ethz.ch/mailman/listinfo/r-devel | > | > -- | > Gauss once played himself in a zero-sum game and won $50. | >
Re: [Rd] Compiling R-2.13.1 with MKL in windows 7 64bit
On 20/07/2011 10:40 AM, WADA Kazuya wrote: Hi I don't know how to complie R-2.13.1 with MKL in windows 7 64bit. I can compile normal R in windows using Rtools under R-admin.html description. but, this way doesn't use ./configure file.(use MkRules.local file as setting.). In 'R-admin.html' description, use ./configure --with-blas="$MKL" in which case with MKL compile. But, There is no description when I use MkRules.local setting file. So, I don't understand what I could describe in MkRules.local file in case of compile R-2.13.1 with MKL in windows. Does anyone know how to complie R with MKL in windows? The Windows make files assume you're using MinGW. If you're not using that compiler, you're on your own. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R-2.13.1 with MKL in windows 7 64bit
On Jul 20, 2011, at 3:01 PM, Duncan Murdoch wrote: > On 20/07/2011 10:40 AM, WADA Kazuya wrote: >> Hi >> >> I don't know how to complie R-2.13.1 with MKL in windows 7 64bit. >> >> I can compile normal R in windows using Rtools under R-admin.html >> description. >> but, this way doesn't use ./configure file.(use MkRules.local file as >> setting.). >> In 'R-admin.html' description, use ./configure --with-blas="$MKL" in >> which case with MKL compile. >> But, There is no description when I use MkRules.local setting file. >> So, I don't understand what I could describe in MkRules.local file in >> case of compile R-2.13.1 with MKL in windows. >> >> Does anyone know how to complie R with MKL in windows? > > > The Windows make files assume you're using MinGW. If you're not using that > compiler, you're on your own. > I think the questions was about MKL BLAS with MinGW. WADA, see Windows FAQ 8.2 - in general, you don't need to compile R against a particular BLAS - you just use shared BLAS and put your favorite BLAS implementation (like MKL) instead of Rblas.dll. The instructions you quote are not for you - they are for unix. I did not use MKL on Windows myself (my tests on OSX indicated that it's slower than ATALS and thus not worth the hassle), so you'll have to try it for yourself. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R-2.13.1 with MKL in windows 7 64bit
On Wed, 20 Jul 2011, Simon Urbanek wrote: On Jul 20, 2011, at 3:01 PM, Duncan Murdoch wrote: On 20/07/2011 10:40 AM, WADA Kazuya wrote: Hi I don't know how to complie R-2.13.1 with MKL in windows 7 64bit. I can compile normal R in windows using Rtools under R-admin.html description. but, this way doesn't use ./configure file.(use MkRules.local file as setting.). In 'R-admin.html' description, use ./configure --with-blas="$MKL" in which case with MKL compile. But, There is no description when I use MkRules.local setting file. So, I don't understand what I could describe in MkRules.local file in case of compile R-2.13.1 with MKL in windows. Does anyone know how to complie R with MKL in windows? The Windows make files assume you're using MinGW. If you're not using that compiler, you're on your own. I think the questions was about MKL BLAS with MinGW. WADA, see Windows FAQ 8.2 - in general, you don't need to compile R against a particular BLAS - you just use shared BLAS and put your favorite BLAS implementation (like MKL) instead of Rblas.dll. The instructions you quote are not for you - they are for unix. I did not use MKL on Windows myself (my tests on OSX indicated that it's slower than ATALS and thus not worth the hassle), so you'll have to try it for yourself. Yes, I think that was the question, and I have used MKL. But its use on Windows is a pain (it took my staff man-days to get the license manager to work), and I would suggest using the Goto BLAS instead: instructions are in the current R documentation (the rw-FAQ AFAIR). Cheers, Simon __ 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
