Mark Dickinson <[EMAIL PROTECTED]> added the comment: 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.) _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3421> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
