[issue4707] round() shows undocumented behaviour

[Daniel Diniz]

Daniel Diniz <ajaksu at gmail.com> added the comment:

Mark Dickinson <report at 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 <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________