Re: Feature suggestion: sum() ought to use a compensated summation algorithm

On May 3, 3:44 pm, Szabolcs Horvát <szhor...@xxxxxxxxx> wrote:
Arnaud Delobelle wrote:

sum() works for any sequence of objects with an __add__ method, not
just floats!  Your algorithm is specific to floats.

This occurred to me also, but then I tried

sum(['abc', 'efg'], '')

and it did not work.  Or is this just a special exception to prevent the
  misuse of sum to join strings?  (As I said, I'm only an occasional user.)

Generally, sum() seems to be most useful for numeric types (i.e. those
that form a group with respect to __add__ and __neg__/__sub__), which
may be either exact (e.g. integers) or inexact (e.g. floating point
types).  For exact types it does not make sense to use compensated
summation (though it wouldn't give an incorrect answer, either), and
sum() cannot decide whether a user-defined type is exact or inexact.

But I guess that it would still be possible to make sum() use
compensated summation for built-in floating point types (float/complex).

Or, to go further, provide a switch to choose between the two methods,
and make use compensated summation for float/complex by default.  (But
perhaps people would consider this last alternative a bit too messy.)

(Just some thoughts ...)

The benefits should be weighted considering the common case. For
example, do you find an error of 10^-14 unbearable ? How many times
someone will add 1.000.000 numbers in a typical scientific application
written in python ?

I believe that moving this to third party could be better. What about
numpy ? Doesn't it already have something similar ?
.

Relevant Pages