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