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.)