Daniel Diniz <aja...@gmail.com> added the comment: Mark Dickinson <rep...@bugs.python.org> wrote: > I don't think the hang itself should be considered a bug, any more > than the hang from "10**(2**31-1)" is a bug.
Well, besides the fact that you can stop "10**(2**31-1)" with Ctrl+C but not round(2, -2**31+1), the round case may special case ndigits > number to avoid the slow pow(10, x). >>>> round(2, -2**31+1) > 2 > > which is a little odd. It's the correct result, but I can't see how Is it correct? The answer for 0 > ndigits > -2**301+1 was nan before the patch, 0 after. Given that "round(2, 2**31)" throws an OverflowError, iff this is wrong, should it OverflowError too? > it gets there: under the current algorithm, there should be a > 10**(2**31-1) happening somewhere, and that would take a *lot* of time > and memory. Will investigate. 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. > Aha. The special result for round(x, 1-2**31) has nothing to do > with this particular patch. It's a consequence of: Yep, "predates your patch" as I said :) ---------- versions: -Python 2.6 _______________________________________ 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