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 georg.brandl, mark.dickinson
Date 2008-07-26.10:03:07
SpamBayes Score 3.23667e-05
Marked as misclassified No
Message-id <1217066590.91.0.392238513019.issue3421@psf.upfronthosting.co.za>
In-reply-to
Content
Sadly, this is not the only problem with math.sum on x86 hardware right 
now.  I'd guess that this is another problem related to double-rounding 
and the use of 80-bit floating-point registers on x86.  Raymond and I 
are still actively looking for ways to fix math.sum up, including the 
possibility of a complete rewrite using a totally different algorithm.

With the current algorithm, behaviour at or near the boundary of the 
floating-point range should really be considered undefined;  so the 
quick fix is to update the tests and docs to reflect this.  The 
particular test that causes test.math to fail would just be removed.

I am intrigued that py3k and the trunk give different results, though;  
I'd very much like to know where the difference comes from.

Georg, *only if you have time*, could you please tell me what results 
the linux box gives for the following two Python sums, in both py3k and 
the trunk:

>>> 1e16 + 2.9999
10000000000000002.0
>>> 1.7976931348623157e+308 + 9.979201547673598e+291
1.7976931348623157e+308

(The results shown are the ones I get on OS X 10.5.4;  I don't have 
access to a linux box for testing at the moment.)
History
Date User Action Args
2008-07-26 10:03:11mark.dickinsonsetspambayes_score: 3.23667e-05 -> 3.23667e-05
recipients: + mark.dickinson, georg.brandl
2008-07-26 10:03:10mark.dickinsonsetspambayes_score: 3.23667e-05 -> 3.23667e-05
messageid: <1217066590.91.0.392238513019.issue3421@psf.upfronthosting.co.za>
2008-07-26 10:03:09mark.dickinsonlinkissue3421 messages
2008-07-26 10:03:07mark.dickinsoncreate