Author mark.dickinson
Recipients christian.heimes, mark.dickinson, tim.peters
Date 2008-01-16.00:22:45
SpamBayes Score 0.0
Marked as misclassified No
Message-id <>
A related problem is that float(n) isn't always correctly rounded for an integer 
n.  A contrived example:

>>> n = 2**68 + 2**16 - 1
>>> float(n)

Here the difference between float(n) and the true value of n is around 0.99998 
ulps;  a correctly rounded float() would have error at most 0.5 ulps.

I don't regard this as terribly serious: from looking at the code, I *think* 
it's always true that the error is strictly less than 1 ulp, which is just 
enough to guarantee that float(n) == n whenever n is exactly representable as a 

In contrast, the division of two integers can produce results that are up to 3.5 
ulps out from the true value.  This is, in my opinion, a worryingly large error 
for a simple calculation.
Date User Action Args
2009-03-09 14:27:16georg.brandlsetspambayes_score: 0.726136 -> 0.0
2008-01-16 00:22:49mark.dickinsonsetspambayes_score: 0.726136 -> 0.726136
recipients: + mark.dickinson, tim.peters, christian.heimes
2008-01-16 00:22:48mark.dickinsonsetspambayes_score: 0.726136 -> 0.726136
messageid: <>
2008-01-16 00:22:46mark.dickinsonlinkissue1811 messages
2008-01-16 00:22:45mark.dickinsoncreate