Raymond Hettinger added the comment:
Conceptually, I support the idea of having some way to avoid information loss
by returning uncollapsed partial sums. As you say, it would provide an
essential primitive for parallel fsums and for cumulative subtotals.
If something along those lines were to be accepted, it would likely take one of
two forms:
fsum(iterable, detail=True) --> list_of_floats
fsum_detailed(iterable) --> list_of_floats
Note, there is no need for a "carry" argument because the previous result can
simply be prepended to the new data (for a running total) or combined in a
final summation at the end (for parallel computation):
detail = [0.0]
for group in groups:
detail = math.fsum_detailed(itertools.chain(detail, group))
print('Running total', math.fsum(detail))
On the negative side, I think the use case is too exotic and no one will care
about or learn to use this function. Also, it usually isn't wise to expose the
internals (we may want a completely different implementation someday). Lastly,
I think there is some virtue in keeping the API simple; otherwise, math.fsum()
may ward-off some its potential users, resulting in even lower adoption than we
have now.
With respect to the concerns about speed, I'm curious whether you've run your
msum() edits under pypy or cython. I would expect both to give excellent
performance.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
