bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GAWK adding big numbers wrong


From: Aharon Robbins
Subject: Re: GAWK adding big numbers wrong
Date: Wed, 15 May 2002 16:49:00 +0300

> Date: Mon, 13 May 2002 13:08:50 +0300 (IDT)
> From: Eli Zaretskii <address@hidden>
> To: Aharon Robbins <address@hidden>
> cc: address@hidden, address@hidden, address@hidden
> Subject: Re: GAWK adding big numbers wrong
>
> On Mon, 13 May 2002, Aharon Robbins wrote:
>
> > If these issues can be solved, when the MP work is ready, I'll integrate
> > it.  If not, it may just be distributed as an officially blessed set of
> > patches that are kept in sync with the main gawk release.
>
> Or maybe make two different binaries when building: one with, the other 
> without arbitrary precision support.

If I understand correctly what's being done, MP will be a dynamically
enabled feature.

IF the new code is something I can maintain, it'll be part of regular gawk.
Otherwise, it will probably have to be managed as a separate set of patches
that the author will maintain.

> To: Aharon Robbins <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Subject: Re: GAWK adding big numbers wrong
> From: Miles Bader <address@hidden>
> Date: 13 May 2002 21:21:09 +0900
>
> Aharon Robbins <address@hidden> writes:
> > The surgery required is significant.  In particular memory management
> > is a major issue, and I am concerned that a switch to infinite precision
> > for the _default_ behavior would be a big performance loss.
>
> Sorry to poke my uninformed nose in, but ...
>
> It already has to pay the price for type-dispatching on arith args
> because they can possibly be strings, so why are bignums any harder?
> The only wrinkle would be testing for overflow and making the result a
> bignum in that case (I'm assuming you're gonna keep the existing number
> representation, and only use bignums for overflow).
>
> In fact, since gawk already has all the infrastructure to deal with
> strings, why not represent bignums as strings-with-a-bit-set-in-the-header?
> [I don't mean represent them as ASCII, just as strings containing the
> binary representation.]
>
> I'll go away now...
>
> -Miles
> -- 
> I have seen the enemy, and he is us.  -- Pogo

As I said, I haven't seen any of the code.  The gawk code doesn't do
"type-dispatching on arith args". Rather it dispatches on the operation
and forces (converts) arguments to be numeric or string as needed.  (This
is based on awk semantics.)

I agree that MP in awk would be a lovely thing to have.  But all features
come at a price, and code maintenance issues are a big factor for me.
Gawk is still maintainable by one person, but the design is starting to
show stress.

Arnold



reply via email to

[Prev in Thread] Current Thread [Next in Thread]