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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4