develooper Front page | perl.perl5.porters | Postings from November 2000

Re: Math::BigInt*

Thread Next
From:
Steffen Beyer
Date:
November 26, 2000 01:55
Subject:
Re: Math::BigInt*
Message ID:
20001126105525.B21493@engelschall.com
Hello tels@bloodgate.com, in a previous mail you wrote:

> >> Steffen Beyer wrote Math::BigIntFast, thus pulling out the rug from
> Ugh, Math::BigIntFast is one I didnt know. Right now I got a deja vu
> feeling, because all the people that rewrote Math::BigInt and me only
> discovering that when I was done. :-/ (Happened with AIFilter, too).
> Anyway, seems there is demand ;)

Beware: Math::BigIntFast is just a wrapper around Bit::Vector (without any
added functionality)! This is because Bit::Vector already contains every-
thing needed for BigInt math, but nobody seems to read the module's
description in The Perl 5 Module List carefully enough to find it
when he/she needs BigInt math, so I decided another entry in the
list was needed. Therefore the wrapper.
But of course there could be some additional code in it in the future,
if necessary.

> I have Math::BigInt "done". There are some issues, but it is practically
> ready. Now I am looking at M::BF, which uses extinsivel M::BI, has lesser
> function etc. and so should be even easier.

Does the new M::BI still use arrays of strings for its internal
representation of numbers?

> Havent an idea about vec(), but if it could use B::V, B::V belongs to the
> core.
> 
> I think my rewrite of M::BI could use B::V, after all, it is like plugging
> in different calculation routines. I have, however, not tried nor
> benchmarked B::V. If B::V goes in the core, then I can use it. If not, I
> can't.

I think you can, just let your module check at startup time if it's there
or not, and then use it or not.

> My current idea is to represent the M::BI numbers as big floats like 2^150.
> I dont know exactly, but I think multiplication/division etc of these
> numbers could be faster, simple because the stored numbers are much smaller
> (BigInt and bit vectore have the problem that the calculation time is O(N)
> where N is the number of digits.)

Yes, but you forget the constant factor which should be much lower for B::V
than for M::BI, since B::V uses machine word arithmetic internally.

> But then, I have no idea about this all :-)
> 
> Using Bit::Vector could be done by a "has-a" relationship, so that M::BI
> simple uses B::V underneath. But then, it would be merely a new overload
> package vor Bit::Vector. Is that something we really need? Why not simple
> include Bit:Vector and be done? 

Yes, that's an idea of course.
What do perl5-porters think?

> I think it is about time to merge all the different fast big int packages...
> 
> My current work is at http://bloodgate.com/perl - comments welcome. The
> current version is about 2..4 times faster than the original and fixes
> several bugs.
> 
> I need to hunt Math::BigIntFast and have a look at it.

See remark at top - Math::BigIntFast is simply a wrapper around Bit::Vector
since Bit::Vector is already fully capable of BigInt math - including over-
loaded operators, if one wishes.

> One more comment: Mark Biggar (original author), liked the idea of a
> Perl only version, even if there is a C version.

Yes, there are circumstances where this is desirable.
Happened already with my other module, Date::Calc: There's also a Perl-only
version available.

Best regards,
-- 
    Steffen Beyer <sb@engelschall.com>
    http://www.engelschall.com/u/sb/whoami/ (Who am I)
    http://www.engelschall.com/u/sb/gallery/ (Fotos Brasil, USA, ...)
    http://www.engelschall.com/u/sb/download/ (Free Perl and C Software)

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About