Gmpy

[Jean-Pierre Andreaux]

Gmpy module was a wrapper of the GNU MP library. It seems that no
evolution is done on this module since 2001. Indeed, Gmpy is not
supported in Python 2.2 nor 2.3.

My question is the following: what is the better replacement solution
for manipulating long numbers. I want to do long numbers
exponentiations. Thanks in advance for your answers.

JP

 

[Gary Herron]

Gmpy module was a wrapper of the GNU MP library. It seems that no
evolution is done on this module since 2001. Indeed, Gmpy is not
supported in Python 2.2 nor 2.3.

My question is the following: what is the better replacement solution
for manipulating long numbers. I want to do long numbers
exponentiations. Thanks in advance for your answers.

JP

Python has (arbitrarily) long integer support built right in. For instance:
10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376L

Notice the 'L' on the end of the result implies the value is a "long'
integer, not a 32-bit integer.

In recent versions of Python, arithmetic on normal integers will
convert to long integers when an overflow occurs.

Is this what you wanted?

Gary Herron

 

[Alex Martelli]

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:

10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376L

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

[alex@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

 

[Carl Banks]

Gmpy module was a wrapper of the GNU MP library. It seems that no
evolution is done on this module since 2001. Indeed, Gmpy is not
supported in Python 2.2 nor 2.3.

My question is the following: what is the better replacement solution
for manipulating long numbers. I want to do long numbers
exponentiations. Thanks in advance for your answers.

An alternative is egenix mxNumber package, still in beta stage.

http://www.egenix.com/files/python/mxNumber.html

I couldn't use gmpy because I needed floating point, and mxNumber also
wraps the floating point functionality. It seemed to work ok.

 

[Alex Martelli]

An alternative is egenix mxNumber package, still in beta stage.

http://www.egenix.com/files/python/mxNumber.html

I couldn't use gmpy because I needed floating point, and mxNumber also
wraps the floating point functionality. It seemed to work ok.

gmpy also wraps the floating-point functionality of GMP:
2.333333333333333333333333333333333333333


Alex

 

[Carl Banks]

gmpy also wraps the floating-point functionality of GMP:

2.333333333333333333333333333333333333333

I'm sorry--I was thinking of the mpz module. I remember looking at
gmpy but passed on it for some reason--probably something silly. In
any case, mxNumber worked well enough so I stuck with it.

 

[Ernie]

gmpy also wraps the floating-point functionality of GMP:

2.333333333333333333333333333333333333333

I am using the XR package from
http://more.btexact.com/people/briggsk2/XR-2.0.tgz and want to try out
the gmpy for comparison. However, trying to install
gmpy-sources-09a21.zip, results in an error:

running install
running build
running build_ext
building 'gmpy' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC -I/usr/local/include/python2.3 -c gmpy.c -o
build/temp.linux-i686-2.3/gmpy.o
In file included from /usr/local/include/python2.3/Python.h:8,
from gmpy.c:101:
/usr/local/include/python2.3/pyconfig.h:844:1: warning:
"_POSIX_C_SOURCE" redefined
In file included from /usr/include/assert.h:36,
from gmpy.c:96:
/usr/include/features.h:171:1: warning: this is the location of the
previous definition
gmpy.c: In function `Pygmpy_rand':
gmpy.c:5053: structure has no member named `seed'
error: command 'gcc' failed with exit status 1

Ernie

 

[Alex Martelli]

Ernie wrote:
...

the gmpy for comparison. However, trying to install
gmpy-sources-09a21.zip, results in an error: ...
gmpy.c: In function `Pygmpy_rand':
gmpy.c:5053: structure has no member named `seed'
error: command 'gcc' failed with exit status 1

Right -- I could SWEAR I've fixed this a zillion times
after the GMP library made an incompatible change in one
of its header files, but apparently the fix didn't
make it to a release. Could you try a CVS snapshot?
Meanwhile I hope to make time to put a fixed release
together in the weekend...


Thanks,

Alex

 

[Alex Martelli]

Carl Banks wrote:
...

I'm sorry--I was thinking of the mpz module. I remember looking at
gmpy but passed on it for some reason--probably something silly. In
any case, mxNumber worked well enough so I stuck with it.

I'm sure mxNumber works just fine, but for some users installing all
of mx-base first, then all of mx-experimental, might be a bit much,
perhaps, if all they need is the use of GMP (also, I don't think the
egenix stuff supports Python 2.3 yet? no doubt just temporarily).

So, anyway, I've just updated gmpy with a few outstanding issues (all
already solved in CVS, except one case of misdiagnosis when wrong
numbers of arguments were passed to some functions, kindly reported
by Paul Rubin -- but I hadn't done a "file release" to pick up the
CVS enhancements in quite a long while!) and released it as 1.0 alpha.
The released Windows binaries, by the way, now require Python 2.3.


Alex