Кстати, BOINC-проект SPT тоже замечательно обсудили на dxdy.ru.
И ошибки, и пропуски, и разрыв БД...
Да, всё есть.
Все люди ошибаются.
Другое дело, что в данном случае рулевой не захотел что-то изменять и продолжает гнать кривой проект.

Замечу, что все значимые результаты с проекта я проверяю, в этих результатах ошибок нет.

Теперь по сути.
Один из читателей моего блога писал

Я всё-таки попробовал применить китайцев до 37
нашёл у вас подходящую 17-ку и подогнал начало расчётов так, чтобы она попала в один период для проверки
[0, 6, 24, 36, 66, 84, 90, 114, 120, 126, 150, 156, 174, 204, 216, 234, 240]
17
period=742738134810
3: [1, 2]
5: [2, 3]
7: [2, 3]
11: [3, 10]
13: [9, 11]
17: [6, 7, 8, 9]
19: [1, 3, 4, 6, 8, 9, 17, 18]
23: [4, 6, 7, 9, 15, 16, 20, 21]
29: [1, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 20]
31: [2, 6, 11, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 28]
37: [2, 3, 4, 5, 7, 9, 10, 12, 14, 15, 16, 17, 20, 23, 24, 26, 30, 32, 33, 36]
4587520 formulae expected
from 19252813982628254538510 to 19252814175567446043570
1 are found of 4587520

19252814175273852997757 p
19252814175273852997763 p
19252814175273852997781 p
19252814175273852997793 p
19252814175273852997823 p
19252814175273852997841 p
19252814175273852997847 p
19252814175273852997871 p
19252814175273852997877 p
19252814175273852997883 p
19252814175273852997907 p
19252814175273852997913 p
19252814175273852997931 p
19252814175273852997961 p
19252814175273852997973 p
19252814175273852997991 p
19252814175273852997997 p
time = 15min, 13,288 ms.

> поиск 17-ки с минимальным диаметром, требует всего 128 формул на периоде 510510.
у меня период больше в 14 535 931 раз
а формул —только в 35 840 раз

Так что, высокоэффективный метод известен не только Ядряре (и г. Петухову), как он, очевидно, полагает.
Почему же я не использую этот метод?
Инерция и какое-то внутреннее недоверие к высокой эффективности этого метода.

Хм...

4587520 formulae expected

Можно попробовать, не столь уже много, не 200 миллионов формул, как у г. Петухова

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

https://dxdy.ru/post1057479.html#p1057479

Не забудем также, что у меня ведётся поиск ключевых 17-ок, а не поиск 19-ки с минимальным диаметром.
А поиск 17-ок, как ни крути, легче поиска 19-ок.
Ключевые 17-ки и только они могут дать 19-ку с минимальным диаметром.
В этом суть моего подхода.
Впрочем, это подход Ярослава Врублевского.
Он использовал его ещё в прошлом конкурсе по кортежам.

4587520 formulae expected

А не ошибся ли мой читатель?

Программа gris выдаёт следующее

(14:57) gp > \r formulae_37.txt
  ***   Warning: not enough memory, new PARI stack 2147483648
  ***   Warning: new stack size = 2147483648 (2048.000 Mbytes).
[0, 6, 24, 36, 66, 84, 90, 114, 120, 126, 150, 156, 174, 204, 216, 234, 240]
17
 3: [1, 2]
 5: [2, 3]
 7: [2, 3]
11: [3, 10]
13: [9, 11]
17: [6, 7, 8, 9]
19: [1, 3, 4, 6, 8, 9, 17, 18]
23: [4, 6, 7, 9, 15, 16, 20, 21]
29: [1, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 20]
31: [2, 6, 11, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 28]
37: [2, 3, 4, 5, 7, 9, 10, 12, 14, 15, 16, 17, 20, 23, 24, 26, 30, 32, 33, 36]
32112640 formulae expected

Сформировать формулы удалось и записать их в выходной файл удалось, но прочитать файл в 465705 КБ мой Блокнот не осилил.
И как мне эти формулы в рабочую программу перетащить?
Хорошо г. Петухову, у него формулы формировались "на лету", то есть ему их не надо было все запоминать и куда-то записывать.
Я правильно понимаю?

В общем, с 37# попытка с треском провалилась.
Попробую для 29#.

PS. Всё-таки не мешало бы проверить, у кого ошибка - у моего читателя или у gris.
Почему количество формул так сильно отличается?

А, ну вот, сравним остатки, которые у моего читатаеля

period=742738134810
3: [1, 2]
5: [2, 3]
7: [2, 3]
11: [3, 10]
13: [9, 11]
17: [6, 7, 8, 9]
19: [1, 3, 4, 6, 8, 9, 17, 18]
23: [4, 6, 7, 9, 15, 16, 20, 21]
29: [1, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 20]
31: [2, 6, 11, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 28]
37: [2, 3, 4, 5, 7, 9, 10, 12, 14, 15, 16, 17, 20, 23, 24, 26, 30, 32, 33, 36]

с остатками у gris.
Остатки-то полностью совпадают!
Элементарное перемножение даёт 32112640 формул.

PS. А может, есть одинаковые формулы?
Проверила 114688 формул для 29#, одинаковых формул не обнаружено.

Итак, вот проход новой версии программы (поиск ключевой 17-ки) - для 29#

(18:09) gp > \r 17pat.txt
   logfile = "17pat_res.txt"
  ***   Warning: new stack size = 536870912 (512.000 Mbytes).
range of search for 17tuples
134396075594001 (p=869501380409076498313230 )
134396075600000 (p=869501380447888188000000 )

time = 3h, 53min, 27,690 ms.

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

Завтра займусь этим.

Стефано ответил
https://dxdy.ru/post1625567.html#p1625567
Молодец!

Теперь Ядряре в самый раз сказать так: "Почему бы не рекомендовать конкурсантам высокоэффективные алгоритмы и программы?"
А потом придёт г. Петухов и скажет: "Организаторам конкурса наплевать на скорость программ, миллионы лет счёта их не пугают".
Ни Ядряра, ни г. Петухов даже не задумались: "где организаторы конкурса, а где скорость программ".
Им лишь бы дудеть в свою дуду!

А г. Петухова миллионы лет счёта не пугают? :)

Покажу итоги года, счёт был с апреля 2023. Досчиталось до 85e22, плюс отдельные мелкие кусочки.

https://dxdy.ru/post1624329.html#p1624329

У него-то программа самая высокоэффективная, однако... счёт годам давно пошёл, ещё отсюда

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

https://dxdy.ru/post1057479.html#p1057479

Симметричный кортеж длины 19 из последовательных простых чисел с минимальным диаметром 252 может найтись у г. Петухова (или у кого-то другого) через неделю или через месяц, а может не найтись ещё 10 лет.
Никто не знает, в каком диапазоне находится этот кортеж.

Вот посчитает Ядряра все кэфы и скажет тогда, в каком диапазоне надо искать эту 19-ку.
А прогнозы Ядряры (вы же знаете) исполняются всегда всенепременно :)
Как он скажет, так и будет!
Посмотрите, например, здесь
https://dxdy.ru/post1615557.html#p1615557
И неважно, что цитату Ядряра обрезал, а было так

Разумеется, в любой момент 19-ка может найтись, а может и припоздниться.

Хи-хи-хи!
Бабушка надвое сказала :)))

Ядряра писал в сообщении
https://dxdy.ru/post1625609.html#p1625609

Просто речь идёт о том, что если считать столь медленным способом, то непонятно что случится раньше — распад протона или 19-252 найдётся.

И ведь никто не держит в секрете способ подсчёта миллионов остатков на лету. Совсем недавно приводил прогу, где это делалось. Работает даже без обычной сортировки остатков по возрастанию.

Так ведь написано же чёрным по белому

However each contestant uses the algorithms and software he sees fit.

Не понятно?
Дело каждого конкурсанта выбирать алгоритмы и программы.
Как это ещё надо разъяснить, чтобы было понятно???

И ведь никто не держит в секрете способ подсчёта миллионов остатков на лету.

Так ведь г. Петухов начал использовать этот метод в 2015 году!
И где же 19-ка с минимальным диаметром???
Почему она до сих пор не нашлась столь высокоэффективным способом?

К тому же, никто не держит в секрете от конкурсантов высокоэффективные алгоритмы и программы.
Читаем правила конкурса

Rules
You can complete one or more of the seven suggested tasks.
You can use the algorithms and programs that you will find at the links below.
You are allowed to use any computer technology, including clusters and supercomputers.

И в ссылках есть ссылка на тему "Симметричные кортежи из последовательных простых чисел"

8. Symmetric tuples of sequential primes
https://dxdy.ru/topic100750.html

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

И не желаете вникать в детали?

Зачем Стефану вникать в детали?
Я уже писала: Стефано предоставил площадку для конкурса.
Алгоритмы и программы он не обязан предоставлять.
Задачи поставлены.
Пусть конкурсанты их решают.

Просто речь идёт о том, что если считать столь медленным способом, то непонятно что случится раньше — распад протона или 19-252 найдётся.

Так начните прямо сейчас считать высокоэффективным способом!!
И найдите 19-252 в рамках конкурса, то есть до 4 апреля т. г.
Что мешает?

Самочувствие не позволяет заняться сравнением скоростей программ.
Запустила опять новую версию программы (для 29#) для крохотного интервала, вот нашлась центральная тройка

869501380472648041792721: [114, 120, 126]
869501380472648041792607: [0, 20, 26, 36, 50, 66, 72, 114, 120, 126, 134, 194, 2
06, 212, 222, 234, 240]
time = 3h, 9min, 11,459 ms.

Запустила снова такой же интервал.
Опять центральная тройка

869501380486988407148191: [114, 120, 126]
869501380486988407148077: [0, 10, 24, 54, 70, 72, 112, 114, 120, 126, 136, 156,
162, 174, 204, 216, 240]
time = 3h, 10min, 9,024 ms.

Ох! Вот сказанул!..

Г. Петухов писал в сообщении
https://dxdy.ru/post1625620.html#p1625620

А я показывал как добавлением одной строчки можно ускорить программу почти впятеро только за счёт замены части проверок ispseudoprime на setsearch от частного, что оказывается намного быстрее. Так можно (более-менее) ускорить фактически любую программу проверки по паттернам на PARI.

Ещё раз - для самых умных:

Все гениальные алгоритмы и программы Ядряры и г. Петухова доступны всем потенциальным конкурсантам.

И далее г. Петухов написал

А насчёт приза ... Только у меня и только в задаче #3 поиска 19-252 уже потрачена практически вся сумма приза только на электричество. Сколько сожгли кранчеры можно прикинуть отдельно (2млн.ч по пусть 50Вт по 5р/кВтч выйдет полмиллиона рублей! вот такова цена "бесплатных" вычислений).

Может быть, мне надо оплатить поиск г. Петуховым 19-ки с минимальным диаметром??? :)))
А также и работу всех кранчеров за 6 лет в пяти BOINC-проектах?!

Была бы несказанно рада, если бы два сапога умника прекратили всякую деятельность в моём проекте и перестали писать несусветные глупости в моей теме.
Не понимаю, зачем г. Петухов тратит такие деньжищи на поиск какой-то никому не нужной 19-ки?
А теперь как бы уже мне счёт выставляет :)))
Видит Бог, я его не заставляла искать эту злосчастную 19-ку!
Пусть бросает уже.
У меня нету денег на оплату затраченного им электричества.

Вялотекущий эксперимент продолжаю потихоньку.

Подумала, что в программе с периодом 29# интервал должен быть совсем маленький, чтобы соответствующий ему интервал в программе с периодом 17# обрабатывался не слишком долго (даже если ускорение будет, например, в пять раз).
При этом желательно, чтобы в интервале было найдено решение, хотя бы центральная тройка.
Это решение должно быть найдено обеими программами.

Так что, запустила совсем крохотный интервал в программе с периодом 29#

i1=134396075610001;
i2=134396075611000;

Жду результаты.
Если центральная тройка здесь найдётся, тогда промасштабирую этот интервал для программы с периодом 17# и выполню эту программу.
Останется сравнить время работы двух программ.

Очень интересно: каково же будет ускорение при переходе от периода 17# к периоду 29# (при поиске 17-ки по паттерну - ключевой 17-ки).
Разумеется, не 40-кратное, как там у Ядряры получается (но у него период 37#, у меня с таким периодом вообще ничего не получилось, формул больше 32 миллионов и даже записать их в рабочую программу я не смогла; к тому же, у него, кажется, рассматривался поиск 19-ки по паттерну, а у меня поиск 17-ки по паттерну).
Ну, хоть какое-то будет ускорение?

Если в этом интервале решение не найдётся, запущу следующий такой же.
Ждём-с.

Решений не нашлось; обработался интервал быстро

(03:42) gp > \r 17pat.txt
   log = 1 (on)
   [logfile is "17pat_res.txt"]
  ***   Warning: new stack size = 536870912 (512.000 Mbytes).
range of search for 17tuples
134396075610001 (p=869501380512591589993230 )
134396075611000 (p=869501380519054813530000 )

time = 38min, 16,460 ms.

Запустила следующий такой же интервал.

Наконец-то, получила решение

(16:52) gp > \r 17pat.txt
   logfile = "17pat_res.txt"
  ***   Warning: new stack size = 536870912 (512.000 Mbytes).
range of search for 17tuples
134396075616001 (p=869501380551409749373230 )
134396075617000 (p=869501380557872972910000 )

869501380556932775998001: [114, 120, 126]
869501380556932775997887: [0, 24, 36, 42, 72, 86, 110, 114, 120, 126, 192, 194,
210, 222, 234, 236, 240]
time = 38min, 17,568 ms.

Теперь можно масштабировать и запускать программу для периода 17#.

Хи-хи-хи!

Г. Петухов писал в сообщении
https://dxdy.ru/post1625795.html#p1625795

Кстати вот и реальная скорость поиска паттерна 19-252 на PARI: 3.0425e14/144*3600=7.6e15 в час.
Моя же программа на асм+AVX2 в тех же условиях (тоже с таблицей 41#) перебирает со скоростью 3.8e18 в час, в 500 раз быстрее. А с таблицей 47# и 9.1e18/ч, в 1200 раз быстрее. Вот такой PARI тормозной.

Похвалимся! Ещё раз похвалимся! В десятый раз похвалимся!

А я писала чуть раньше в сообщении
https://boinc.progger.info/odlk/forum_thread.php?id=273&postid=13376

А у г. Петухова есть супер-пупер программы, которые дают ускорение не в 40 раз, а в 1000 раз.
Флаг ему в руки.
Пусть покажет результаты!
А мы посмотрим :)

Ага!
Если на "тормозном PARI" 19-ка с минимальным диаметром будет искаться миллион лет, то супер-программой г. Петухова, которая в 1200 раз быстрее, он найдёт эту 19-ку всего за 1000000/1200 = 833,3333333 лет :)))
Ну, это уже хорошо, правда, я уж точно не доживу :)
Жаль.

Тут надо бы понимать, что дело не в миллионах лет, и это пустое сотрясание воздуха.
Однако... это надо понимать, а не упереться, как баран в ворота, в миллион лет и в тормознутость PARI.

Например, дело прежде всего в массовости вычислений.
19-ку с минимальным диаметром надо искать по обширному полю, а не только у одного ручья.
А для поиска по обширному полю нужны тысячи машин, а не только компьютеры г. Петухова, хоть их там 10 штук и в каждом 56 ядер.

Я уже приводила пример с 19-ми, которые найдены в BOINC-проекте SPT, но г. Петухов этот пример, наверное, не читал.
И зря!

Поиск по обширному полю можно реализовать, например, на кластере или суперкомпьютере.
Кто-то ведь имеет и такие возможности.

Кстати о птичках...
Хорошо, похвалился г. Петухов в десятый раз своей супер-программой.
И что? Да ничего.
А что если г. Петухов зарегистрируется в конкурсе и предложит там свою супер-программу.
Слабо?
Разрекламировать как следует супер-программу, глядишь, набегут конкурсанты и вмиг найдут 19-ку с минимальным диаметром.
А?

Ну, а сидеть в своём углу и квакать оттуда, что всё в конкурсе плохо, - это занятие сами знаете для кого.

PS. На худой конец, организовали бы уже два сапога умника распределённые вычисления на dxdy.ru по супер-программе г. Петухова.
Ведь у г. Лецко получилось!

Ой, отмасштабировалось на удивление точно!
Запустила программу для периода 17#

(02:34) gp > \r 17pat_test.txt
   log = 1 (on)
   [logfile is "17pat_test_res.txt"]
  ***   Warning: new stack size = 536870912 (512.000 Mbytes).
range of search for 17tuples
1703201466281580673 (p=869501380551409749373230 )
1703201466294241000 (p=869501380557872972910000 )

Теперь осталось дождаться, когда она выполнится.
А потом посмотреть на время выполнения и сравнить его с временем выполнения программы для периода 29#.
Вот и все дела.

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

Ядряре точно такое же задание: высокоэффективную программу для конкурсной задачи #1 в студию!!
А затем надо зайти на страницу конкурса (да, именно туда) и предложить свою высокоэффективную программу.

Вот это будет дело.
А пока один трёп.

Я вот сейчас как раз экспериментирую с программой для конкурсной задачи #1.
Программа работает, но работает, конечно, медленно.
И я это прекрасно знаю, мне не надо об этом в сотый раз напоминать.
Я осталась без техники, с одной черепашкой.
Поэтому развернуть масштабные эксперименты по всем имеющимся у меня алгоритмам не могу.
А алгоритмы у меня имеются для всех семи конкурсных задач, а не только для поиска 19-ки с минимальным диаметром.

Цитата из сообщения
https://boinc.progger.info/odlk/forum_thread.php?id=268&postid=13374

Вот уже пошли результаты

[logfile is "17-27tuple_res.txt"]
   *** Warning: new stack size = 536870912 (512.000 Mbytes).
range of search for 17tuples
1803201465993400001 (p=920552380404290634510510 )
1803201466000000000 (p=920552380407660000000000 )
range of search for 19tuples
1803201465993400001 (p=17490495227681522055699690 )
1803201466000000000 (p=17490495227745540000000000 )
range of search for 25tuples and 27tuples
1803201465993400001 (p=402281390236675007281092870 )
1803201466000000000 (p=402281390238147420000000000 )

920552380404965706798187: [114, 120, 126]
920552380404965706798073: [0, 6, 10, 18, 78, 88, 108, 114, 120, 126,
154, 156, 196, 220, 226, 238, 240]
402281390237055303386648177: [114, 120, 126]
402281390237055303386648063: [0, 18, 20, 48, 50, 80, 90, 114, 120, 126,
168, 176, 204, 210, 218, 234, 240]

Первая центральная тройка найдена в первой ветви программы (поиск ключевой 17-ки по паттерну), второе решение найдено в третьей или в четвёртой ветви программы (в 25-ах или в 27-ах).
Эх, куда занесло - 27-значные числа!
Программа ещё работает, интервал задан приличный [1803201465993400001, 1803201466000000000].

__________________________
конец цитаты

Это Стефано считает по моей программе для конкурсной задачи #1.
Да-да, по весьма неэффективной программе!
Ну, Ядряра ведь ещё не выложил высокоэффективную программу для этой конкурсной задачи.
Как только выложит и покажет её высокую эффективность, тогда я, может быть, воспользуюсь его программой.
А пока пользуюсь своей.

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

А вот и новые решения Стефано прислал

17490495227714211883059667: [114, 120, 126]
17490495227714211883059553: [0, 4, 34, 58, 64, 70, 100, 114, 120, 126,
130, 150, 156, 168, 196, 216, 240]
17490495227715629286847621: [114, 120, 126]
17490495227715629286847507: [0, 6, 16, 22, 46, 66, 90, 114, 120, 126,
136, 144, 154, 156, 214, 226, 240]

Тоже центральные тройки, обе найдены во второй ветви программы (поиск ключевых 17-ок в 19-ке с минимальным диаметром).

Б-л-и-и-и-и-н!!!

Ядряра писал в сообщении
https://dxdy.ru/post1625848.html#p1625848

Что мешает поправить программу и считать в 38 раз быстрее? Зачем продолжать тестировать карету с конной тягой, вместо того чтобы на самолёте лететь ??

Во-первых, уже сказано, что Стефано ничего сам не считает.
Ядряра, вам это понятно???

Во-вторых, Стефано не может поправить чужую программу (мою программу, которую помогает мне тестировать).
Ядряра, вам это понятно???

В-третьих, то, что я считаю в своих программах, Ядряру не касается!
Ядряра, вам это понятно???

В-четвёртых, зачем понукать чужую лошадь? Может, надо запрячь свою?

Ядряра, у меня к вам тоже вопрос: что вам мешает считать по вашей высокоэффективной программе???
Летите хоть на звездолёте, как на собственном заду!
(C)

Наконец, в-пятых: г. Петухов считает не просто по высокоэффективной программе (на PARI), а по супер-пупер программе (в 1200 раз быстрее), c апреля 2023 г.
Что-то я не вижу, где 19-ка с минимальным диаметром.
Она уже найдена?
Ядряра, ссылку дайте, пожалуйста!

Ядряра писал

Это потому что PARI — интерпретатор, как и Бэйсик?

Все мои мировые рекорды по магическим и латинским квадратам (внесённые в OEIS) были найдены на Бейсике.
Тормознутость Бейсика ничуть не помешала найти эти рекорды.

Кстати, у Бейсика уже очень давно есть компилятор.

Ну вот и результат у черепашки

(02:34) gp > \r 17pat_test.txt
   log = 1 (on)
   [logfile is "17pat_test_res.txt"]
  ***   Warning: new stack size = 536870912 (512.000 Mbytes).
range of search for 17tuples
1703201466281580673 (p=869501380551409749373230 )
1703201466294241000 (p=869501380557872972910000 )

869501380556932775998001: [114, 120, 126]
869501380556932775997887: [0, 24, 36, 42, 72, 86, 110, 114, 120, 126, 192, 194,
210, 222, 234, 236, 240]
time = 7h, 25min, 20,631 ms.

Сравниваем с результатом - для периода 29#

(16:52) gp > \r 17pat.txt
   logfile = "17pat_res.txt"
  ***   Warning: new stack size = 536870912 (512.000 Mbytes).
range of search for 17tuples
134396075616001 (p=869501380551409749373230 )
134396075617000 (p=869501380557872972910000 )

869501380556932775998001: [114, 120, 126]
869501380556932775997887: [0, 24, 36, 42, 72, 86, 110, 114, 120, 126, 192, 194,
210, 222, 234, 236, 240]
time = 38min, 17,568 ms.

Время выполнения отличается в 11,71 раз.

Таким образом, при поиске ключевых 17-ок программа для периода 29# даёт убыстрение в 11,71 раз по сравнению с программой для периода 17#.

Напомню: об этом убыстрении мне писал читатель темы, о чём написано выше.

Возможно, период 37# даст ещё большее убыстрение, но, как уже выше написано, с этим периодом мне не удалось формулы (которых больше 32 миллионов) записать в рабочую программу.
У читателя для данного периода формул почему-то гораздо меньше, нежели даёт программа gris.
Возможно, он ошибся.

Следовательно, надо учиться хватать формулы "на лету".
А чего учиться? :)
gris говорит, что всё очень просто.
Однако... он пока не экспериментировал с этим хватанием "на лету".
Я понимаю, как это пройдёт для одного периода.
А у нас ведь идёт цикл.
И что, на каждом шагу цикла заново все более 32 миллионов формул хватать "на лету"?
В общем, пока у нас с gris программы для хватания "на лету" нет.

Буду пока крутить программу с периодом 29#.
Но... у меня первоначальная версия программы искала ключевые 17-ки сразу в трёх диапазонах, что достигалось особенностью алгоритма поиска (поиск ключевых 17-ок в 19-ах, 25-ах и 27-ах).
Сейчас тоже сделаю так, чтобы сразу проверялись три диапазона.

То ли ещё будет, ой-ёй-ёй.
(С)

Г. Петухов писал в сообщении
https://dxdy.ru/post1625903.html#p1625903

Глупые именно ответы, не вопросы - как бы не претендую на гуру в асме, но что знаю поделюсь. Если соберётесь с духом/силами. Или может опрос замутить интересно ли это кому-то ещё? Тут-то никто не увидит.

Да чего уж там: валите всё в тему "Симметричные кортежи из последовательных простых чисел" - и Асм, и FASM, и PARI, и кэфы, и расчёты скоростей программ, и про маленький приз в конкурсе, который даже затрат г. Петухова не покрывает, и ошибки в остановленном год назад BOINC-проекте и ...
В теме уже давненько кортежей не видно - с 29 декабря прошлого года, да и те все дырявые.

Вот прошёл проход программы с периодом 29#

(04:18) gp > \r 17pat.txt
   log = 1 (on)
   [logfile is "17pat_res.txt"]
  ***   Warning: new stack size = 536870912 (512.000 Mbytes).
range of search for the first stream
134396075620001 (p=869501380577288522293230 )
134396075621000 (p=869501380583751745830000 )
range of search for the second stream
144396075620001 (p=934198312877288522293230 )
144396075621000 (p=934198312883751745830000 )
range of search for the third stream
154396075620001 (p=998895245177288522293230 )
154396075621000 (p=998895245183751745830000 )

the first stream
the second stream
the third stream
time = 1h, 53min, 45,981 ms.

Решений не найдено ни в одном из трёх диапазонов.
Время хорошее - около двух часов.
Можно крутить дальше.

Стефано сообщил

program is terminated:

[logfile is "17-27tuple_res.txt"]
*** Warning: new stack size = 536870912 (512.000 Mbytes).
range of search for 17tuples
1803201465993400001 (p=920552380404290634510510 )
1803201466000000000 (p=920552380407660000000000 )
range of search for 19tuples
1803201465993400001 (p=17490495227681522055699690 )
1803201466000000000 (p=17490495227745540000000000 )
range of search for 25tuples and 27tuples
1803201465993400001 (p=402281390236675007281092870 )
1803201466000000000 (p=402281390238147420000000000 )

920552380404965706798187: [114, 120, 126]
920552380404965706798073: [0, 6, 10, 18, 78, 88, 108, 114, 120, 126,
154, 156, 196, 220, 226, 238, 240]
402281390237055303386648177: [114, 120, 126]
402281390237055303386648063: [0, 18, 20, 48, 50, 80, 90, 114, 120, 126,
168, 176, 204, 210, 218, 234, 240]
17490495227714211883059667: [114, 120, 126]
17490495227714211883059553: [0, 4, 34, 58, 64, 70, 100, 114, 120, 126,
130, 150, 156, 168, 196, 216, 240]
17490495227715629286847621: [114, 120, 126]
17490495227715629286847507: [0, 6, 16, 22, 46, 66, 90, 114, 120, 126,
136, 144, 154, 156, 214, 226, 240]
920552380407474528878497: [114, 120, 126]
920552380407474528878383: [0, 6, 18, 36, 64, 70, 88, 114, 120, 126, 150,
168, 198, 216, 226, 234, 240]
?

Замечательно!
Пожалуй, самое интересное приближение - последнее

920552380407474528878497: [114, 120, 126]
920552380407474528878383: [0, 6, 18, 36, 64, 70, 88, 114, 120, 126, 150, 168, 198, 216, 226, 234, 240]

Сейчас я его разверну.

Вот
{920552380407474528878383, 920552380407474528878389, *920552380407474528878401, 920552380407474528878419,
*920552380407474528878447, *920552380407474528878453, *920552380407474528878471, 920552380407474528878497,
920552380407474528878503, 920552380407474528878509, 920552380407474528878533, *920552380407474528878551,
*920552380407474528878581, *920552380407474528878599, *920552380407474528878609, 920552380407474528878617,
920552380407474528878623}

Приближение к ключевой 17-ке с 8 "дырками", недалеко от последней известной на данный момент ключевой 17-ки, вот этой

901985248981556228168767: 0 6 24 36 66 84 90 114 120 126 150 156 174 204 216 234 240

(найдена г. Петуховым)