Re: operation of 'round' function. Why does it matter?

[Alan Mackenzie]

David Kastrup <David.Kastrup@t-online.de> wrote on 09 Feb 2002 15:06:09 +0100:
> none@example.invalid (Alan Mackenzie) writes:

>> Deepak Goel <deego@glue.umd.edu> wrote on 08 Feb 2002 11:28:38 -0500:

[ .... ]

>> Why on earth does it matter?  Any time you're doing rounding,
>> truncating, flooring, or whatever, you're fudging the result and
>> loosing accuracy.

> "Losing", for heaven's sake, "losing".

Sorry!

> The art of numerics is to lose as little accuracy as possible.
> Rounding to even in number bases divisible by 2 but not by 4 rounds
> away from the next possible point of ambiguity.  That way, a subsequent
> rounding operation will in several cases not continue to add error in
> the same direction in case of another occuring ambiguity.  This means,
> for example, that a+b-b = a+b-b+b-b (bad enough that a+b-b = a does not
> hold).  In case where you are, say, approximating an integral by
> summing differences, not to be sneezed at.  If adding 10000 values
> already introduces a bias of 5000ulp...

The next question is, in this numerical process, how many of the numbers
are _exactly_ n½?  If the answer is "quite a lot", then that suggests
that floating point was the wrong way to go - like, for example somebody
using floating point for Euros, the fractional part representing Cents.
If the answer is "hardly any", like when your digitising an analog
signal, then what the heck.

When you are calculating the integral by summing 10000 values, then
nearly all the time exactly none of them are going to be exactly n½, and
just very, very occasionally, one of them is.  By contrast, how much
accuracy is lost by rounding the 10,000 values before rather than after
summation?  Assuming a uniform distribution of the fractional part, the
mean error is ¼ per value.  Adding 10,000 of these together, the expected
error is SQRT(10,000) x ¼ = 25.

> There is a reason the IEEE mandates rounding to even.  Now of course
> you may feel free to point out that what a floating point processor
> does with its least significant digits need not have any correlation to
> what a function round() supposed to deliver whole numbers does.  But
> what and how numbers are used is probably not always easy to discern.

I've only very rarely used floating point numbers, but I think the best
thing to write into the documentation string for round would be along the
lines "... if the fractional part of a number is exactly 0.5, whether it
will be rounded up or down is implementation dependent."

> -- 
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
> Email: David.Kastrup@t-online.de

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").