From: Akshay S. <aks...@gm...> - 2013-04-20 16:11:39
|
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 <pv...@pv...> 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 > |