question about large number math

[pop]

why does this work?:
gawk "BEGIN{print 2^54,2^54-2}"
18014398509481984 18014398509481982

but this does not work?:
gawk "BEGIN{print 2^54,2^54-1}"
18014398509481984 18014398509481984

all powers greater than 53 display this strange behavior. Is this a bug
or is this the way it is supposed to work with 64bit integers? I noticed
the similar behavior with windows API calls with powers greater than 53.

GNU Awk 4.1.3
Windows 10.0.10586 N/A Build 10586
4 GB memory
etc;

--
Best wishes;
(^\pop/^) -> Mark

[Luuk]

It's not specific for Windows...

luuk@opensuse:~> gawk "BEGIN{print 2^54,2^54-1}"
18014398509481984 18014398509481984
luuk@opensuse:~> gawk --version
GNU Awk 4.1.3, API: 1.1
Copyright (C) 1989, 1991-2015 Free Software Foundation.



It has to do with "how does a computer store numbers"
https://www.google.nl/?gfe_rd=cr&ei=q5ThV9GrO5DH8Afek764Dw#q=how+does+a+computer+store+numbers

[pop]

ahhh... that explains it: even tho I was thinking integer, the CPU
stores it as float (following from an article):

In general, a number is expressed as ±2e · x where 1 ≤ x < 2 so x = 1.
The machine allows 52 bits for x, the mantissa, one bit for the sign,
and 11 for the exponent e, making 64 bits in all. The mantissa by
definition always starts off with 1, so it uses up 52 bits but has 53
bits in its expression since the initial 1 is redundant. The
exponent is allowed to be negative, roughly in a range [−1024, 1023].

So numbers and integers only have 52/53 bit accuracy in 64bit
operations. I am now up to date.

thanks for your reply to get me on track.

[Janis Papanagnou]

On 20.09.2016 22:39, pop wrote:
> ahhh... that explains it: even tho I was thinking integer, the CPU stores it
> as float (following from an article):
>
> In general, a number is expressed as ±2e · x where 1 ≤ x < 2 so x = 1. The
> machine allows 52 bits for x, the mantissa, one bit for the sign, and 11 for
> the exponent e, making 64 bits in all. The mantissa by definition always
> starts off with 1, so it uses up 52 bits but has 53 bits in its expression
> since the initial 1 is redundant. The
> exponent is allowed to be negative, roughly in a range [−1024, 1023].
>
> So numbers and integers only have 52/53 bit accuracy in 64bit operations. I am
> now up to date.
>
> thanks for your reply to get me on track.
>

Since you're using a recent version of GNU awk, and if you want to do
multi-precision math, you can use option -M (this requires your gawk
version to have been compiled with the respective MP libraries).

$ gawk "BEGIN{print 2^54,2^54-1}"
18014398509481984 18014398509481984

$ gawk -M "BEGIN{print 2^54,2^54-1}"
18014398509481984 18014398509481983


Janis

[Kaz Kylheku]

On 2016-09-20, pop <p_...@hotmail.com> wrote:
> why does this work?:
> gawk "BEGIN{print 2^54,2^54-2}"
> 18014398509481984 18014398509481982
>
> but this does not work?:
> gawk "BEGIN{print 2^54,2^54-1}"
> 18014398509481984 18014398509481984
>
> all powers greater than 53 display this strange behavior. Is this a bug

Yes, because 53 is how many binary digits of precision there are in
an IEE 754 double floating point mantissa. (Actually 52 are stored;
there is an implied 1 which is not stored).

So that is the limit on the range of integers that can be represented
exactly.

> or is this the way it is supposed to work with 64bit integers? I noticed

It's not working with integers there, 64 bit or otherwise.

> the similar behavior with windows API calls with powers greater than 53.

You need to pass -M to gawk to get it to use multi-precision arithmetic:

Wrong output:

$ gawk "BEGIN{print 2^130,2^130-1}"
1361129467683753853853498429727072845824 1361129467683753853853498429727072845824

Right output:

0:rocktron:~/txr-64$ gawk -M "BEGIN{print 2^130,2^130-1}"
1361129467683753853853498429727072845824 1361129467683753853853498429727072845823

For that, we need Awk compiled with the right libs:: GNU MP and MPFR:

$ gawk --version
GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.1)
Copyright (C) 1989, 1991-2016 Free Software Foundation.

> GNU Awk 4.1.3
> Windows 10.0.10586 N/A Build 10586
> 4 GB memory

This might a Windows build made with MinGW; not sure if that is linked
with those libraries for -M support.

Try the experimental Cygnal-ized build I made (warning: 64 bit, not 32):

http://www.kylheku.com/cygnal/winawk.tar.gz

Test:

C:\Users\kaz\Desktop\winawk>dir
Volume in drive C is Local Disk
Volume Serial Number is 5E2B-F3C2

Directory of C:\Users\kaz\Desktop\winawk

09/20/2016 02:10 PM <DIR> .
09/20/2016 02:10 PM <DIR> ..
08/28/2016 05:05 PM 71,187 cyggcc_s-seh-1.dll
08/28/2016 05:05 PM 539,155 cyggmp-10.dll
08/28/2016 05:05 PM 1,033,235 cygiconv-2.dll
08/28/2016 05:05 PM 40,979 cygintl-8.dll
08/28/2016 05:05 PM 353,299 cygmpfr-4.dll
08/28/2016 05:05 PM 285,203 cygncursesw-10.dll
08/28/2016 05:05 PM 211,475 cygreadline7.dll
08/28/2016 05:08 PM 3,510,225 cygwin1.dll
08/28/2016 05:08 PM 571,923 gawk.exe
9 File(s) 6,616,681 bytes
2 Dir(s) 140,814,749,696 bytes free

C:\Users\kaz\Desktop\winawk>gawk --version
GNU Awk 4.1.4, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.1)
Copyright (C) 1989, 1991-2016 Free Software Foundation.
[ ... etc ... ]

C:\Users\kaz\Desktop\winawk>gawk -M "BEGIN{print 2^130,2^130-1}"
1361129467683753853853498429727072845824 136112946768375385385349842972707284582
3

[pop]

Thanks, Janis - Yes, I know about the -M option I was just temporarily
thrown by the results without the -M option until my memory was jogged
about how numbers were stored.
thanks again...

[pop]

Kaz Kylheku wrote on 9/20/2016 4:16 PM:
> On 2016-09-20, pop <p_...@hotmail.com> wrote:

<snipped>

Yes, I know about the -M option I was just temporarily thrown by the
results without the -M option until my memory was jogged about how
numbers were stored.

thanks for your reply...