[perl #36330] [TODO] Create a BigNum PMC

[Patrick R. Michaud]

bignum.c seems to be entirely unused. Everything builds just fine
without it. There are many lint errors in it, such as int functions
returning with "return;" and no value.
Can we throw it away? Move it somewhere out of the way?

If (1) bignum.c is not being used, and (2) we don't expect it to
be used between now and Parrot 1.0, then I recommend we eliminate
it for the time being.

If someone in the future wants to recover this code as part of
(re)implementing BigInt/BigNum/BigWhatever, they can easily do
so from the svn repository. Until then, let's not carry around
the code baggage and/or lead coders down false trails.

Pm

[Jerry Gay]

On Thu, Feb 5, 2009 at 08:26, Andrew Whitworth via RT

1) Are we going to be relying on libraries to handle our BigInt/BigNum
implementations, or are we intending to roll our own?

we can't rely on external libraries, whether for bignum, unicode, gc,
or anything else. we can detect and use them, however, if they exist.

~jerry

[Jerry Gay]

On Thu, Feb 5, 2009 at 08:45, Andrew Whitworth via RT

Post by Jerry Gay
On Thu, Feb 5, 2009 at 08:26, Andrew Whitworth via RT

1) Are we going to be relying on libraries to handle our BigInt/BigNum
implementations, or are we intending to roll our own?

we can't rely on external libraries, whether for bignum, unicode, gc,
or anything else. we can detect and use them, however, if they exist.
~jerry

Okay, maybe "rely" was the wrong word to use. Current implementation of
BigInt.pmc uses GMP if it's available, else it throws exceptions that
there is no bug number library present to implement the behavior. Same
is true of the unicode charset and ICU. We don't require ICU or GMP to
build parrot, but we don't implement these behaviors without them.

but we do implement these behaviors, at least some of them. for
example, i don't have icu installed, but i can still use french quotes
in rakudo. i'll get an exception if i try to downcase a string of
japanese text (a silly example, but it won't throw if i have icu)
because not all unicode functionality has been implemented natively
*yet*.

Question is: Are we going to do this same thing for BigNum (use a
library if present, throw sane exceptions otherwise), or are we going to
roll our own BigNum implementation?

we will roll our own bignum, and give users the ability to use gmp or
another external library at configure time. until we do roll our own,
we should provide a default implementation that throws descriptive
exceptions.

~jerry

[Chromatic]

Post by Jerry Gay
we will roll our own bignum, and give users the ability to use gmp or
another external library at configure time.

That sounds like a fantastic recipe for hard-to-debug configuration problems
and all of the joys of fixing copious amounts of bugs we don't even know
about.

We're pretty decent at writing VMs and compiler tools and languages. If we
were also good at writing transcendental and arbirtrary precision math
libraries, we'd probably already have written one.

-- c

[Will Coleda]

Post by Chromatic

Post by Jerry Gay
we will roll our own bignum, and give users the ability to use gmp or
another external library at configure time.

That sounds like a fantastic recipe for hard-to-debug configuration problems
and all of the joys of fixing copious amounts of bugs we don't even know
about.
We're pretty decent at writing VMs and compiler tools and languages. If we
were also good at writing transcendental and arbirtrary precision math
libraries, we'd probably already have written one.
-- c

My 2 cents: it's ok to rely on external libraries. If they don't exist
on our core platforms, we could do something crazy like help port
them.

We do not need to reinvent every wheel. We're already reinventing
several as it stands.

[Jerry Gay]

Post by Will Coleda

Post by Chromatic

Post by Jerry Gay
we will roll our own bignum, and give users the ability to use gmp or
another external library at configure time.

That sounds like a fantastic recipe for hard-to-debug configuration problems
and all of the joys of fixing copious amounts of bugs we don't even know
about.
We're pretty decent at writing VMs and compiler tools and languages. If we
were also good at writing transcendental and arbirtrary precision math
libraries, we'd probably already have written one.
-- c

My 2 cents: it's ok to rely on external libraries. If they don't exist
on our core platforms, we could do something crazy like help port
them.
We do not need to reinvent every wheel. We're already reinventing
several as it stands.

silly me. i keep getting caught up in "old-think" lately. of course,
we've changed direction on this point, and the "new-think" is that we
do plan on relying on external libraries where it makes sense. we need
sane overflow semantics for our numeric pmcs if gmp isn't found, and
sane exceptions for unicode operations if icu isn't available.

a big warning in the configure output if icu or gmp isn't found would
certainly be a nice addition, so users know what they're in store for
if they don't have the (all but)? required external libraries
installed.

sorry for the confusion.
~jerry