> -----Original Message----- > From: r-help-boun...@r-project.org > [mailto:r-help-boun...@r-project.org] On Behalf Of Martin Batholdy > Sent: Wednesday, September 30, 2009 12:18 PM > To: Duncan Murdoch > Cc: r help > Subject: Re: [R] Rounding error in seq(...) > > hum, > > can you explain that a little more detailed? > Perhaps I miss the background knowledge - but it seems just > absurd to > me. > > 0.1+0.1+0.1 is 0.3 - there is no rounding involved, is there? > > why is > x <- 0.1 + 0.1 +0.1 > not equal to > y <- 0.3 >
Let's do this in base 10, since it is more familiar. Suppose we decide, for efficiency reasons to store all numbers to 2 significant decimal digits. Then 1/3 gets stored as 0.33 and stored(1/3)+stored(1/3)+stored(1/3) is stored(0.99), not 1.0. (Here stored() is the function that maps a number to the 2 decimal digit number closest to it.) For efficiency reasons standard computer representation of number with fractional part involves 52 significant binary digits. 1/10 in base 10 is like 1/3 in base 2: it cannot be represented exactly with 52 significant binary digits. Hence we cannot expect that as.double(1/10)+ <8 reps> +as.double(1/10) will be exactly 1.0. (Here, as.double is not the R function but the mathematical function that maps a number to the double precision number closest to it.) Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com > ? > > > > Am 30.09.2009 um 21:04 schrieb Duncan Murdoch: > > > On 9/30/2009 2:50 PM, Michael Knudsen wrote: > >> On Wed, Sep 30, 2009 at 8:44 PM, Duncan Murdoch > >> <murd...@stats.uwo.ca> wrote: > >>> Why? You asked for an increment of 1 in the second case > (which is > >>> exactly > >>> represented in R), then divided by 10, so you'll get the same as > >>> 0.3 gives > >>> you. In the seq() case you asked for an increment of a number > >>> close to but > >>> not equal to 1/10 (because 1/10 is not exactly representable in > >>> R), so you > >>> got something different. > >> Well, the problem is that I don't know how seq is > implemented. I just > >> assumed that it wouldn't behave like this. > > > > It doesn't really matter how it is implemented: if you ask > to start > > at 0.1 and increment by 0.1, you should expect the result > to be the > > same as > > > > 0.1 > > 0.1+0.1 > > 0.1+0.1+0.1 > > etc. > > > > and I think it is. The problem is that 0.1+0.1+0.1 is not > the same > > as 0.3, due to rounding. Neither 0.1 nor 0.3 can be represented > > exactly in the standard IEEE floating point formats that R uses. > > > > Duncan Murdoch > > > > ______________________________________________ > > R-help@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. > > ______________________________________________ > R-help@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. > ______________________________________________ R-help@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.
