Пентадекатлон мечты

[VAL]

Huz в сообщении #1562544 писал(а):

I have $M(720) \le 127$.

The result is actually for $n+5$, final digits should be "..28124".

Thanks!

[Yadryara]

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

Вашему вниманию предлагается таблица наименьших известных непрерывных 14-к

Ну вот, только стоило таблицу опубликовать, как мировой рекорд из неё уже побит аж в три раза!

$T(6,14)\leqslant 182212015721072444191301392660439641$ Demis.

[Huz]

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

Ну вот, только стоило таблицу опубликовать, как мировой рекорд из неё уже побит аж в три раза!

$T(6,14)\leqslant 182212015721072444191301392660439641$ Demis.

Grats! I'm not sure what "Demis" is - is that a person to whom this should be attributed? Or is that Anton, or Natalia?

[VAL]

$M(504)\ge 9$

(Оффтоп)

393713064999337022904353228111411721727464757644352420765999013360633532711030366601502108282715372801602705285307534671869

[Yadryara]

Huz в сообщении #1562186 писал(а):

I think I'm the only person actively working towards such a goal.

Зря Вы так. А как же мы?

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

Аn — Anton
De — Demis
Dm — Dmitriy
Na — Natalia

Да, мы ищем по другим алгоритмам. И, если угодно, с другого конца, со стороны более длинных цепочек, 14-к и 15-к.

Большое Спасибо всем кто ищет сам или помогает искать другим.

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

Да, Demis это псевдоним. Не хочет человек лишней огласки — имеет право. Всё же прошу Hugo включить его в новый релиз, то бишь А-файл.

Я не ругался именно на самодеятельность Наталии, я был недоволен тем что мне неизвестны параметры этой самодеятельности. И до сих пор неизвестны кстати. Непонятно как вычислялся kolshag. Если он вычислялся верно или с ошибкой в большую сторону, то подклассы 234 и 259 можно записать в число полностью обсчитанных, если с ошибкой в меньшую сторону — то нельзя. И файлы подробной статистики Process.out по всему диапазону 0 — 5401e33 мне тоже нужны.

Сам я скомпилил и обсчитал комплекты до 295-го включительно. Затем, в связи со сменой парадигмы(о чём расскажу отдельно) вернулся к 23-му комплекту и дообсчитал его. Таким образом, количество полностью обсчитанных комплектов возросло до пяти:

Эталонный нулевой, 23-й, 262-й, 310-й, 314-й.

[Huz]

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

Huz в сообщении #1562186 писал(а):

I think I'm the only person actively working towards such a goal.

Зря Вы так. А как же мы?

I do not mean to denigrate anyone else's work; however finding the minimum value involves proving that it is minimal, and I'm not aware of anyone working on that other than myself - but I confess that many of the discussions between you and Dmitry do not translate well, so I may be unaware of what is right in front of me.

Цитата:

Да, Demis это псевдоним. Не хочет человек лишней огласки — имеет право. Всё же прошу Hugo включить его в новый релиз, то бишь А-файл.

Hmm, that may be a problem for the OEIS A-file: the OEIS expects submissions to be "of the same standard as a mathematical journal", and as part of that standard insists on real names for contributors. I'll have to check with other editors whether that standard also extends to me reporting a discovery by a pseudonymous third party, or what to do in that case.

[EUgeneUS]

Huz
Yadryara
We all know about the Student distribution. It was developed by English statistician William Sealy Gosset under the pseudonym "Student".
Thus, using an pseudonym when publishing results does not seem to be a problem.

Well, if you need to specify a first and last name in the a-file, then maybe ask the Demis to choose a pseudonym with a first and last name?

-- 13.08.2022, 07:41 --

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

Зря Вы так. А как же мы?

Не нужно обижаться.
Хуго, видимо, действительно единственный человек, который пытается доказать, что некоторые цепочки являются минимальными.
Ваша команда ищет всё меньшие цепочки двух типов (14-ка и 15-ка на 12 делителей). Но даже не представляю, как можно было бы доказать (за обозримое время), что какая-то из найденных вами цепочек будет минимальной.

[Yadryara]

EUgeneUS, рад Вас вновь видеть. Счёты больше не простаивают ?

[Dmitriy40]

Да никак нельзя доказать что найденные цепочки минимальны: даже для замены одной только 37 надо проверить подстановку всех простых до $\sqrt{\frac{5401\cdot10^{33}}{8\cdot(2\times3\times5\times7\times11\times13\times17\times19\times23\times29\times31)^2}}\approx4.1\cdot10^6$. Да, последний миллион вариантов можно проверить очень быстро (шаг будет большим и попыток надо сделать мало и можно на PARI без ускорителей), но ведь это замена только одного числа, а чисел можно заменять мало того что шесть штук, так ещё и комбинации из них.
Да, может ещё неоднократно повезти и величина 5401e33 ещё уменьшится, но во первый когда, во вторых насколько.

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

Эталонный нулевой, 23-й, 262-й, 310-й, 314-й.

Я тут посчитал немного, до границы 5401e33, комплекты 234, 482, 540, 664, 872, 1104, 1188, 1905, 1911, 1937, 1941, можете все их помечать проверенными. Из интересного (14-ки и 15-ка) нашлось только (уже не рекордные):
x540\N9-53-842536:251965067711102426690889681603235545: 24, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, valids=14
x1911\N2-35-3S1462:600025123366056883938250029428621145: 12, 12, 48, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, valids=14, ALL
x872\S9-56-A62345:3274477987462436933721552911787926041: 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12,192, 12, 12, valids=14, ALL
В начальные комплекты я лезть не хочу, так что работа с вашей не пересекается.

-- 13.08.2022, 10:19 --

(Забавное наблюдение)

Хотел тут запустить счёт на ноуте с 4-х ядерным 8-ми потоковым процом, но на нём почему-то компиляция одного ускорителя вместо 0.3с занимает аж 8.5с! Даже в один поток. Мрак. А счёт даже немного быстрее чем у меня. Т.е. похоже дело в диске ... Хотя у себя разницы между SSD и HDD не вижу. Не стал разбираться, плюнул.

[Yadryara]

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

Да никак нельзя доказать что найденные цепочки минимальны: даже для замены одной только 37 надо проверить подстановку всех простых до $\sqrt{\frac{5401\cdot10^{33}}{8\cdot(2\times3\times5\times7\times11\times13\times17\times19\times23\times29\times31)^2}}\approx4.1\cdot10^6$

Это я перепроверю. Надеюсь, теперь-то Вам очевидно, что рано или поздно код придётся переписывать на несколько паттернов.

Давно хотел спросить, 156 вариантов замен как подсчитали?

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

Но так да, выходит всего примерно 156 вариантов замен,

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

Потому если будет интерес народа, то готов и выложить у себя в облаке, и скомпилить несколько других вариантов (все 156 не просить ).

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

Я тут посчитал немного, до границы 5401e33, комплекты 234, 482, 540, 664, 872, 1104, 1188, 1905, 1911, 1937, 1941, можете все их помечать проверенными. Из интересного (14-ки и 15-ка) нашлось только (уже не рекордные):
[..]
В начальные комплекты я лезть не хочу, так что работа с вашей не пересекается.

Спасибо! Вообще-то по 234-му пересекается. Правда, насколько я знаю, он обсчитан до 5000е33, а не до 5401е33. (Я установил стоп ещё до обнаружения новой 15-шки.) Ну даже хорошо, если пришлёте логи, сверим. Если и другой лог(Process.out) пришлют.

[Dmitriy40]

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

Давно хотел спросить, 156 вариантов замен как подсчитали?

Сейчас уже не вспомню, скорее всего ограничил величину шага чтобы ускорителям оставался минимум один полный круг (в то время он был 227млн), т.е. проверял какие варианты замен поднимают границу с 1e35 (один круг счёта) не выше чем 664e35 (наименьшая известная тогда 15-ка). Чтобы оставался смысл использования ускорителей и они выдавали бы ту же скорость (с тем же количеством 227млн проверяемых индексов за вызов).
Да, оказалось это слишком ограниченный расчёт, вариантов на порядки больше.

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

Ну даже хорошо, если пришлёте логи, сверим.

Прислал почтой, с комментариями.

[Yadryara]

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

Это я перепроверю.

Перепроверил. Настоящий шаг-то в 6 раз больше:

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

$$2^63^3\prod_{i=3}^{12}p_i^2=Step$$

2-ка в 6-й степени, а не в 5-й и 3-ка в 3-й степени, а не во 2-й. И Вы это знали и в прогах где-то на 6 умножаете, надеюсь.

Так что

$$\sqrt{\frac{5401\cdot10^{33}}{48\cdot(2\times3\times5\times7\times11\times13\times17\times19\times23\times29\times31)^2}}\approx1.67\cdot10^6$$

Что эквивалентно проверке примерно $126$ тысяч простых чисел в 1-й строке 1-й таблицы. В остальных строках этой же таблицы всё меньше и меньше.

[Dmitriy40]

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

Настоящий шаг-то в 6 раз больше:

При использовании моих ускорителей не шаг в 6 раз больше, а количество попыток проверок индексов в 6 раз меньше, потому что в 6 раз шаг изменяется уже внутри ускорителя (он проверяет не 227млн индексов как заказано, а лишь 227млн/6=38млн, а реально ещё меньше за счёт массива bb[]). Так что нет, не до 1.67млн, а таки до 4.1млн. Подставьте в формулу вместо 5401e33 значение 4.4e26 (расчётный шаг для изначальных ускорителей) и получите что простые надо проверять до 37 - как и есть, а не в 6 раз меньше. Банальная же проверка, я её сразу сделал.
Увеличение шага в программе VAL - это уже фильтрация (как и проверка по индексам), мои ускорители любую фильтрацию делают полностью сами, снаружи (в PARI коде) работа идёт без учёта любой фильтрации (например для изначального варианта шаг 4.4e26, а не в 6 раз больше).
Хотя конечно что 1.67млн, что 4.1млн, и то и другое почти одинаково нереально.

-- 13.08.2022, 14:26 --

Хотя нет, мы оба неправы: верхняя граница зависит от того какой именно вариант по модулю 6 подходит, если равный нулю, то правы Вы, если равный 5, то прав я, если другие то граница будет промежуточной. Причём в исходном варианте остаток равен 4, а в других комплектах он вполне может быть (и реально есть) другой.
Более того, остаток меняется даже внутри одного комплекта, так что нельзя брать меньшие значения и тогда почти всегда прав таки я (разве что вдруг в каком-то комплекте не будет ни одного паттерна с остатком 5).

-- 13.08.2022, 14:45 --

Я даже больше скажу, если в M12mods1.gp убрать вывод номера паттерна в группе (последний foreach), увеличить массив rr до 289550 штук и заменить в r=[] любое число на 289550 (т.е. на простое 4096667), то pp=Mod(5357515110390795106745540511859271641,5400600826664385070754510562870592800) - т.е. куча допустимых паттернов с величиной чисел чуть менее 5401e33. Это прямой пример что простые нужны почти до 4.1млн.

[Yadryara]

Н-да. Что-то здесь не то.

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

Я даже больше скажу, если M12mods1.gp убрать вывод номера паттерна в группе (последний foreach), увеличить массив rr до 289550 штук и заменить в r=[] любое число на 289550 (т.е. на простое 4096667), то pp=Mod(2442457878795566908170814512778425241,5400600826664385070754510562870592800)

Ну то есть стартовая точка 2442e33. И первый же шаг делать бессымысленно: уже будет существенное превышение. А без первого шага проверка осуществляется? В прогах на Пари она делалась ещё до первого шага. Если так, то ситуация ещё менее приятная — надо, чтобы стартовое число превышало 5401е33.

[Dmitriy40]

Yadryara
Я поменял pp в сообщении выше, теперь стартовая точка практически в конце, посмотрите.
При правильном вызове ускорителя он никогда не станет проверять цепочки больше 5401e33 - потому что ему не заказали проверку столь больших индексов. Тут есть тонкость, но пока для простоты можно считать так.
Индексы проверяются с наименьшего заказанного до наибольшего в порядке увеличения, но не все подряд, а только допустимые, и вот их то как раз в несколько раз меньше всех заказанных (минимум в 6 раз, а реально и в 28 раз бывает, зависит от bb[], коэффициент пишется файлом Yadryara6.gen.gp при компиляции в строке "Blocks=9102/780=11.669x"). Список допустимых индексов (по модулю блока, например 9102 выше) можно увидеть в файле .inc в таблице по метке offsets. Если первый же подходящий индекс уже выше заказанной границы, то всё сложно: будет проверен один блок индексов (в примере выше 9102шт, из них подходящих индексов лишь 780шт, именно они будут проверены) или до конца, или до нахождения первого же кандидата в решение, если таковой найден, то выход из ускорителя произойдёт при попытке его печати (команда jnc .stop в строке 188 файла Yadryara5.asm, недалеко ниже метки .check), если не найден, то при после перехода в следующий блок он проверяться уже не будет так как индекс станет больше заказанной границы (команда jc .stop в 135-й строке файла Yadryara5.asm, прямо перед меткой .start). Проверка одного блока, как и переход к следующему, это миллисекунды, оптимизировать не вижу смысла (вызывать ускоритель для проверки менее сотен тысяч (а скорее даже миллионов) индексов - впустую тратить время, на накладные расходы уйдёт больше времени чем на проверку стольких индексов).