[1/2]
There is a bug in gawk 4.1.4, which was used to generate the table from >>23, which causes the second column, that of R values, to be wrong starting with k=9. You can see that the value of R(10^10) stated in >>18, which is the correct value from raw python output, differs from the value from >>23 for k=10. The values stated from raw python output are correct, only the R column of >>23 is wrong starting with k=9. Here is the raw python output with the correct values:
$ cat data.txt
groups: 4 index: 1
10: 69 0x0000000000000045
groups: 12 index: 3
100: 5764 0x0000000000001684
groups: 41 index: 7
1000: 526334 0x00000000000807FE
groups: 133 index: 13
10000: 50874761 0x0000000003084989
groups: 431 index: 25
100000: 5028514748 0x000000012BB90BBC
groups: 1384 index: 47
1000000: 500918449417 0x00000074A110F509
groups: 4416 index: 87
10000000: 50029364025646 0x00002D805E78992E
groups: 14039 index: 157
100000000: 5000934571821489 0x0011C452D0B2C9B1
groups: 44534 index: 285
1000000000: 500029664631299282 0x06F07654A9819CD2
groups: 141082 index: 512
10000000000: 50000940106333921296 0x2B5E7061C419DA010
groups: 446604 index: 920
100000000000: 5000029765607020319048 0x10F0D5A2486CA185148
groups: 1413120 index: 1647
1000000000000: 500000941936492050650505 0x69E11AF9D4B68A281589
groups: 4470180 index: 2944
10000000000000: 50000029798618763894670256 0x295BEB0BEDFC4C3D3B43B0
groups: 14138641 index: 5255
100000000000000: 5000000942529842698007077786 0x1027E762374D2B62E383E39A
groups: 44715123 index: 9372
1000000000000000: 500000029809255627825531266625 0x64F9654B819C0B0427AA32641Here is a diff between the values from the raw python output and the R column of >>23:
$ diff <(grep -e ' 0x' data.txt | cut -d ' ' -f 2) <(sed -r -e 's/^ *[0-9]+ +([0-9]+) +.+$/\1/' epsilon.txt)
9,15c9,15
< 500029664631299282
< 50000940106333921296
< 5000029765607020319048
< 500000941936492050650505
< 50000029798618763894670256
< 5000000942529842698007077786
< 500000029809255627825531266625
---
> 500029664631299264
> 50000940106333921280
> 5000029765607020822528
> 500000941936492081577984
> 50000029798618762867376128
> 5000000942529842273283211264
> 500000029809255645132191956992[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.