Точное количество кортежей из простых чисел в интервале

[vicvolf]

Dmitriy40 Вы торопитесь. Я еще редактировал сообщение. Посмотрите последний вариант. Я не собирался делать никаких открытий. Если это банально для Вас, то я за Вас очень рад. Меня наоборот удивило Ваше сообщение, что 10 млн. нулей не хватило для определения количества простых чисел для $\pi(155921)$, если для определения $\pi(10^{24})$ Платту потребовалось только 70 млрд.

[Dmitriy40]

vicvolf в сообщении #1688515 писал(а):

Например, для определения $\pi(10^{24})$ Платт использовал 69.7 млрд нулей.

vicvolf в сообщении #1688519 писал(а):

Меня наоборот удивило Ваше сообщение, что 10 млн. нулей не хватило для определения количества простых чисел для x=155921, если для определения $\pi(10^{24})$ Платту потребовалось только 70 млрд.

Беда в том что каждый ноль даёт смещение вовсе не меньше $\varepsilon$, а намного больше, вот например значения $\operatorname{li}((10^{24})^\rho)$ по последним 10-ти известным нулям около 103.8млрд:

? foreach(zm,z,print(real(-eint1(-log(1e24)*(0.5+I*z)))))
0.31951698367409512367799580572380077893
0.59090447178189821240918737841797028099
0.15308415359474422950945561681622188033
-0.015982484139642834950190382357771271888
-0.35052955002734209512920822260918799621
-0.51412503403657131406181063056726844007
-0.30457303049259294013850242022354281067
0.56717703722949931182460043061098336051
-0.43490655320108955705516788168157554695
0.18949170027403777197550220694276195895

Даже из этого понятно что надо как-то хитро выбирать сколько именно нулей использовать, не просто когда изменения станут меньше погрешности, а гораздо хитрее, учитывать что при суммировании нули друг друга компенсируют.

-- 02.06.2025, 20:38 --

vicvolf в сообщении #1688519 писал(а):

Меня наоборот удивило Ваше сообщение, что 10 млн. нулей не хватило для определения количества простых чисел для $\pi(155921)$,

Я такого не говорил, Вы выдумываете. Я говорил что 10млн нулей не хватило для точного равенства (с указанным количеством цифр после запятой) $J(x)$ своему идеальному значению. Но погрешности в $1.1\cdot10^{-5}$ за глаза хватает чтобы определить точное значение $\pi(x)$. Хватило бы даже и погрешности в 0.2, для чего вроде бы хватает и 20000 нулей (если считать всё честно, без оптимизаций).

[vicvolf]

Dmitriy40 в сообщении #1688522 писал(а):

Хватило бы даже и погрешности в 0.2, для чего вроде бы хватает и 20000 нулей (если считать всё честно, без оптимизаций).

Вот именно. Ведь мы округляем $\pi(x)$ с точностью до 1.

[Dmitriy40]

Повторю, я говорил про другое.

[Yadryara]

Dmitriy40 в сообщении #1688522 писал(а):

vicvolf в сообщении #1688519 писал(а):

Меня наоборот удивило Ваше сообщение, что 10 млн. нулей не хватило для определения количества простых чисел для $\pi(155921)$,

Я такого не говорил, Вы выдумываете.

Подтверждаю, Дмитрий этого не говорил.

Dmitriy40 в сообщении #1688522 писал(а):

foreach(zm,z,print(real(-eint1(-log(1e24)*(0.5+I*z)))))

Всё-таки один минус для дзета-нулей надо ставить, а не два. Для единообразия предлагаю оставить минус только перед log.

Dmitriy40 в сообщении #1688522 писал(а):

гораздо хитрее, учитывать что при суммировании нули друг друга компенсируют.

Тогда нужно искать точки обратные резонансным, то есть точки поглощения, причём начинать надо тоже с первых нулей, а не с далёких.

Посмотрел на первые два нуля в низине:

        x       sum 2
   12.051   -0.000069
   14.557   -0.000077
   17.535    0.000098
   21.303    0.000019
   29.384    0.000037
   35.535    0.000035
   42.802   -0.000045
   51.878    0.000004
   71.627   -0.000002
   86.755    0.000038
  104.498    0.000022
  126.443    0.000004
  174.509    0.000001
  211.810   -0.000005
  255.145   -0.000020
  308.347   -0.000004
  424.769   -0.000005
  517.118    0.000004
  623.010   -0.000001
  752.215   -0.000003

sum 2 здесь означает sum(i=1,2, 2*real(eint1(-log(x)*(1/2+z[i]*I))))

[vicvolf]

Dmitriy40 в сообщении #1688533 писал(а):

Повторю, я говорил про другое.

Я понял, Вы говорите о вычислении $J(x)$ с идеальной точностью. Но это и не нужно, так как $\pi(x)$ вычисляется с точностью до единиц. Для этого требуется значительно меньше нулей.

[Dmitriy40]

Yadryara в сообщении #1688562 писал(а):

Всё-таки один минус для дзета-нулей надо ставить, а не два.

Я смотрю в программу и вижу код b+=-sum(j=1,#zm, 2*real(-eint1(-log(y)*(1/2+I*zm[j])))); с двумя минусами. И именно такой код и был рекомендован для вычисления li(x).
Может Вы хотели сказать про третий минус? Да, его можно внести внутрь real() и сократить минусы до одного перед логарифмом. Но не хочу, понятнее так, а минусов мне не жалко.

vicvolf в сообщении #1688568 писал(а):

Я понял, Вы говорите о вычислении $J(x)$ с идеальной точностью. Но это и не нужно,

Я и не говорил что это нужно. Я сказал что 10млн нулей для этого не хватило даже с точностью вывода в моей программе. Не "нужно", а "не хватило". Просто наблюдение.

vicvolf в сообщении #1688568 писал(а):

Для этого требуется значительно меньше нулей.

Хорошо что Вы разобрались почему хватило 70млрд нулей.

-- 03.06.2025, 11:14 --

Если же говорить о достаточности, то для числа n=155922 погрешность суммы от идеального значения (17.483811746221499642489216337689751178) стала меньше 0.7 лишь с 5536 нуля.
А меньше 0.6 она стала ниже сначала с 7731 нуля, но потом снова возросла выше с 31216 нуля, и окончательно (в рамках первого миллиона нулей!) ушла ниже только с 40654 нуля.
Меньше 0.5 погрешность от идеального значения уходила много раз: 8190-15883, 16075-29465, и только после 42025 нуля ушла окончательно.
Меньше 0.4 погрешность от идеального значения суммы уходила тоже неоднократно (показываю лишь дальше 42025): 50592-68187, 72980-77458, 91930-133923, и только с 133972 нуля ушла окончательно.
Меньше 0.3 погрешность стала окончательно с 152940 нуля.
Меньше 0.2 погрешность стала окончательно с 246844 нуля.
И любой из вот этих интервалов, когда погрешность снова стала выше порога лишь временно, можно ошибочно принять за ошибочный окончательный результат.
Как это решалось у Платта я не смотрел.
Выше везде речь лишь про одно значение $J(x)$, из первой строки, где корень первой степени, потому что остальные строки через нули дзета функции Римана вычислять не нужно, проще и быстрее через $\pi(x)$.

[Yadryara]

Dmitriy40 в сообщении #1688573 писал(а):

Может Вы хотели сказать про третий минус? Да, его можно внести внутрь real() и сократить минусы до одного перед логарифмом.

Ровно об этом и речь. Не три минуса, а один. Зачем множить сущности.

Dmitriy40 в сообщении #1688573 писал(а):

Но не хочу, понятнее так, а минусов мне не жалко.

Понятнее ? Тогда трёх маловато будет, может лучше до 5 или до 7 довести Результат не изменится.

Dmitriy40 в сообщении #1688573 писал(а):

vicvolf в сообщении #1688568 писал(а):

Для этого требуется значительно меньше нулей.

Хорошо что Вы разобрались почему хватило 70млрд нулей.

Кстати, не факт, что vicvolf разобрался. Неплохо бы продемонстрировать на каком-нибудь более простом примере, как обойтись меньшим количеством нулей.

Помнится как vicvolf считал по HL1:

vicvolf в сообщении #1632363 писал(а):

Есть первая гипотеза Харди-Литтлвуда о количестве k-кортежей на интервале $x$: $\pi(x,k) \sim \frac{Cx}{\ln^k(x)}$, где постоянная $C$ зависит от структуры кортежа. В данном случае я хотел просто грубо оценить порядок величины $x$ до первого кортежа, поэтому предположил значение $\pi(x,k)=1$, а значение $C$ вообще не учитывал. Наверно так делать нельзя, так как значение $C$ при большом значение $k$ велико и формула асимптотическая.

Во-первых, констант C не одна, а 31. И теперь мы знаем их все:

Dmitriy40 в сообщении #1684733 писал(а):

vC=[1592669394.7454967048413543203360474784, 224048612037.93039519376335978164281999, 15060404457776.501117870903945957690526, 643975079051969.03088164442593218519955, 19672864014876028.811392004831387751738, 457178627398399663.18641317636046162635, 8402763498659303975.5096285952058360662, 125377224477963805206.89777938556921101, 1546929025718798946089.7912641404857550, 15994906029871361204769.187564407532779, 139968081763087863869464.29066290148284, 1044156353257761368147093.1368606066768, 6675438285921407673520498.0916226089839, 36708432877688236096050822.004415616758, 174035122935989493790024654.03258975691, 712196947564732599952975315.78320487298, 2515955263037428615471767242.6561789800, 7665777149089072567977478763.2382586304, 20106445874574298344616432170.789792210, 45264384755093882439279790845.152290852, 87100700457132907803880854701.370644633, 142466968404912726214137650877.36926652, 196618531164038126660089156973.85750819, 226702801658738154151893801565.04524662, 215451193980762378792182794368.57516197, 165604812316252926590574664686.92377585, 100155274592395251942807287899.23908798, 45706363430133812262358484887.605564941, 14703144047237460493314662394.499537327, 2942032946247678005083329346.8122466890, 271007079912233354594900744.95914433491]

Во-вторых, значения констант $C0 - C30$, как видим, не просто большие, а порой офигеть какие большие, сильно больше 1-цы.

vicvolf, сможете проверить правильно ли посчитаны константы? Не все, а хотя бы три любые, на выбор.

[Dmitriy40]

Yadryara в сообщении #1688579 писал(а):

Понятнее ?

Да, понятнее: li(x)=-eint1(-log(x)). Именно эту формулу я нашёл где-то (кажется в OEIS и в StackOverflow), вот ровно в таком виде. С этим спорить не будете? А дальше уже лишь упрощение выражений, в чём я смысла не вижу (скорость счёта не увеличивает, зато легко забыть почему там в li(x) уже нет минуса и может это вообще уже не li(x)).
И вообще надо было определить функции li(x)=-eint1(-log(x)) и li_p(x,p)=-eint1(-log(x)*p) и уже только ими и пользоваться, без всяких внесений минусов внутрь функций.

Yadryara в сообщении #1688579 писал(а):

Неплохо бы продемонстрировать на каком-нибудь более простом примере, как обойтись меньшим количеством нулей.

Только что продемонстрировал:

Dmitriy40 в сообщении #1688573 писал(а):

Если же говорить о достаточности, то для числа n=155922 погрешность суммы от идеального значения (17.483811746221499642489216337689751178) стала меньше 0.7 лишь с 5536 нуля.
...

[Yadryara]

Dmitriy40 в сообщении #1688584 писал(а):

С этим спорить не будете?

Возможно буду, но позже. Ещё раз перепроверю формулу для действительных чисел и для комплексных.

Dmitriy40 в сообщении #1688584 писал(а):

Только что продемонстрировал:

Это я не Вас просил продемонстрировать.

Dmitriy40 в сообщении #1688584 писал(а):

меньше 0.7 лишь с 5536 нуля.

А можно ли обойтись лишь 5-ю сотнями нулей?

[vicvolf]

Когда $\pi(x)$ определяется, как сумма по $k$ значений

Dmitriy40 в сообщении #1688397 писал(а):

$\frac{\mu(k)}{k}J(\sqrt[k]{n})$

, то возникает еще вычислительная погрешность, которая добавляется к погрешности определения $J$?

Yadryara в сообщении #1688579 писал(а):

Помнится как vicvolf считал по HL1:

vicvolf в сообщении #1632363 писал(а):

Есть первая гипотеза Харди-Литтлвуда о количестве k-кортежей на интервале $x$: $\pi(x,k) \sim \frac{Cx}{\ln^k(x)}$, где постоянная $C$ зависит от структуры кортежа. В данном случае я хотел просто грубо оценить порядок величины $x$ до первого кортежа, поэтому предположил значение $\pi(x,k)=1$, а значение $C$ вообще не учитывал. Наверно так делать нельзя, так как значение $C$ при большом значение $k$ велико и формула асимптотическая.

В том то и дело, что я не считал, а прикидывал в уме. Считать это к Дмитрию.

[Yadryara]

vicvolf в сообщении #1688586 писал(а):

Считать это к Дмитрию.

А почему к Дмитрию? Вы не понимаете как считать константы?

Поэтому у меня и сомнения, что Вы понимаете как посчитано у Платта, хоть и сказали, что там написано доходчиво. Покажите, пожалуйста, на примере, как обойтись меньшим количеством нулей.

Dmitriy40 в сообщении #1688584 писал(а):

Да, понятнее: li(x)=-eint1(-log(x)). Именно эту формулу я нашёл где-то (кажется в OEIS и в StackOverflow), вот ровно в таком виде. С этим спорить не будете? А дальше уже лишь упрощение выражений, в чём я смысла не вижу (скорость счёта не увеличивает, зато легко забыть почему там в li(x) уже нет минуса и может это вообще уже не li(x)).

Перепроверил. Критическим является именно минус перед логарифмом, остальные можно убирать. То есть для счёта достаточно либо одного минуса, либо двух, в трёх нет необходимости.

[Dmitriy40]

Yadryara в сообщении #1688585 писал(а):

А можно ли обойтись лишь 5-ю сотнями нулей?

Я не представляю как: на 500-м нуле погрешность составляет -3.6, на 480-м она была -3.99, на 521-м снова -3.83. ну и как из этого понять что сумма потом уйдёт на 3.6 выше текущей ...
И кстати погрешность пересекала 0 на 446450 нуле, и потом ещё много раз. И вообще говоря не факт что после миллиона нулей она не доберётся до +0.5 ... Например до +0.1 она добралась на 744881 нуле, а около 798794 нуля она добралась и до +0.124.
Формально же погрешность нужна менее 0.5 (по модулю), и то, я бы для надежности взял 0.45...0.4.

vicvolf в сообщении #1688586 писал(а):

то возникает еще вычислительная погрешность, которая добавляется к погрешности определения $J$?

Да, разумеется, но PARI считает с точностью 38 значащих цифр (и можно сделать хоть миллион), что превышает точность первых 10млн нулей, так что погрешности вычислений в далёких знаках после запятой и роли не играют.

Yadryara в сообщении #1688592 писал(а):

Критическим является именно минус перед логарифмом, остальные можно убирать. То есть для счёта достаточно либо одного минуса, либо двух, в трёх нет необходимости.

Ну а мне удобнее видеть что считается именно li(x), в котором два минуса, а не абы что. Пока это не сильно влияет на скорость.

[Yadryara]

Добавку к посту не сразу заметил.

Dmitriy40 в сообщении #1688573 писал(а):

Меньше 0.3 погрешность стала окончательно с 152940 нуля.
Меньше 0.2 погрешность стала окончательно с 246844 нуля.
И любой из вот этих интервалов, когда погрешность снова стала выше порога лишь временно, можно ошибочно принять за ошибочный окончательный результат.

Вот поэтому слово "окончательно" неудачное. Ещё 12 лет назад, читая Дербишира на 407-й бумажной странице "Окончательный результат равен -0,370816425..." подумал: "А откуда он знает какой окончательный результат?" И ответил себе: "Да он вычитанием это определил." Ведь для маленьких чисел $\pi(x)$ прекрасно известно.

Так что если считать в лоб складывая нули, то сходимость очень плохая и потому формула Римана по сути непригодна для практических вычислений.

Dmitriy40 в сообщении #1688626 писал(а):

Я не представляю как: на 500-м нуле погрешность составляет -3.6,

Так вот именно, а Платт, видимо, представляет. И vicvolf, вроде бы, представляет. Но не рассказывает пока.

[vicvolf]

Yadryara в сообщении #1688592 писал(а):

Покажите, пожалуйста, на примере, как обойтись меньшим количеством нулей.

У меня есть маленькая программа на Phyton, которая подсчитывает $J(x)$ по формуле Римана. Чтобы она считала быстро я взял $x=500$ и $T=100,200,300,350,360$. Это не меняет сути. Вот результаты:

Введите x (>2): 500
Введите T (высота обрезания нулей, например 100): 100
J(500.0) ≈ 101.67028552503706335196860058874042659004510020639

Введите x (>2): 500
Введите T (высота обрезания нулей, например 100): 200
J(500.0) ≈ 101.45730981715565773375323224981284644093037647246

Введите x (>2): 500
Введите T (высота обрезания нулей, например 100): 300
J(500.0) ≈ 101.3993827996977496953639381082889243166190724738

Введите x (>2): 500
Введите T (высота обрезания нулей, например 100): 350
J(500.0) ≈ 101.38359916719723374713052912698255498741239274133

Введите x (>2): 500
Введите T (высота обрезания нулей, например 100): 360
J(500.0) ≈ 101.38145163741553383733018788945674905527660705906