Hello,
I have tried my previous TestCase on Office XP, too, and found similar
errors, but this should NOT preclude making Calc a better software.
However, I found something interesting. If you remember, I added some
numbers in various orders and found differences in the results. (The
correct result would have been: *-*0.00001111).
*SUM* *0.00000000* *0.00000000* *-0.00001063* *-0.00001145*
*FALSE* *FALSE* *ALMOST* *EVEN*
*CORRECT* *CLOSER*
As I sad, I tested this in Office XP, too. Here are the results:
*SUM* *0.00E+000* *-1.19E-005* *0.00E+000* *0.00E+000*
What one notes is, that Exel calculates for column 3 the number almost
correct (well OOo is more accurate when comparing this result with that
from columns 3 and 4). The point is that the big numbers cancel out in
column 3, and therefore this column is the simple addition of: -10^-5,
-10^-6, ..., so it SHOULD have been accurate in OOo, too. I believe that
Calc does some over-rounding (more than needed; but could be needed in
other operations, so that will be difficult to test or change).
While the difference may seem trivial to some, and the spread of the
numbers I choose very big (10^10 to 10^-8), please note that the sample
is very small, only 36 numbers. As the sample gets bigger, so does the
error, and as the spread gets bigger, the error rises, too. BUT even a
moderate spread on a sufficiently big sample will generate significant
errors. Especially as the sum is used in so many formulas, the error is
perpetuated and could have dramatic consequences.
Can somebody test how fast a sorting algorithm for numbers is? (we do
NOT need the sign for this sorting)
