From tplate at acm.org  Tue May 30 20:23:42 2006
From: tplate at acm.org (Tony Plate)
Date: Tue, 30 May 2006 12:23:42 -0600
Subject: [Rd] Numerical error in R (win32) (PR#8909)
In-Reply-To: <20060530124306.C0DBE3F045@slim.kubism.ku.dk>
References: <20060530124306.C0DBE3F045@slim.kubism.ku.dk>
Message-ID: <447C8DAE.5070609@acm.org>

Beyond the R FAQ 7.31 the article "What Every Computer Scientist Should 
Know About Floating-Point Arithmetic, by David Goldberg" 
(http://docs.sun.com/source/806-3568/ncg_goldberg.html) is very 
informative, but it is rather long (this topic has many subtleties). 
Wikipedia has a shorter page on "Floating point arithmetic", 
(http://en.wikipedia.org/wiki/Floating_point) which covers some of the 
most important points for scientists who are not computer scientists, 
and also has many links.

If it's really important to have exact representation for decimal 
fractions, then look at the draft IEEE proposal for "General Decimal 
Arithmetic" (http://www2.hursley.ibm.com/decimal/ ) which states:  "Most 
computers today support binary floating-point in hardware.  While 
suitable for many purposes, binary floating-point arithmetic should not 
be used for financial, commercial, and user-centric applications or web 
services because the decimal data used in these applications cannot be 
represented exactly using binary floating-point. (See the Frequently 
Asked Questions pages for more explanation and examples.)"

(I would quibble with the blanket statement that "binary floating-point 
arithmetic should not be used for financial [...] applications" -- it 
all depends on the needs of the particular financial application.)

I don't believe that there are any facilities in R for doing decimal 
arithmetic, but I would guess that some accounting applications might 
offer some.

-- Tony Plate

(I removed R-bugs from the cc list because it's not a bug, as has 
already been noted.)

teck.lim at imperial.ac.uk wrote:
> Hi
> 
> 	Thanks for the quick reply. However, I am not satisfied, as
> 
>>round(3.15000000, 1)
> 
> [1] 3.1
> 
>>round(3.75000000, 1)
> 
> [1] 3.8
> 
> 	I think the problem is really more of an error in the rounding off
> algorithm than finite precision.
> 
> Thanks
> Teckpor 
> 
> -----Original Message-----
> From: Uwe Ligges [mailto:ligges at statistik.uni-dortmund.de] 
> Sent: Monday, May 29, 2006 17:45
> To: teck.lim at imperial.ac.uk
> Cc: R-bugs at biostat.ku.dk
> Subject: Re: [Rd] Numerical error in R (win32) (PR#8909)
> 
> teck.lim at imperial.ac.uk wrote:
> 
> 
>>Hi
>>    I had observed the following problem in R (also C, Matlab, and
> 
> Python).
> 
>>sprintf('%1.2g\n', 3.15)
>>give 3.1 instead of 3.2 whereas an input of 3.75 gives 3.8.
>>Java's System.out.printf is ok though.  
>> 
>>
>>
>>>round(3.75,1)
>>
>>[1] 3.8
>>
>>
>>>round(3.15,1)
>>
>>[1] 3.1
>> 
>>Similar outcome with sprintf in R.
>>
>>
>>However, the right answer should be 3.2
> 
> 
> This is not a bug.
> 
> Please read the R FAQ "Why doesn't R think these numbers are equal?" and
> after that note that *numerically* the following inaqualities are TRUE:
> (3.2 - 3.15) > 0.05
> (3.15 - 3.1) < 0.05
> 
> Uwe Ligges
> 
> 
> 
>>Regards
>>Teckpor
>> 
>>
>>	[[alternative HTML version deleted]]
>>
>>______________________________________________
>>R-devel at r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



[Rd] Numerical error in R (win32) (PR#8909)
Tony Plate