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

[hdante]

On May 3, 3:44 pm, Szabolcs Horvát <szhor... at gmail.com> 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 ?