GNOME Bugzilla – Bug 608889
SUM should be more exact
Last modified: 2010-07-28 19:53:58 UTC
SUM really should take more care of how to add: A1: =10^300 A2: =PI()*10^-100 A3: =-(10^300) A5: = SUM(A1:A3) A6: = SUM(A1,A3,A2) then A5 and A6 should really contain the same answer but SUM seems to just add the numbers in given order.
This has popped up before. The current state of affairs is that we add in the given order using long double, if available. (This is not to be confused with --with- long-double.) Various other addition methodologies have been proposed, but I have not seen any that do not just make an equally bad situation pop up elsewhere.
If we are going to solve this -- and that is a fairly big "if" -- then I believe we are going to have to do 1. Add exactly. That means with up to thousands of bits precision. Gnu mpl can do this. 2. Come up with a smart ordering. The best I can think of is... (a) discard zeros. (b) while (multiple addends) either pick two numbers that can be machine added exactly or pick two numbers with smallest possible sum replace the two numbers with their sum In the mixed-sign case I have the feeling that this is very, very expensive.
Order by absolute size (large to small). Sum!
> Order by absolute size (large to small). Sum! Worst possible when all terms are positive.
Ah, now I see what the poster meant about matching up numbers for small sums first -- very interesting problem indeed.
While this is not exactly bug #170000, it is the same general issue. So I'll mark it as a duplicate of that. *** This bug has been marked as a duplicate of bug 170000 ***