This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients mark.dickinson, oscarbenjamin, rhettinger
Date 2013-09-27.18:40:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1380307239.45.0.484925032555.issue19086@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2013-09-27 18:40:39rhettingersetrecipients: + rhettinger, mark.dickinson, oscarbenjamin
2013-09-27 18:40:39rhettingersetmessageid: <1380307239.45.0.484925032555.issue19086@psf.upfronthosting.co.za>
2013-09-27 18:40:39rhettingerlinkissue19086 messages
2013-09-27 18:40:38rhettingercreate