Re: [bug-gawk] GAWK 4.1 arbitrary precision integers and E notation

[Aharon Robbins]

Hi.

I finally took another (short, sort of) look at this.

> Date: Tue, 06 Aug 2013 07:41:35 +0200
> From: Hermann Peifer <address@hidden>
> To: address@hidden
> Subject: [bug-gawk] GAWK 4.1 arbitrary precision integers and E notation
>
> As Arnold requested, I am forwarding the below snippet from a c.l.a. 
> posting to the bug-gawk mailing list.
>
> Hermann
>
> -------- Original Message --------
> Subject: Re: GAWK 4.1 Integer Division
> Date: Mon, 5 Aug 2013 19:26:36 +0000 (UTC)
> From: address@hidden (Aharon Robbins)
> Organization: A noiseless patient Spider
> Newsgroups: comp.lang.awk
> References: <address@hidden> 
> <address@hidden> 
> <address@hidden> 
> <address@hidden>
>
> Hermann Peifer  <address@hidden> wrote:
> ># 10^30 obviously "looks like an integer" and is handled accordingly
> >$ gawk -M 'BEGIN{print 10^30}'
> >1000000000000000000000000000000
>
> The MPFR code deals with this and figures it out.
>
> ># But 1e+30 doesn't seem to look like an integer..
> >$ gawk -M 'BEGIN{print 1e+30}'
> >1000000000000000019884624838656
>
> The exponential form is by definition floating point.  This conversion
> might be a bug. Can you file a bug report so that I'll look into it?

I think this is just something we have to live with.  10^30 is correctly
handled by the MPFR code and treated as integer since it's done at runtime,
with big integers.

The 1e30 is evaluated at parse time.  Even with -M, the *default* precision
is 53, which is the same as double precision floating point. First,
in floating point:

        # 10^30 is 1e31, no?
        $ ./gawk 'BEGIN { print 10^30 }'
        1000000000000000019884624838656
        $ ./gawk 'BEGIN { print 1e31 }'
        9999999999999999635896294965248

Now with MPFR:

        $ ./gawk -M 'BEGIN { print 1e31 }'
        9999999999999999635896294965248

But if we increase the precision:

        $ ./gawk -M  -vPREC=80 'BEGIN { print 1e31 }'
        10000000000000000000000000000000

I don't think there's a lot more to do here.  If (one day) gawk
ever supports real decimal arithmetic, then maybe this will
be straightened out.  Until then, anyone using MPFR will need
to remember that they should increase the precision if they
want more exact results.

Thanks,

Arnold