From pdalgd at gmail.com  Wed Jul 20 18:02:39 2011
From: pdalgd at gmail.com (peter dalgaard)
Date: Wed, 20 Jul 2011 18:02:39 +0200
Subject: [Rd] Randomness not due to seed
In-Reply-To: <20006.55884.14520.313303@max.nulle.part>
References: <1311081181602-3678082.post@n4.nabble.com>
	<BLU166-w543D75409AB00B2B1DB127BE4C0@phx.gbl>
	<4E26C175.1070806@gmail.com>
	<CABFfbXutiefddok9WWSxq0vYiwAomLA3hcmma5nW0PwJyJ8UfQ@mail.gmail.com>
	<20006.55884.14520.313303@max.nulle.part>
Message-ID: <0348E92E-B044-4954-95F9-BE8C32C22E21@gmail.com>


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-8        LC_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.57909489051087703615    3.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-8        LC_TELEPHONE=en_US.UTF-8
> | [11] LC_MEASUREMENT=en_US.UTF-8    LC_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 at 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 at 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.mes at cbs.dk  Priv: PDalgd at gmail.com



[Rd] Randomness not due to seed
peter dalgaard