This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ajaksu2
Recipients ajaksu2, dingo, giampaolo.rodola, jyasskin, loewis, mark.dickinson, rhettinger
Date 2008-12-21.15:44:04
SpamBayes Score 4.049016e-09
Marked as misclassified No
Message-id <1229874246.48.0.335107500723.issue4707@psf.upfronthosting.co.za>
In-reply-to
Content
Mark Dickinson <report@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 :)
History
Date User Action Args
2008-12-21 15:44:06ajaksu2setrecipients: + ajaksu2, loewis, rhettinger, mark.dickinson, giampaolo.rodola, jyasskin, dingo
2008-12-21 15:44:06ajaksu2setmessageid: <1229874246.48.0.335107500723.issue4707@psf.upfronthosting.co.za>
2008-12-21 15:44:05ajaksu2linkissue4707 messages
2008-12-21 15:44:04ajaksu2create