Raymond Hettinger added the comment: FWIW, the reason for __builtin__.sum() having a start argument was so that it could change the base datatype: sum(iterable, start=Fraction(0)).
[Oscar Benjamin] > Although fsum is internally very accurate > it always discards information on output. A "start" argument won't help you, because you will discard information on input. A sequence like [1E100, 0.1, -1E100, 0.1] wouldn't work when split into subtotal=fsum([1E100, 0.1]) and fsum([-1E100, 0.1], start=subtotal). > My motivation for this is that I want to be able to write > an efficient sum function that is accurate for a mix of ints > and floats FWIW, fsum() already works well with integers as long as they don't exceed 53bits of precision. For such exotic use cases, the decimal module would be a better alternative. Now that the decimal module has a C implementation, there is no reason not to use it for high precision applications. It is possible to extent the current fsum() implementation to separately track integers and combine it with the float results at the end. That said, the probability that any user (other than yourself) will need this can only be expressed as a denormal number ;-) I'm not rejecting the request; rather, I'm questioning the need for it. ---------- _______________________________________ 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
