[2/2]
Gawk 4.1.4 claims GNU MP support:
$ gawk --version
GNU Awk 4.1.4, API: 1.1 (GNU MPFR 4.0.1, GNU MP 6.1.2)
Copyright (C) 1989, 1991-2016 Free Software Foundation.but it mangles large numbers if they are printed as numbers rather than strings. A minimal test case:
$ echo "50000940106333921296" | gawk '{print $1}'
50000940106333921296
$ echo "50000940106333921296" | gawk '{printf "%d\n", $1}'
50000940106333921280What happens is that gawk 4.1.4 mangles the 16th byte from the msb and drops lower bytes:
>>> hex (500029664631299282)
'0x6f07654a9819cd2'
>>> hex (500029664631299264)
'0x6f07654a9819cc0'
>>> hex (50000940106333921296)
'0x2b5e7061c419da010'
>>> hex (50000940106333921280)
'0x2b5e7061c419da000'
>>> hex (500000029809255627825531266625)
'0x64f9654b819c0b0427aa32641'
>>> hex (500000029809255645132191956992)
'0x64f9654b819c0c00000000000'Somewhat surprisingly this already happens for R(10^9) even though it fits into an s64. Here is the corrected table with the R column matching the raw python output:
1 69 4 1.264911 1 0.562341
2 5764 12 1.200000 3 0.948683
3 526334 41 1.296534 7 1.244796
4 50874761 133 1.330000 13 1.300000
5 5028514748 431 1.362942 25 1.405853
6 500918449417 1384 1.384000 47 1.486271
7 50029364025646 4416 1.396462 87 1.547103
8 5000934571821489 14039 1.403900 157 1.570000
9 500029664631299282 44534 1.408289 285 1.602673
10 50000940106333921296 141082 1.410820 512 1.619086
11 5000029765607020319048 446604 1.412286 920 1.636017
12 500000941936492050650505 1413120 1.413120 1647 1.647000
13 50000029798618763894670256 4470180 1.413595 2944 1.655533
14 5000000942529842698007077786 14138641 1.413864 5255 1.661777
15 500000029809255627825531266625 44715123 1.414016 9372 1.666603Sorry about the wrong R column in >>23, I did not expect a bug in gawk.