I'll copy this to the list as it's of general interest. Herein begins
floating-point arithmetic 101. :)
Dave Peticolas writes:
> I wrote
> > it is inevitable that rounding errors will accumulate when
> > adding a large column of figures because none of the quantities being
> > added has an exact binary fractional representation. Rounding after
> > addition will NOT solve this problem.
>
> Why is that? I would have thought that rounding would eliminate the
> introduced error.
Consider adding up, for example 1000000 (one million) identical
transactions, all for $1.01. $1.01 can not be stored exactly -- the
nearest representation is likely to be 1.0099999... In single
precision floating point this is stored to between 6 and 7 d.p. For
the sake of argument let's say 6. So we add 1.009999 to itself one
million times. If our processor was exact we would get the result
1009999.0 and NOT 1010000. Clearly no rounding scheme applied after
the summation can round 1009999.0 to 1010000 without getting other
calculations badly wrong.
That is with an ideal processor with at least 7 guard bits.
Unfortunately the situation with real processors is MUCH worse due to
the finite precision of the result. Halfway through the calculation
the sum is
505000.0 + 1.009999
which stored to 6 significant figures is
505001.0
Notice that this is correct but that we have lost .009999 and this
happens on most of the additions. So in general the result is MUCH
less than the expected one. Try the following program on your computer
#include <stdio.h>
main()
{
int i;
float r=0;
for(i=0; i< 1000000; i++)
r += 1.01;
printf("Result = %16.4f\n",r);
}
Compiled using gcc on a Sun sparc I get "1003222.0". You may
get different results on different machines, with different
optimization levels and ieee rounding modes set. The important lesson
to learn is that although we did our computations to 6 or 7
significant figures individually, the final result is only accurate
to 2 significant figures, and we have lost 4-5 digits of precision.
In some calculations it is quite easy to lose ALL the precision, but
even the most straightforward case of adding a list of values can
cause severe loss of accuracy. Using double precision gives you a
little more headroom, but accuracy is not guaranteed.
Of course there are ways around this. If you add up the numbers in a
different order you will get a different result, since floating point
arithmetic is not associative. For example a binary sum where
numbers are added in pairs and the cycle repeated until only one
result remains will give a more accurate answer. Of course this
sensitivity to the order of addition may not please accountants.
This is why there is an entire field of mathematics - numerical
analysis - devoted to devising ways of performing numerical
calculations accurately using floating-point computer arithmetic. It
is far from easy and far from obvious.
Here endeth the lesson.
--
Dr Keith Refson, "Paradigm is a word too often used by those who would
Dept of Earth Sciences like to have a new idea but cannot think of one."
Parks Road, -- Mervyn King, Deputy Governor, Bank of England
Oxford OX1 3PR, UK
Keith.Refson@ Tel: 01865 272026
earth.ox.ac.uk Fax: 01865 272072
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
