develooper Front page | perl.perl5.porters | Postings from April 2001

Re: [PATCH] Re: Math::Big* v1.21

Thread Previous
From:
John Peacock
Date:
April 4, 2001 07:44
Subject:
Re: [PATCH] Re: Math::Big* v1.21
Message ID:
3ACB333E.DB735D68@rowman.com
Jarkko - 

How would you feel about my taking the existing Math::BigInt/BigFloat
and packaging them up for inclusion under CPAN?  I am thinking that this
is the only way to get the patched versions out to those poor souls who
cannot/will not upgrade to a more current Perl.  Except for a single
"no warnings" line, both of these modules will run under any 5.x
release.

At the same time, Tels could continue developing his replacements and
distribute them with his other modules.  If and when his replacements
get added to the core, we can replace the existing modules under CPAN
as well.

I propose this as a solution to get the patched files into the hands of
people who want to use them, and still allow for parallel development 
of an eventual replacement.

John Peacock

Jarkko Hietaniemi wrote:
> 
> > > 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
> 
> Well, not *that* compatible :-)
> 
> > 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?
> 
> Point taken.  But it's not so much about comparing new candidates
> against already existing parts in size than having to choose among
> several candidate modules for inclusion, and their usefulness/size
> ratio.  Also, what goes in cannot be taken out.  Ever.  Therefore
> I tend to favor stable (no jokes about my signature quote, please)
> modules (Inline was an exception since it looked, and still looks,
> so ingenious an idea -- but the author of Inline quite wisely chose
> not to accept my "invitation".)
> 
> > > Bignums, especially bigints, are nice to have,
> > > but essential, so one must weight the costs carefully.
> >      ^-- a not missing?
> 
> Yes.
> 
> > That is what was proposed here:
> >
> > http://archive.develooper.com/perl6-internals@perl.org/msg02640.html
> > [snip]
> > 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
> 
> I'm sorry to sound blunt that discussion about perl 6 internals is
> best to have in the perl6-internals mailing list.  There's a reason
> we decided to start the Perl 6 project, after all...  many of the
> solutions that will make sense for p6 won't make sense for p5,
> and vice versa.
> 
> --
> $jhi++; # http://www.iki.fi/jhi/
>         # There is this special biologist word we use for 'stable'.
>         # It is 'dead'. -- Jack Cohen

Thread Previous


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