I can then probably start off by integrating your code for GMP with SBCL, and then
start work on MPFR. That'd be very nice indeed :)


On 20 April 2013 09:56, Stephan Frank <crimsonf@cs.tu-berlin.de> wrote:
Well, if it helps with your decision process: I have a mostly complete
GMP connection for SBCL (currently only for integers, though rationals
should be easy to extent; that's my next step). It was a project I had
considered for a longer time already and Paul's GSoC description sparked
my interest anew. I have kept it under wraps so far (apart from some
communication with Paul) because I didn't want to discourage a potential
student from participating in GSoC.

However, looking at my project schedule at work there are several things
from Pauls project suggestion that will definitely not happen by me in
the foreseeable future: extensive unit tests; GMP algorithms in Lisp for
SBCL. So you might want to expand on that or take on your MPFR proposal.


On 04/20/2013 06:11 PM, Akshay Srinivasan wrote:
> 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 <mailto: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
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel