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 mark.dickinson
Recipients MrJean1, mark.dickinson, rhettinger
Date 2008-07-26.10:38:36
SpamBayes Score 1.97036e-05
Marked as misclassified No
Message-id <1217068721.62.0.551524870004.issue2819@psf.upfronthosting.co.za>
In-reply-to
Content
Here's a patch giving an alternative implementation of math.fsum; it's 
based on Tim Peter's suggestions, works mostly with integer arithmetic, 
and so bypasses problems with double rounding and extended precision 
floats.

The patch is experimental:  it doesn't have sufficient tests, has no 
documentation, and it adds math.fsum alongside the current math.sum, to 
make it easy to compare the two implementations.

On my MacBook, math.fsum is a factor of 2-3 times slower than math.sum.
It's also longer and distinctly less elegant.  So its only real 
advantage is that it should fix the difficulties on x86 hardware.

We *really* need to sort math.sum out, one way or another, before the 
next beta.  Georg recently discovered another problem on x86/Linux:  see 
issue 3421.

Some options:

 (1) leave math.sum as it is, skip all tests on x86/Linux, and document
     the current behaviour.

 (2) investigate a version of math.sum that plays with the FPU control 
word to force 53-bit rounding (and round-half-even)

 (3) replace math.sum with the slower but (presumably) less erratic 
math.fsum, possibly just as a temporary measure.  This would at least 
get all tests passing.

Jean, Raymond:  what do you think?
History
Date User Action Args
2008-07-26 10:38:42mark.dickinsonsetspambayes_score: 1.97036e-05 -> 1.97036e-05
recipients: + mark.dickinson, rhettinger, MrJean1
2008-07-26 10:38:41mark.dickinsonsetspambayes_score: 1.97036e-05 -> 1.97036e-05
messageid: <1217068721.62.0.551524870004.issue2819@psf.upfronthosting.co.za>
2008-07-26 10:38:41mark.dickinsonlinkissue2819 messages
2008-07-26 10:38:40mark.dickinsoncreate