From: Akshay S. <aks...@gm...> - 2013-04-21 19:23:37
|
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 :) Akshay On 20 April 2013 09:56, Stephan Frank <cri...@cs...> 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. > > Regs, > Stephan > > 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 <pv...@pv... <mailto: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 > > > > > > > > > > > ------------------------------------------------------------------------------ > > 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 > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > > > |