New submission from Neil <na...@raytheon.com>: round() returns incorrect results for certain large real-integer arguments. Demonstration via interpreter session: >>> x = 2.0**52+1 # Huge, odd double integer near limits of what IEEE format >>> can fully represent in its mantissa part >>> round(x) - x # Difference should be zero 1.0 >>> x = 2.0**53+1 # Even larger odd argument ... >>> round(x) - x # ... returns correct result! 0.0 >>> x = 2.0**51+1 # And a smaller argument ... >>> round(x) - x # ... also returns correct result! 0.0
Discussion: It is not sufficient to implement round(x) as ceil(x - .5) for negative x and floor(x + .5) otherwise, since large integers near the representation limits will be changed incorrectly by these operations, apparently due to internal FPU semantics. One must test the argument first to see if it is a floating-point integer (e.g., math.floor(x) == x), and only bias & truncate towards zero if it is not. C math libraries that implement round(), such as on Linux & MacOS, do this correctly. ---------- components: None messages: 135724 nosy: nasix priority: normal severity: normal status: open title: round() erroneous for some large arguments type: behavior versions: Python 2.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12052> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
