Front page | perl.perl6.internals |
Postings from February 2002
Re: Initial bignum pdd
From: Tim Bunce
February 28, 2002 03:34
Re: Initial bignum pdd
Message ID: 20020228113422.R17360@dansat.data-plan.com
On Thu, Feb 28, 2002 at 10:44:21AM +0000, Ben Evans wrote:
> On Thu, Feb 28, 2002 at 10:18:45AM +0000, David Chan wrote:
> > On Wed, Feb 27, 2002 at 09:35:13PM +0000, Nicholas Clark wrote:
> > > On Tue, Feb 26, 2002 at 11:17:55AM +0000, Alex Gough wrote:
> > > > Yes, at some point allowing 10**222222222222222222222, is just silly,
> > > > and I doubt the potentional applications are numerous enough to
> > > > warrant trying it. So long as we're clear about what the limits are,
> > >
> > > about 10**98 particles in the universe, isn't it?
> > > How many real world calculations seriously need numbers considerably
> > > larger than that?
> > Remember that many important calculations are not "real world". For
> > instance, numbers bigger than 10**98 are used routinely in cryptography
> > (though not bigger than 10**2147483648, which is your point, I think).
> > I'm sure you could, in theory, get numbers that high when dealing with
> > statistical stuff. But if people say it hardly ever happens in
> > practice, then I'm sure they're right.
> Eg: The size of the space of configurations of a simple model of magnetism
> (the Ising model) would be 2**V where V is the number of sites of some
> lattice. "Very nearly all" of them are pathological special cases, though.
> Such models are quite common in simulation, but only a newbie would
> approach them in a manner where that number actually appeared. I'd
> agree with all of the above - come up with some vaguely sensible limit
> and make it clear in the documentation what the limit is.
And remember that the bignum implementation should be pluggable so the
default limit should be pragmatic and favour performance. Everyone wants
performance, but few need very high values. Those that do can plug in a
bignum implementation that supports what they need.
And now for a probably dumb question (since I've not really been
paying attention): are people really planning to spend time working
on yet another bignum implementation? Isn't one of the freely
available bignum libraries 'out there' acceptable?