Home Original page

Long int too large to convert?

Markus Schaber markus at schabi.de
Wed Sep 12 17:06:34 EDT 2001 
Hi,

fbasegmez <fb at ultranet.com> schrub:
>>>> for i in xrange(1L, 5 * pow(10L, 40)):
> ...   x = i * x
> ...
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> OverflowError: long int too large to convert
> Any ideas?

The Problem seems to be that xrange only accepts values in the range of 
integers. Pow(10L, 40) = 10000000000000000000000000000000000000000 (one 
could also write 10**40L) just is too big.

Your example, assuming you can run it with one loop per processor clock 
tick (which would assume a that you have a highly optimizing compiler, 
and that you can in parallel add and multiply long ints in one cycle), 
running at 1 GigaHertz clock speed, would - roughly estimated - still 
need about 1585489599188229325215625 years to compute.

Not even thinking about storing the result in a computers memory.

And in my python documentation, I find the info that xrange " is very 
similar to range()". And about range, it says "The arguments must be 
plain integers.".

Personally, I think it doesn't make sense to have ranges and xranges 
that need long integers for displaying their length. (Ranges of such 
size wouldn't even have enough place in today's 32 bit machines memory, 
and xranges would need a looong time to loop through.)

But there may be reasons to open ranges and xranges for long ints, such 
that you can e. G. define an xrange(10**40, 2*(10**40), 10**39) which 
has 10 elements - maybe this comes "automagically" with the int/long 
unification.

> First I was going to use scientific notation instead of pow(x, y) but
> then I decided not to because,
>>>> long(5e40)
> 50000000000000000310004322520389159747584L
>>>>
> I am aware of numerical precision issues but this still managed to
> surprise me.

Scientific notation uses floats, which have only a limited number of 
significant digits (the number was between 15 and 17, AFAIR) and are 
stored as a mantissa and an exponent in base2 internally.

10**40 is about 2**132.877123795. So as long as you have less then 133 
bits for the mantissa, the computer can only approximate it, the lower 
bits are lost. (And usual IEEE double precision format has 64 bits for 
exponent, mantissa and sign)

I hope I could clear up some of the mysteries of large numbers - if 
not, don't refuse to ask again :-)
markus
-- 
"The strength of the Constitution lies entirely in the determination of 
each citizen to defend it. Only if every single citizen feels duty 
bound to do his share in this defense are the constitutional rights 
secure." -- Albert Einstein
More information about the Python-list mailing list