Gmpy

Alex Martelli aleax at aleax.it
Thu Aug 7 20:13:15 CEST 2003


Gary Herron wrote:
   ...
> Python has (arbitrarily) long integer support built right in.  For

Oh yes (it's the one bit that initially most attracted me, because
I needed to do some combinatorial-arithmetic computations...), and it's
become even better (faster) in 2.3, with Karatsuba's algorithm for
multiplication.  However...:

> instance:
> 
>>>> ((2**10)**10)**10
>
10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376L

[alex at lancelot Lib]$ python timeit.py '((2**10)**10)**10'
10000 loops, best of 3: 98.5 usec per loop

[alex at lancelot Lib]$ python timeit.py -s'import gmpy'
'((gmpy.mpz(2)**10)**10)**10'
100000 loops, best of 3: 6.47 usec per loop

...gmpy's still way faster (at least on my Athlon machine -- I did
originally choose AMD over Intel essentially by benchmarking the
two possibilities on some heavy computations with GMP...), for this
kind of computation.  This kind of speed improvement, one of more
than an order of magnitude, sometimes makes the difference between
a project being feasible or unfeasible, if computations of this kind
are right on a program's bottleneck.  So, gmpy still has a place, IMHO.


Alex





More information about the Python-list mailing list