Re: our own decimal math lib
At 8:46 AM +0200 7/1/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Nope. Nor, if the freeze/thaw system is representation-neutral, as a plugin option for parrot itself. There are just some license issues (or I'm reading it wrong, which is an issue itself :) that make shipping GMP with parrot problematic. Isn't it enough, whem we provide a link, where people can download GMP? Not by my reading of the license, no. And, what about making GMP a prerequisit (in the case that GMP is selected at configure time)? If they choose to use GMP at configure time, that's fine. I think what's in our best interests is to ship as part of parrot a basic bignum library that does what we need (which is nicely limited) with the option to replace it with GMP if the person building parrot wants to do so. Then it's just a matter of making sure we keep frozen bignums cross-compatible and having a simple thunking layer to translate our API to GMP's so parrot's source doesn't need to care which is chosen. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: our own decimal math lib
Dan Sugalski [EMAIL PROTECTED] wrote: Nope. Nor, if the freeze/thaw system is representation-neutral, as a plugin option for parrot itself. There are just some license issues (or I'm reading it wrong, which is an issue itself :) that make shipping GMP with parrot problematic. Isn't it enough, whem we provide a link, where people can download GMP? And, what about making GMP a prerequisit (in the case that GMP is selected at configure time)? Dan leo
Re: our own decimal math lib
On Fri, 25 Jun 2004, [ISO-8859-1] André Pang wrote: On 24/06/2004, at 6:31 PM, Leopold Toetsch wrote: i still have my stillborn bignum (using bcd registers and efficient algorithms) implementation if anyone wants to pick it up. i have some working base code and the overall design. The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK. Is there a big problem with using GMP for the purposes of the demo? Nope. Nor, if the freeze/thaw system is representation-neutral, as a plugin option for parrot itself. There are just some license issues (or I'm reading it wrong, which is an issue itself :) that make shipping GMP with parrot problematic. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: our own decimal math lib
André pang [EMAIL PROTECTED] wrote: On 24/06/2004, at 6:31 PM, Leopold Toetsch wrote: The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK. Is there a big problem with using GMP for the purposes of the demo? I don't think that this should be a problem. And, what does Python use for arbitrary-precision integers? They have their own lib (base 2^15 binary digits). ... It only seems fair to be using the same library as Python, if you want a decent bignum speed comparison. Python::Flongobject.c is not pluggable, it's full of Python internals. leo
Re: our own decimal math lib
On Friday 25 June 2004 03:47, André Pang wrote: It only seems fair to be using the same library as Python, if you want a decent bignum speed comparison. We don't mind being unfair, as long as parrot's winning :-) Jerome -- [EMAIL PROTECTED]
Re: our own decimal math lib
Uri Guttman wrote: SB == Scott Bronson [EMAIL PROTECTED] writes: SB Has anybody inquired to the GMP project as to the possibility of SB relaxing that restriction? If GMP truly is the best bignum SB implementation, I definitely think it's worth asking. Not AFAIK. Please try. i still have my stillborn bignum (using bcd registers and efficient algorithms) implementation if anyone wants to pick it up. i have some working base code and the overall design. The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK. We can always switch the internals, as long as we keep it consistent at the surface. uri leo
Re: our own decimal math lib
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT Uri Guttman wrote: SB == Scott Bronson [EMAIL PROTECTED] writes: SB Has anybody inquired to the GMP project as to the possibility of SB relaxing that restriction? If GMP truly is the best bignum SB implementation, I definitely think it's worth asking. LT Not AFAIK. Please try. i still have my stillborn bignum (using bcd registers and efficient algorithms) implementation if anyone wants to pick it up. i have some working base code and the overall design. LT The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon LT benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK. LT We can always switch the internals, as long as we keep it consistent LT at the surface. sorry about the timing. and dan and i discussed the ability to swap the lib later so that is how we should go with my lib. but it still needs work so if anyone wants to get into parrot this way, let me know. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: our own decimal math lib
On 24/06/2004, at 6:31 PM, Leopold Toetsch wrote: i still have my stillborn bignum (using bcd registers and efficient algorithms) implementation if anyone wants to pick it up. i have some working base code and the overall design. The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK. Is there a big problem with using GMP for the purposes of the demo? And, what does Python use for arbitrary-precision integers? It only seems fair to be using the same library as Python, if you want a decent bignum speed comparison. -- % Andre Pang : trust.in.love.to.save
