On Sat, Aug 14, 2010 at 8:56 AM, Patrick R. Michaud <pmich...@pobox.com>wrote:
> On Fri, Aug 13, 2010 at 11:08:30AM -0400, Aaron Sherman wrote: > > On Thu, Aug 12, 2010 at 3:48 PM, Darren Duncan <dar...@darrenduncan.net > >wrote: > > > > > > > > What is the difference between Parrot bignums and gmp? Could Parrot > not > > > just use gmp to implement its bignums? -- Darren Duncan > > > > > > > Parrot does use GMP. What we're discussing is how appropriate those are > for > > Perl 6. My feeling is that the closer Perl 6 can get to using GMP > directly, > > the better. If we need to wrap Parrot BigInt in a Perl 6 class, that > > wouldn't be terrible. > > It ultimately needs to be wrapped into a Perl 6 Int -- there's not a > separate "big integer" type. > That shouldn't be the case unless you're going to implement everything in Int that you can do with a GMP-based bigint or at least support auto-promotion if you try to do a GMP-only function on an Int. For example, GMP provides low-level implementations of primality testing, GCD, modular exponentiation, returning and modifying bit indexes in single operations (e.g. "set bit 121 to 0") without having to create a new bigint mask value. I would think that Int would encapsulate a BigInt which it would use as needed, but also expose to the user for advanced functionality, e.g.: my Int $a = 10**100; my $b = $a.bigint; $b.setbit(150); say $b.nextprime; > Or, put another way, we need Rakudo's Int class to be smart enough to > adapt to using a bigint representation (e.g., Parrot's BigInt PMC) > whenever the values are outside of a native int. > Handling large integers is only the start of what modern multi-precision integers are there for. Really, what they're becoming is high performance math libraries, sans the typical arbitrary limitations of native ints. Not providing that to Perl 6 users seems a wasted opportunity. -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
