On Wed, Aug 11, 2010 at 12:50 PM, Patrick R. Michaud <pmich...@pobox.com>wrote:
> On Tue, Aug 10, 2010 at 08:44:06PM -0400, Aaron Sherman wrote:
>
> > Is this an interim limitation, or something that's intended as a
> long-term
> > implementation for Rakudo?
>
> It's an interim limitation, but I don't know how long it will be
> before Rakudo fixes it. Certainly Perl 5 has survived for a very long
> time without needing its integers to be arbitrary precision by default.
>
Perl 5 and 6 are radically different systems in this respect. Perl 5 deals
with large numbers by storing everything in a double (well... most
everything, there are IVs to be sure, but the user almost always interacts
in NVs when they're doing math). In Perl 6 this doesn't work nearly so well
because it has a typing system which makes automatic conversions painful.
For example, here's an implementation of modpow, much like Perl 5's
Math::BigInt::bmodpow:
sub modpow(Int $n is copy, Int $exponent, Int $mod) {
my Int $total = 1;
for $exponent, * +> 1 ... 1 -> $e {
$total = ($total * $n) % $mod if $e +& 1;
$n = ($n*$n) % $mod;
}
return $total;
}
Now, if you pass 10, 10 and 7 to that function, it works fine and you get 4.
But if you pass larger values:
modpow(100000, 100000, 7)
Type check failed for assignment
in '&infix:<=>' at line 1
in 'modpow' at line 9:./modp.p6
in main program body at line 19:./modp.p6
You just can't silently upgrade a type to an incompatible type on the fly
like that without expecting any code with type constraints to break. It
would almost be better to raise an overflow exception. At least then, the
programmer could catch it and deal with it appropriately.
> > [...]
> > But assuming that Parrot's BigInt will be expanded to suit general
> purpose
> > needs, is it Rakudo's plan to use it for Int implementation?
>
> My guess is that Rakudo will ultimately develop its own
> arbitrary-precision integer representation, rather than trying to use
> the BigInt that comes with Parrot. Also, IIRC, Parrot's BigInt
> implementation only works on systems that have certain libraries
> installed.
>
Well... that's true, but unlike some libraries out there, gmp isn't exactly
a difficult dependency to meet. To quote their site:
GMP's main target platforms are Unix-type systems, such as GNU/Linux,
Solaris, HP-UX, Mac OS X/Darwin, BSD, AIX, etc. It also is known to work on
Windows in both 32-bit and 64-bit mode.
And this from the GCC 4.3 release notes:
GCC requires the GMP and MPFR libraries for building all the various
front-end languages it supports.
I think Perl 6 would be doing amazingly well if it *only* ran everywhere
that all of gcc 4.3's front-end languages ran... Not to mention the fact
that GMP is amazingly fast. What would you write Perl 6's implementation in
that could come near the hardware-optimized performance of GMP? The thing
ships with hand-optimized assembly (including things like MMX/SSE support)
across dozens of processor platforms. I know we put a lot of faith into the
magical day when Perl 6 is jitted down into its optimal machine code, but I
don't think it's rational to expect to be able to touch GMP's performance,
and most applications that care about arbitrarily large integers actually do
care about performance.
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
