On 16 Mar 2003, Peter Dalgaard BSA wrote: > Rashid Nassar <[EMAIL PROTECTED]> writes: > > > Many thanks to all for the very quick replies. I should have stated the > > apparent problem more clearly: round() does not seem to always round 5 to > > the nearest even value as I expected, as my examples (repeated below) > > showed: > > > > > round(2.45, 1) > > [1] 2.5 # shouldn't this be 2.4? > > > > > round(1.05, 1) > > [1] 1.1 # 1.0 ? > > > > > signif(3.445, 3) > > [1] 3.45 # 3.44 ? > > > > Apologies for not stating this more clearly in my first message, and again > > thanks for the replies. > > Yes. From my reading of the code, I would expect 2.4 in the first case > as well. It appears that the intention is to subtract off the integer > part, scale according to the number of digits and round nnn.5 +- eps > towards even values of nnn, but that's not what is happening. > > Anyone want to trace through the code and see what is going on?
As people have already suggested, inexact representation. 2.45 is being represented as 2.4500000000000002 on my system when printed out from the C code in fround. It is not a binary fraction and so cannot be represented exactly (in standard hardware). The calculation does (2.45 - 2)*10 and rounds it, and that is just greater than 4.5 (which could be represented exactly). Try this: > x <- 2.45 > (100*x - 245) [1] 2.842171e-14 which is fairly firm evidence that the representation error is positive, as multiplication by 100 should be exact. Note though that the print routine will multiply by powers of 10 so the only sure way is to read the bit pattern and compute exactly from that. -- Brian D. Ripley, [EMAIL PROTECTED] 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, UK Fax: +44 1865 272595 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
