On May 3, 3:44 pm, Szabolcs Horvát <[EMAIL PROTECTED]> 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 ? -- http://mail.python.org/mailman/listinfo/python-list
