[Python-numerics]Re: [Python-Dev] Re: WYSIWYG decimal fractions

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [Alex Martelli]
> > ...
> > There's another free library that interoperates with GMP to remedy
> > this -- it's called MPFR and lives at http://www.loria.fr/projets/mpfr/.
> > It's also LGPL.  I haven't looked much into it as it seems it's not been
> > ported to Windows yet (and that looks like quite a project) which is
> > the platform I'm currently using (and, rationals do what I need:-).
> 
> Thanks for the pointer!  From a quick skim, good news & bad news (although
> which is which may depend on POV):
> 
> + The authors apparently believe their MPFR routines "should replace
>   the MPF class in further releases of GMP".  Then somebody else will
>   port them.

...or simply install both packages...
 
> + Allows exact specification of result precision (which will make the
>   results 100% platform-independent, unlike GMP's).

This is a Good Thing :)
 
> + Allows choice of IEEE 754 rounding modes (unlike GMP's truncation).
> 
> + But is still binary floating-point.

:-(
 
> Marc-Andre is especially interested in decimal fixed- and floating-point, and
> even more specifically than that, of a flavor that will be efficient for
> working with decimal types in databases (which I suspect-- but don't
> know --means that I/O (conversion) costs are more important than computation
> speed once converted).  GMP + MPFR don't really address the decimal part of
> that.  Then again, MAL hasn't quantified any of his desires either <wink>; I
> bet he'd be happier with a BCD-ish scheme.

The ideal solution for my needs would be an implementation which
allows:

* fast construction of decimals using string input
* fast decimal string output
* good interaction with the existing Python numeric types

BCD-style or simple decimal string style implementations serve
these requirements best, but GMP or MPFR 
 
> > ...
> > Hmmm, port MPFR everywhere...?-)  Pearu Peterson already did the
> > MPFR Python wrapper interoperating with GMPY, btw -- it lives at
> > http://cens.ioc.ee/~pearu/misc/gmpy-mpfr/ (haven't tested it as
> > I can't run MPFR myself, as above explained).
> 
> OK, that amounts to ~200 lines of C code to wrap some of the MPFR functions
> (exp, log, sqrt, sincos, agm, log2, pi, pow; many remain to be wrapped; and
> they don't allow specifying precision yet).  So Pearu still has significant
> work to do here, while MAL is wondering who in their right mind would want to
> do *anything* with numbers except add them <wink>.

Right: as long as there is a possibility to convert these decimals to 
Python floats or integers (or longs) I don't really care ;)

Seriously, I think that the GMP lib + MPFR lib provide a very
good basis to do work with numbers on Unix. Unfortunately, they
don't look very portable (given all that assembler code in there
and the very Unix-centric build system).

Perhaps we'd need a higher level interface to all of this which
can then take GMP or some home-grown "port" of the Python long
implementation to base-10 as backend to do the actual work.

It would have to provide these types:
 Integer - arbitrary precision integers
 Rational - dito for rational numbers
 Float - dito for floating point numbers

Integration with Python is easy given the new coercion mechanism
at C level. The problem I see is how to define coercion order, i.e.
Integer + Rational should produce a Rational, but what about
Rational + Float or Float + Python float or Integer + Python float ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/