Front page | perl.perl5.porters |
Postings from March 2001
Re: [PATCH] Re: Math::Big* v1.21
March 31, 2001 08:00
Re: [PATCH] Re: Math::Big* v1.21
Message ID: 200103311600.LAA411252@www08.hway.net
-----BEGIN PGP SIGNED MESSAGE-----
[Steffen: please see below]
On 31-Mar-01 Jarkko Hietaniemi tried to scribble about:
>> Yes, that is what was my plan/wishfull dreaming ;o) I am working hard to
>> make it a true (aka working the same as closely as possible)
>> Unfortunately, Math::BigFloat is not ready yet, so you probably don't
>> want to include it. The old Math::BigFloat is not working with the new
>> Math::BigInt since it relies on to many internals.
>> I am working hard to get M::BF complete. Sorry that it is not ready yet.
>> > Yes, licensing has been an issue in the past. Basically, if the
>> > licensing is anything else than the Perl dual Artistic/GPL, there's
>> > a problem.
>> I think in the future we get Bit::Vector as the underlying library, and
>> this means more speed (C!) and no licencing issues, since thats a perl
>> module (thanx to Steffen Beyer for his work!). But this means more work
>> me and Bit::Vector must be included too. Hm. Wel, we leave that for
>> > How big is the new Math::Big*?
>> 70 kb compressed, but thats including all the Math::String etc. about 40
>> KByte for M::BI.pm. (its pure Perl)
>> As soon as it is ready for inclusion (determined by you or me) I will
>> the other Math::String stuff and make them an extra CPAN module.
>> Maybe it is time to collect all the pure-Perl math stuff and check if it
>> still working. I will look at Math::Fraction, since my Math::BigFraction
>> reinventing the wheel there. I haven't heard back from the original
> When both the M::BI and M::BF really are available are true drop-in
> replacements, that is, backward compatibility with the pure-Perl
> add-ons has been checked,
This will not be 100% backward compatible, since it fixes bugs and corrects
(serious) mistakes the old code had. But I have essential taken over the
old testsuite and enhanced and enlarged it. Anything important using
BigNums is looked/tested by me or I am working with the author together
(John P. => ;o)
> I might consider including it. The
> extension is more than a bit on the large side, though, that might
> be a serious problem.
Why? Seeing that the CHANGES files alone are 2.4 MB, why are 46 KByte
code/documentation (over 13 old) a problem? ;)
I mean, the old version is broken. Fixing it is more important than size or
did I misunderstand you here?
> Bignums, especially bigints, are nice to have,
> but essential, so one must weight the costs carefully.
^-- a not missing?
The are essential whenever the normal numbers are too small, which is quite
often the case. Many people rely on them already. But its a point of
> One area of completely unexplored area of work that might be useful
> would be for someone to research the various available bignum
> libraries and figure out how integrate the support of those into the
> core language. I'm not talking about having separate extensions for
> each bignum library out there because there are too many, what I'm
> after is some kind of more transparent support for 2**1000.
That is what was proposed here:
I am already having a look at the available material. Most of it is out of
There is only one problem: It seems Dan likes to completely rewrite the
transparent bignum support in C (unlikely that someone will have the time
to re-invent the wheel, though), and libraries are probably not possible due
to licencing. One solution would to have the pure-perl version in (so that
it works, not that it is fast) and then later replace it with C code. I do
not now if this is technically feasible.
If it must be C from the beginning, I vote for the C parts of Bit::Vector.
I am cc'ing Steffen to hear what he thinks.
Transparent support would solve many speed/overload/overcomplicated code
Best example is Math::Fraction, which is very complicated (and currently
broken, but thats another side of the story) just to provide fractions that
work with normal numbers and bignums. If there were transparent support,
it's code might be reduced by 50-70%. Would also be easier from the
end-users point of view.
Te"Only a dead bug is a good bug"ls
perl -MMath::String -e 'print \
http://bloodgate.com/thief/ Thief - The Dark Project
http://bloodgate.com/perl My current Perl projects
http://freedomforlinks.de Fight for your right to link.
PGP key available on http://bloodgate.com/tels.asc or via email
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----