GSoC Idea: GMP Bindings
10 Mar 2010This conversation happened yesterday on IRC, with some off-topic things edited out:
darbelo: That reminds me. I hate our bignums and want them to die...
whiteknight: darbelo: I agree with the bignums thing 100%. I want bignums out of the repo and moved to their own project
whiteknight: There's no sense keeping them when I suspect a majority of users can't use them because they don't have GMP installed
darbelo: Actually, I wouldn't mind them being in the core if they weren't dependant on a lib I don't have.
darbelo: I actually had started to write a stand-alone BigInteger PMC after last year's SoC.
whiteknight: that would make an awesome project too.
whiteknight: I think we should have lots of projects like that, and for developers to be able to pick which solution they want
whiteknight: as we are now, it's easier to force BigInt to pretend to do what we need instead of just using the best solution, which might be DecNumber or something else
darbelo: Maybe, but GMP is much, much more than just bignums. It's a pretty big library.
darbelo: Our PMCs don't even start to scratch the surface of what GMP can do.
whiteknight: darbelo: so moving those PMCs out to a separate library and adding wrappers for other functionality might be nice
darbelo: I would consider a GMP binding much more valuble to parrot than our current use of the lib, yes.
bubaflub: last year i worked a bit with GMP library and suggested to dukeleto we work on a GMP binding for parrot
bubaflub: last year with GSOC and perl 5
darbelo: bubaflub: That would be nice to have.
bubaflub: though we used an existing perl 5 binding (Math::GMPz)
whiteknight: yes, that would be a wonderful project
bubaflub: but we could nab the test suite and what not
whiteknight: exactly. We have the two PMC types, and we could write wrappers for the rest of the library and get all sorts of additional power
bubaflub: i think access to the GMP library in general would be nice; the stuff i worked on last year was setting some foundational stuff for cryptography libraries
Parrot has two PMC types that wrap GMP: BigInt nd BigNum. I think, and apparently a few people agree, that these two types have no business being in the core Parrot repository and should be moved to another project. The immediate benefit to this would be that the bindings for GMP could be improved and expanded independently, instead of only providing what little functionality Parrot actually makes direct use of.
A good GSoC project for this year would be to move (or fork) the current BigInt and BigNum PMC types to a new project and use them as the cornerstone for writing a more comprehensive interface for the GMP library.This could include other PMC types, NCI function wrappers, PMC methods, ops, and other things to allow access to the power of the GMP library. Adding custom Integer-like and Float-like PMCs that autopromote to their Big- counterparts would be nice too.
For more info about this project, you could probably get in touch with myself, darbelo, or bubaflub.
This entry was originally posted on Blogger and was automatically converted. There may be some broken links and other errors due to the conversion. Please let me know about any serious problems.
Comments
Anonymous
3/10/2010 12:21:40 PM
Whiteknight
3/10/2010 1:31:40 PM
redbrain
3/10/2010 1:46:47 PM
Perl 6 requires arbitrary precision integers for the "Int" type, which is a type that is presumably used in every single Perl 6 program.
I guess that it would require a Parrot type that uses native integer arithmetic (so that calculations won't be slow for small numbers) and automatically upgrades to some kind of BigInt whenever an integer overflow happens.
Parrot's "Integer" PMC seems to do this. Will it still be available after you remove the GMP dependency?
Rakudo already doesn't use Parrot's built-in Integer PMC type, so the behavior of what Parrot's type does or does not do is sort of irrelevant.
But you're right, if BigInt and BigNum move out of the repo (and this is just an idea I had, the rest of the community hasn't signalled any support for it yet), Integer will lose the autopromotion behavior.
Of course, I think that's a good thing. Parrot shouldn't be making decisions with respect to the autopromotion of datatypes. At least, I don't think it should be.
I think i might be interested in doing this, been looking into GMP for my own project for builtin Bignums for the language, but i have it as a ./configure option so you can --with-bugnums. MPFR is interesting too because you can manualy set the precision. I am just back at my university to finish my degree after work for a year and a half at SAP so i need something to do this summer :).