I wonder if I can pitch the MPFR integration itself as a project for GSoC; I'm afraid this is what I'd want SBCL to have more (well the
bignums are already there :), but also that it is of a much lower priority than adding GMP support.

Akshay


On 20 April 2013 03:00, Paul Khuong <pvk@pvk.ca> wrote:
Stephan Frank wrote:
but wouldn't a library with bindings to MPFR (using CFFI) not make more
sense? Maxima (and I suppose matlisp as well) have to implement their
own bigfloats data type anyway whereas the GMP integration has the
chance of being tightly and transparently integrated with the underlying
bignum implementation of SBCL. I could only see an advantage when
tightly coupling it with CMUCL's quad-floats.

We may still do something useful with long-floats. That type is currently equivalent to double-float, but there's nothing that makes the situation necessary. IIRC, CLISP's long floats are arbitrary precision. I'm not completely sure what that means for standard compliance, but I'm also somewhat open to interpreting the standard loosely if the looseness only affects long float values.

However, integrating MPFR for long floats is likely to be more work than plugging GMP in SBCL's bignums. We'd have to re-create a long-float type, likely fiddle with numeric bounds propagation, and (this final part is much more easy) define a concrete representation for long floats and tell the GC about.

Paul Khuong