Oscar Benjamin added the comment: Thanks for responding Raymond.
Raymond Hettinger wrote: > 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). I'm not sure if you've fully understood the proposal. The algorithm underlying fsum is (I think) called distillation. It compresses a list of floats into a shorter list of non-overlapping floats having the same exact sum. Where fsum deviates from this idea is that it doesn't return a list of floats, rather it returns only the largest float. My proposal is that there be a way to tell fsum to return the list of floats whose sum is exact and not rounded. Specifically the subtotal that is returned and fed back into fsum would be a list of floats and no information would be discarded. So fsum(numbers, []) would return a list of floats and that list can be passed back in again. > > 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. I was simplifying the use-case somewhat. I would also like this sum function to work with fractions and decimals neither of which coerces exactly to float (and potentially I want some non-stdlib types also). > 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 coerce to Decimal and exactly sum a list of ints, floats and decimals (by trapping inexact and increasing the context precision). I have tried this under CPython 3.3 and it was 20-50x slower than fsum depending on how it manages the arithmetic context and whether it can be used safely with a generator that also manipulates the context - the safe version that doesn't build a list is 50x slower. It is also not possible to use Decimal exactly with Fractions. I believe that there are other use-cases for having fsum be usable incrementally. This would make it usable for accurate summation in incremental, parallel and distributed computation also. Unfortunately fsum itself already isn't used as much as it should be and I agree that probably all the use cases for this extension would be relatively obscure. ---------- _______________________________________ 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