newbie: precision question

Mensanator mensanator at
Sat Mar 21 05:57:27 CET 2009

On Mar 20, 11:02�pm, Lada Kugis <lada.ku... at> wrote:
> On 21 Mar 2009 03:34:18 GMT, Steven D'Aprano
> <st... at> wrote:
> Hello Steven,
> thanks for answering on such short notice,
> >Floats in Python don't have infinite precision.
> >Ints (or longs) can have infinite precision. Try calculating (say)
> >1234567**315*24689 and you should get 1923 digits. By the way, you can do
> >calculations on ints with tens of thousands of digits *much* faster than
> >you can print those same ints: on my computer, calculating all 75199
> >digits of 1234567**12345 takes less than an eye-blink, while printing it
> >takes ages.
> Yes, I've tried things like>>> print 2**10000

I usually use the gmpy library as it tends to be better
than native Python and includes a lot of stuff Python
doesn't have.

Incredible as it seems, you CAN get carried away with
such capability. This function, from my Collatz library:

    # a = (i-1)*9**(k-1) + (9**(k-1) - 1)/2 + 1
    # return 2**(6*a - 1) - 1

grows VERY quickly. At (6,1) the number has 55,338 decimal
digits (takes several pages of 11x17 paper printed at 6 point font).
I can't even do (11,1) because I get an "Outrageous Exponet"
exception (attemps to create 2 raised to the power of over 2

> (gives a large, really mind-boggingly huge big number :)
> So, if I understood you right, integers can have infinite precision

Keep in mind you are still limited by how much RAM you have,
although with today's computers that's not an issue...most of the
"Arbitrary" is probably a better term than "infinite".

> and floating points are up to 16 digits

Some libraries (such as gmpy) can give you arbitrary
precision floats if you need them. But gmpy also has
arbitrary precision rationals. These are worth checking out.
In my usage, all calculations are done in rationals, which
prevents any rounding errors. Only when I need it displayed
do I convert it to an arbitrary precision float.

> (if I remember anything they
> thought me in my C classes) because they cannot be represented exactly
> in binary form. C representation, can of course vary according to
> platform, compiler etc.
> Normal integers are up to 10 digits, after which they become long
> integers, right ?

The conversion is automatic, you usually don't have to be concerned
with overflow with integers.

> But if integers can be exactly represented, then why do they need two
> types of integers (long and ... uhmm, let's say, normal). I mean,
> their error will always be zero, no matter what kind they're of.
> Lada
> >Floats, on the other hand, are effectively the same as double on the C
> >compiler for your platform.
> >Does this answer your question?

More information about the Python-list mailing list