Mark Dickinson <dicki...@gmail.com> added the comment: > [Me] > > which is a little odd. It's the correct result, but I can't see how [Daniel] > Is it correct?
No. :-) It should be 0, as you say. > Given that "round(2, 2**31)" throws an OverflowError I think this is wrong, too. It should be 2. It's another consequence of the code in bltinmodule.c. The builtin_round function seems unnecessarily complicated: it converts the second argument from a Python object to a C int, then converts it back again before calling the appropriate __round__ method. Then the first thing the __round__ method typically does for built-in types is to convert to a C int again. As far as I can tell the first two conversions are unnecessary. Here's an updated version of the patch that does away with the unnecessary conversions, along with the UNDEF_NDIGITS hack. All tests still pass, on my machine, and with this patch I get the results I'd expect: >>> round(2, 2**31) 2 >>> round(2, 2**100) 2 >>> round(2, -2**100) ^CTraceback (most recent call last): File "<stdin>", line 1, in <module> KeyboardInterrupt >> round(2, 1-2**31) ^CTraceback (most recent call last): File "<stdin>", line 1, in <module> KeyboardInterrupt > That should be optimizable for ndigits > number, and perhaps > log10(number) < k * ndigits (for large ndigits), right? But I don't > think it's a realworld usecase, so dropping this idea for 2.6. Agreed. I don't think this optimization is worth it. Added file: http://bugs.python.org/file12415/round_int_int4.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4707> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
