At 01:15 PM 12/29/00 +0000, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >BigInt and BigFloat are both pure perl, and as such their speed leaves a
> >*lot* to be desired. Fixing that (at least yanking some of it to XS) has
> >been on my ToDo list for a while, but other stuff keeps getting in the
> >way... :)
>
>My own "evolutionary" view of things is that if we did XS versions
>of BigInt and BigFloat for perl5 we would learn some issues that might
>affect Perl6. i.e. the vtable entries for "ints" may be influenced
>by their use as building blocks for "floats".
I hadn't considered that as an idea, but most of the code would be useable,
wouldn't it? I may move it up my ToDo ladder some.
>For example the choice of radix in the BigInt case - should it be N*16-bits
>or should we try and squeeze 32-bits - or to avoid issues with sign
>should that be 15 or 31? (If we assume we use 2's complement then LS words
>are treated as unsigned only MS word has sign bit(s).)
I like the idea of n-1 bit integers building this up to make carry/borrow
detection easier. If we were at a lower level I'd check the math error
status bit directly, but we can't do that. :( (And I, for one, don't care
to hand-roll assembly at this point, certainly not for RISC processors...)
>BigFloat could well build on BigInt for its "mantissa" and have another
>int-of-some-kind as its exponent. We don't need to pack it tightly
>so we should probably avoid IEEE-like hidden MSB. The size of exponent
>is one area where "known range of int" is important.
That works too.
Anyone know of a good bigint/bigfloat library whose terms are such that we
can just snag the source and use it in perl? I don't really care to write
the code for division, let alone the transcendental math ops...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
