Dmitriy40, у Вас, как понял, скачаны не 10 тысяч, а 10 миллионов нулей. Ну вот можете проверить, действительно ли рекордная сумма дзета-нулей равна примерно 17-ти и действительно ли точка экстремума гораздо ближе к тому самому простому числу

.
Во-первых, скачать с указанного Вами сайта можно сразу сто тысяч нулей за раз, с адреса вида
https://www.lmfdb.org/zeros/zeta/list?limit=100000&N=XXX00000, где XXX это с какого нуля скачивать. Выделяете весь текст, копируете в файл, получаете список нулей. Я сразу удаляю первую колонку (с номерами нулей) и получаю просто вектор самих нулей, читаемый в PARI командой readvec().
Чтобы не париться с ручным скачиванием, использую cURL и команду
curl -k "https://www.lmfdb.org/zeros/zeta/list?limit=100000&N=[1-99]00000" -o z#1e5 (первый файл, с первого нуля, скачать отдельно, там и номер с 1, и количество 99999). Правда они сволочи не отдают сразу много файлов (вместо списка нулей приходит html размера около 20КБ с чем-то типа капчи, это и есть признак что не отдали), потому запускать сразу на 100 смысла нет, я запускал по 5 с паузой в десяток секунд, так отдают без проблем. Каждый файл занимает 4.5МБ.
Во-вторых, мне проще выложить список первых 10млн нулей (всего-то 390МБ текста или 151МБ архива) чем заморачиваться с перевычислением кучи вашей статистики.
В-третьих, если Вы хотите просто проверить точность вычисления формулы Римана с 10млн нулей, то это сильно проще и для этого не надо набирать кучу статистики, вот:
n=155921
1: 14389.0370810906 17.0674522471 -0.6931471806 0.0000000000 = 14405.4113861571
2: -42.2802358371 0.0997350812 0.3465735903 -0.0000002488 = -41.8339274144
3: -6.4789166691 -0.1243403752 0.2310490602 -0.0000129638 = -6.3722209479
5: -1.3122730261 0.1072749823 0.1386294361 -0.0002978887 = -1.0666664964
6: 0.8213114166 0.0435656436 -0.1155245301 0.0006474669 = 0.7499999970
7: -0.5638964859 -0.0339993911 0.0990210258 -0.0011250378 = -0.4999998891
10: 0.2430228397 0.0232568337 -0.0693147181 0.0030351361 = 0.2000000914
11: -0.1938109652 0.0436362423 0.0630133801 -0.0037480044 = -0.0909093473
13: -0.1289850667 0.0039348721 0.0533190139 -0.0051919374 = -0.0769231181
14: 0.1069241061 0.0081097929 -0.0495105129 0.0059051828 = 0.0714285689
15: 0.0892958839 0.0169753052 -0.0462098120 0.0066051261 = 0.0666665032
17: -0.0632096301 -0.0284337889 0.0407733636 -0.0079529708 = -0.0588230262
14389.037081090565938281780070180898713\\li(n)
14356.500011078238148023773800925770675
14357\\pi(n)
Обращу внимание что значение 14356.5 - точное, именно на 0.5 меньше

- так задана

.
n=156007
1: 14396.2292918073 10.8744128520 -0.6931471806 0.0000000000 = 14406.4105574787
2: -42.2893416816 0.1088422784 0.3465735903 -0.0000002486 = -41.8339260615
3: -6.4797440870 -0.1235129118 0.2310490602 -0.0000129585 = -6.3722208971
5: -1.3123738289 0.1073768627 0.1386294361 -0.0002978108 = -1.0666653409
6: 0.8213678051 0.0435094375 -0.1155245301 0.0006473214 = 0.7500000339
7: -0.5639328440 -0.0339634517 0.0990210258 -0.0011248142 = -0.5000000840
10: 0.2430380851 0.0232421127 -0.0693147181 0.0030346717 = 0.2000001515
11: -0.1938233972 0.0436486028 0.0630133801 -0.0037474666 = -0.0909088809
13: -0.1289939660 0.0039430386 0.0533190139 -0.0051912673 = -0.0769231809
14: 0.1069318443 0.0081029247 -0.0495105129 0.0059044539 = 0.0714287099
15: 0.0893027065 0.0169693819 -0.0462098120 0.0066043428 = 0.0666666192
17: -0.0632151111 -0.0284296163 0.0407733636 -0.0079520908 = -0.0588234547
14396.229291807254365572118199681946613\\li(n)
14357.499185093295663523388798446899407
14358\\pi(n)
Каждая строка с 10млн нулями вычисляется по 2.7 минуты!
По идее можно суммирование по нулям сделать и параллельно, но это требует другой версии PARI (та что gpp) и плюс затраты памяти будут в разы больше - PARI не умеет обращаться с общими данными для всех потоков, он будет весь вектор нулей дублировать для каждого потока (что конечно маразм, вектор же read only в каждом потоке). Если сделать вектора по 100К элементов, то не страшно, а вот десяток векторов по миллионам элементов, по 40 байтов на элемент ...
Достаточно добавить команду
export(zm,y) (по моему коду) и заменить
sum на
parsum. Правда ускорение получилось даже не в разы, с 162с до 134с на строку, хотя задействованы все 4 потока и ожидалось 40с.
Видимо выгоднее параллельно обрабатывать сами файлы нулей, а не суммирование. Впрочем, так ускорение с 162с до 125с на строку, вместо ожидаемых 50с.
Фуфло эта встроенная параллельность в PARI.
В-четвёртых, раз уж точное значение

несложно вычислить через

для небольших

(до 1e17 уж точно), то соответственно можно узнать точное значение второго слагаемого (суммы).
В-пятых, все значения

будут одинаковы если выполняется условие
![$\lfloor \sqrt[k]{a} \rfloor = \lfloor \sqrt[k]{b} \rfloor, k=1\ldots\infty$ $\lfloor \sqrt[k]{a} \rfloor = \lfloor \sqrt[k]{b} \rfloor, k=1\ldots\infty$](https://dxdy-02.korotkov.co.uk/f/5/7/0/570ef6141e917278fbd85fb9abc4e5d982.png)
для двух чисел

, т.е. выше правая колонка (это и есть

) во всех строках кроме первой должна быть одинаковой. Все отклонения - результат погрешностей вычислений, в основном из-за недостатка количества нулей.
Ну либо я не понял чего именно Вы хотите.
PS. Для длинных таблиц удобно использовать тег syntax с вариантом text, как у меня выше, а не code и offtop - кому надо тот сам развернёт текст, зато без всяких действий по первым строкам видно что там. И выравнивание лучше.