[Top][All Lists]
[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