[issue1811] True division of integers could be more accurate
Mark Dickinson
report at bugs.python.org
Wed Jan 16 01:22:48 CET 2008
Mark Dickinson added the comment:
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)
2.9514790517935283e+20
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
float.
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.
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1811>
__________________________________
More information about the Python-bugs-list
mailing list