Rationals?

[Tim Peters]

[Nick Craig-Wood]
...
> I'm personally more interested in the fixed point numbers rather than
> the rationals, and having played with various implementations of that
> concept recently, I can say that the new decimal module is by far the
> slowest, and gmpy is by far the fastest.
>
> Eg simplistic program to calculate 1000 decimal places of e :-
>
> gmpy.mpf            0.00271s
> FixedPointNcw.py    0.0118s (FixedPoint.py with simple mod for * by int)
> FixedPoint.py       0.358s
> decimal          1546.9s
> 
> People are going to come new to Python and see the decimal type and
> think - oh this looks ideal for high precision calculations, then get
> rather a shock!

When they do, point them at gmpy.

The decimal module's intent is to provide a complete and conforming
implementation of IBM's proposed standard for decimal arithmetic:

    http://www2.hursley.ibm.com/decimal/

gmpy doesn't aim at that.

> The GMP library upon which gmpy it is based
> 
>  http://www.swox.com/gmp/
> 
> is very portable and lovingly maintained by a team of experts ;-)

Yes, and I've been using it since before the world began <wink>.

> Why should python re-implement its own versions of what it does
> when it exists already in a usable (LGPL) format?

As above, GMP''s and decimal's goals have a tiny intersection.

>  In fact I'd go one further and suggest gmpy.mpz() should replace
> long().
...
> Anyway, I see from a bit of googling that python used to have an mpz
> module based on GMP in the stdlib, but it was dropped for some
> reason.  Probably the pain of external library dependencies in cross
> platfor code (a very familiar pain from my day to day working life!).

Nobody cared enough about mpz to support it, and people who cared
enough about GMP to want it were happy enough with the other Python
wrappers (gmpy and Marc-Andre Lemburg's mxNumber).  Or, at least, they
were happy enough that they didn't volunteer work on mpz.  We can only
distribute what people contribute.