From teck.lim at imperial.ac.uk  Tue May 30 14:42:43 2006
From: teck.lim at imperial.ac.uk (ltp)
Date: Tue, 30 May 2006 13:42:43 +0100
Subject: [Rd] Numerical error in R (win32) (PR#8909)
In-Reply-To: <447B2413.1@stats.uwo.ca>
Message-ID: <002f01c683e6$8b9ac2d0$f9bec69b@ltpfujitsu>

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: Duncan Murdoch [mailto:murdoch at stats.uwo.ca] 
Sent: Monday, May 29, 2006 17:41
To: teck.lim at imperial.ac.uk
Cc: r-devel at stat.math.ethz.ch; R-bugs at biostat.ku.dk
Subject: Re: [Rd] Numerical error in R (win32) (PR#8909)

On 5/29/2006 12:22 PM, 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.  There is no way to represent 3.15 exactly in double
precision, so it is hard to predict whether it will round up or down. 
Apparently on the machine you were using it is represented as a number
slightly less than 3.15, which rounds down.

Duncan Murdoch



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