Re: [perl #36330] [TODO] Create a BigNum PMC
On Thu, Feb 5, 2009 at 08:26, Andrew Whitworth via RT parrotbug-follo...@parrotcode.org wrote: 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
Re: [perl #36330] [TODO] Create a BigNum PMC
On Thu, Feb 5, 2009 at 08:45, Andrew Whitworth via RT parrotbug-follo...@parrotcode.org wrote: On Thu Feb 05 08:40:47 2009, particle wrote: On Thu, Feb 5, 2009 at 08:26, Andrew Whitworth via RT parrotbug-follo...@parrotcode.org wrote: 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
Re: [perl #36330] [TODO] Create a BigNum PMC
On Thursday 05 February 2009 08:57:18 jerry gay wrote: 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
Re: [perl #36330] [TODO] Create a BigNum PMC
On Thu, Feb 5, 2009 at 1:12 PM, chromatic chroma...@wgz.org wrote: On Thursday 05 February 2009 08:57:18 jerry gay wrote: 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. -- Will Coke Coleda
Re: [perl #36330] [TODO] Create a BigNum PMC
On Thu, Feb 5, 2009 at 10:23, Will Coleda w...@coleda.com wrote: On Thu, Feb 5, 2009 at 1:12 PM, chromatic chroma...@wgz.org wrote: On Thursday 05 February 2009 08:57:18 jerry gay wrote: 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
Re: [perl #36330] [TODO] Create a BigNum PMC
On Mon, Dec 01, 2008 at 06:23:31AM -0800, Klaas-Jan Stol via RT wrote: On Sat Sep 08 10:39:31 2007, bernhard wrote: Just for the records, Andy Lester wrote on p2: 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
[perl #36330] [TODO] Create a BigNum PMC
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #36330] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36330 The current state of big numbers and extended decimal arithmetic in Parrot is mildly confusing. In 'pdd17_basic_types.pod' there is a BigNum PMC mentioned, being a wrapper around a low-level BigNum type. This low level BigNum type is kind of documented in 'docs/pdds/pdd14_bignum.pod'. An implementation is started in the directory 'types'. However this implementation is nowhere used in Parrot. There is an implementation, based on GMP, of a BigInt PMC in 'classes'. The implementation is tested in 't/pmc/bigint.t'. But the BigInt PMC is not mentioned in 'pdd17_basic_types.pod'. 'vtable.tbl' mentions the vtable methods: PMC* get_bignum() void set_bignum_int(INTVAL value) void set_bignum_num(FLOATVAL value) void set_bignum_str(STRING* value) However only 'get_bignum' and 'set_bignum_int' are mentioned in 'pdd02_vtables.pod'. These vtable are propably meant for dealing with overflows on assignment. But it looks they are not consistently used. I propose following actions: - update pdd17_basic_types.pod: BigInt and BigNum are PMCs, behavior on overflowing assignment - Provide a GMP based implementation of BigNum PMC - Add a complete test suite, see types/bignum_test.pl, http://www2.hursley.ibm.com/decimal/dectest.html - clean up the 'types' directory - Specify an API for plugging in other BigNum libraries, the implementation in 'types' could conform to that API
