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 <[EMAIL PROTECTED]> <http://bugs.python.org/issue1811> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
