[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: operation of 'round' function. Why does it matter?
Date: 11 Feb 2002 22:38:57 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

address@hidden (Alan Mackenzie) writes:

> David Kastrup <address@hidden> wrote on 09 Feb 2002 15:06:09 +0100:

> >> Why on earth does it matter?  Any time you're doing rounding,
> >> truncating, flooring, or whatever, you're fudging the result and
> >> loosing accuracy.
> > 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 [...]

This is nonsense.  Whenever you are adding or subtracting numbers with
a result that carries over in the most significant digit, you lose a
single digit of accuracy from the number greater in magnitude.  If it
shares the exponent with the number lesser in magnitude, half of the
numbers to be rounded will be of the form n½.  Only when the numbers
added differ by several binary orders of magnitude will the event of
having exactly n½ to round become unlikely.

> 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½,

Says who?

> 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.

The mean absolute error.  The standard deviation, however, is
sqrt(1/12).  The expected distribution will be almost normal with a
standard deviation of sqrt(10000/12).

> Adding 10,000 of these together, the expected
> error is SQRT(10,000) x ¼ = 25.

I get something closer to 23.

> 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."

Finally something with which I find myself able to agree.

David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]