На форум BOINC-проекта SPT забросила вопрос
https://boinc.termit.me/adsl/forum_thread.php?id=72

Вдруг кто-нибудь там в курсе данного вопроса.
Demis в курсе; очень давно он писал многопоточную программу ещё в проекте по ОДЛК, правда, не на PARI/GP.
Но у Demis нет времени :)

Обратилась с просьбой к Максу Алексееву по поводу многопоточной программы..
Он помочь отказался, но прислал ссылки.
Цитирую

По поводу документации: см. https://pari.math.u-bordeaux.fr/dochtml/html/Parallel_programming.html
и главу 2 в https://pari.math.u-bordeaux.fr/pub/pari/manuals/2.13.3/parallel.pdf

Я спросила его, возможно ли в принципе сделать из моей программы многопоточную программу.
Он ответил:

"В принципе" из почти всего можно сделать многопоточную программу, но на все нужно время.

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

Это приближение к центральной 13-ке на периоде 59#

1450341578591278867891: [0, 12, 42, 60, 70, 90, 96, 106, 126, 132, 150, 180, 192]
1450341578591278867891: [0, 0, 0, 0, 4, 0, 0, 4, 0, 0, 0, 0, 0]
1450341578591278867891: [1, 1, 1, 1, 0, 1, 1, 0, 1, 1, 1, 1, 1]
valids=11
code=1903

Интересны отклонения: 4 и 4. Маленькие.

Пока только с низкими valids идут приближения к центральной 13-ке.
Ну, не совсем с низкими, >9.

Вот симпатичное приближение

26675783449634223301: [0, 12, 42, 60, 66, 90, 96, 102, 106, 166, 178, 180, 192]
26675783449634223301: [0, 0, 0, 0, 0, 0, 0, 0, -20, 34, 28, 0, 0]
26675783449634223301: [1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1]
valids=10
code=2033

Прекрасное начало кортежа, три "дырки" рядышком.

Эти два приближения тоже интересные

19772416285630302691: [0, 12, 36, 60, 66, 90, 96, 102, 126, 132, 138, 150, 192]
19772416285630302691: [0, 0, -6, 0, 0, 0, 0, 0, 0, 0, -12, -30, 0]
19772416285630302691: [1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1]
valids=10
code=1532

16943461467375036991: [0, 12, 28, 60, 66, 90, 96, 102, 126, 132, 138, 178, 192]
16943461467375036991: [0, 0, -14, 0, 0, 0, 0, 0, 0, 0, -12, -2, 0]
16943461467375036991: [1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1]
valids=10
code=1532

Приближения (Norm-числа) идут непрерывным потоком!
Много их добавочки дают.

Однако... центральных 13-к пока нет.

Из интересных новых приближений к центральной 15-ке

27239062247498705983: [0, 18, 30, 60, 70, 96, 108, 114, 120, 130, 150, 168, 198, 210, 228]
27239062247498705983: [0, 0, 0, 0, -8, 12, 0, 0, 0, -14, 0, 0, 0, 0, 0]
27239062247498705983: [1, 1, 1, 1, 0, 0, 1, 1, 1, 0, 1, 1, 1, 1, 1]
valids=12
code=7407

Для центральных 13-к нет ничего интересного, хотя Norm-чисел выдалось много за ночь, пять выходных файлов по 10000 Norm-чисел.

Репост

Цитата

Если программу выполнить до конца, все ключевые 17-ки в этом интервале будут найдены.
Но... это тысяча лет :)
Здесь, конечно, не сплошной перебор по всем простым, не пугайтесь :)
Здесь перебор по добавкам.
Но это всё равно очень долго, потому что добавок 1999660772229120000 штук.
Хотя добавки проверяются не все (генерируются, понятно, все), а только находящиеся в заданном интервале
(12*10^23, 7858321551080267055879090).
А сколько добавок находится в заданном интервале - одному Богу известно.

Можно выполнить такой эксперимент.
Сгенерировать N добаок, чтобы набралось, например, 10000 добавок, принадлежащих заданному интервалу.
При этом вывести количество сгенерированных добавок N.
Затем просто пропорционально посчитать, сколько будет добавок, принадлежащих заданному интервалу, среди всех.
Это, конечно, может быть очень приблизительно.
Ну, хотя бы оценочно узнаем.
________________________
конец репоста

Сейчас выполню этот эксперимент для центральных 13-к.

При периоде 53# центральные 13-ки ищутся в интервале
(10013230717641471277; 32589158477190044730).

Количество добавок равно 145544026521600.
Сейчас наберу 10000 добавок, принадлежащих заданному интервалу, и посмотрю сколько при этом всего сгенерируется добавок.

gris пишет

Насчёт распределения добавок внутри периода
Они распределяются по имеющемуся алгоритму очень равномерно и эта равномерность сохраняется на всём продолжении расчёта с небольшими флуктуациями
гистограмма 20 млн добавок по десятым долям периода

37#: [2000212,2000093,1999637,1999985,2000450,1999887,1999616,2000375,2000001,1999744]
53#: [2000067,2000013,1999961,2000063,2000003,1999905,2000027,1999944,2000067,1999950]
73#: [2000116,2000043,1999905,2000016,1999890,2000032,1999967,2000013,2000092,1999926]

То есть количество отбираемых остатков пропорционально длине непрерывного интервала отбора.

Замечательно!
Следовательно пропорциональная экстраполяция будет правильная (если мы правильно друг друга поняли).

Эксперимент выполнила.
10000 добавок, принадлежащих заданному интервалу, набрались при генерации 14436 добавок.
То есть примерно 1:1,5.

А теперь попробую набирать добавки, принадлежащие следующему интервалу
[10013230717641471277, 11000000000000000000).

В этом интервале 10000 добавок набралось при генерации 33066 добавок.
ВотЪ!
При этом 10000 добавок из заданного интервала набираются практически мгновенно

. . . . . . . . 
10207413784312699351
10155082738986019231
10769972521574510641
10102751693659339111
10050420648332658991
10665310430921150401
10560648340267790161
10508317294941110041
330066
time = 2,637 ms.

Ещё тестирую.
Сделала так: генерирую и выбираю 50000 добавок, принадлежащих заданному интервалу.
Проверяю эту порцию добавок сразу на valids (а не на Norm-числа).
Снова генерирую и выбираю 50000 добавок из заданного интервала.
И так далее.

Показываю консоль

0 from number
0 to В  number
[0,12,42,60,66,90,96,102,126,132,150,180,192]
patterns length 13
32589158477190044730 period
search in 0 (0.E-19) - 32589158477190044730 (3.3 E19)
central 3: [90,96,102]
prove by 53#: [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53]
145544026521600 formulae expected
schet=1
1711589

schet=2
3421556

schet=3
5132722

schet=4
6844097
. . . . . . 

Интересненько!
Программа выведет приближения с valids>9.
Пока их не найдено.
schet - это счётчик порций.
При schet=4 выбрано и проверено 50000*4=200000 добавок из заданного интервала.

Обратите внимание на количество сгенерированных добавок на получение 50000 нужных добавок.
Да, примерно пропорционально.

В этом варианте программы ничего уже проверять не надо (Norm-числа на valids), всё в программе проверится.
Также хорошо, что видим количество сгенерированных и проверенных добавок.

Тут у меня укороченный интервал.
Надо запустить такой вариант программы для полного интервала.

Ещё надо попробовать запустить всё это дело с последней проверенной добавки.
Если получится, будет совсем хорошо.

Пока никак не соображу, как это сделать.
Разве что посчитать, сколько до последней проверенной добавки сгенерировано всех добавок.

Тестирую на черепашке.
Интервал полный, набираю по 100000 добавок, принадлежащих интервалу.
Генерация начинается с самого начала.

Жду появления приближений с valids>9.

0 from number
0 to   number
[0,12,42,60,66,90,96,102,126,132,150,180,192]
patterns length 13
32589158477190044730 period
search in 0 (0.E-19) - 32589158477190044730 (3.3 E19)
central 3: [90,96,102]
prove by 53#: [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53]
145544026521600 formulae expected
schet=1
144359
. . . . . . 

Цитата

Эксперимент выполнила.
10000 добавок, принадлежащих заданному интервалу, набрались при генерации 14436 добавок.
То есть примерно 1:1,5.

Да, интересно: на 10000 добавок из интервала потребовалось сгенерировать 14436 добавок, а на 100000 добавок из этого же интервала потребовалось сгенерировать 144359 добавок.
Практически пропорционально.

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

На Ахиллесе-3 уже сгенерировано 34 порции по 50000 добавок

. . . . . 
schet=30
51335356

schet=31
53048064

schet=32
54758092

schet=33
56469954

schet=34
58181115
. . . . . 

На первую порцию было сгенерировано 1711589 добавок.
При строгой пропорциональности получается: 1711589*34 = 58194026.

У меня такое ощущение, что генерация и проверка добавок порциями работает медленнее, чем проверка выбранной добавки на лету.
Может быть, ложное ощущение.

Но пока ни на черепашке, ни на Ахиллесе-3 не появилось ни одного приближения с valids>9.

А версию с проверкой выбранных добавок на лету я тестировала, там вроде бы быстро появилось приближение с valids=10.
Может, забылось время, которое там было до первого приближения.

Так как же всё-таки быстрее: сразу проверять каждую выбранную добавку или набирать порцию добавок и проверять её?

Прервала тестирование на черепашке, на Ахиллесе-3 пока работает.

Запустила на черепашке прежнюю версию - с проверкой каждой выбранной добавки сразу.
Короткий интервал.
Сделала вывод приближений с valids>8.

Посмотрим, когда появится первое приближение.
Ещё вывожу номер добавки, при котором есть приближение с valids>8.

PS. Вот забыла, на каком интервале я в прошлый раз тестировала - на коротком или на длинном.

Ахиллес-3 шпарит

. . . . . . 
schet=76
130058804

schet=77
131767664

schet=78
133478162

schet=79
135192877

schet=80
136902433

Сгенерировано 80 порций по 50000 добавок, все они принадлежат заданному интервалу.
Интервал здесь короткий.
Всего сгенерировано 136902433 добавок.
Это, конечно, очень мало - из 145544026521600.
Программа работает около двух часов.

Пора г. Петухову посчитать, сколько лет моя программа будет работать :)

Необходимо распараллеливание, но с этим глухо.
Никто ничего не знает, а кто знает - не скажет :)

Кстати, про распараллеливание смотрите следующие сообщения.

Макс Алексеев писал в письме

"В принципе" из почти всего можно сделать многопоточную программу, но на все нужно время.

Программу посмотреть он, скорее всего, не удосужился, хотя я его просила посмотреть и сказать, можно ди эту программу распараллелить в принципе.

А вот что ответил Стефану ИИ, которого он спросил по поводу распараллеливания моей программы:

it was a tentative. the AI says that it cannot be parallelized as internal part is dependent of external part of the neested for loops

Далее Стефано продолжает

but then it produced that code (that as it not compile it is wrong :(

Он прислал мне программу, которую ему сделал ИИ, я запустила её, в ней куча ошибок.

А ещё Стефано написал

I see that PARI/GP must be com
piled with multi-thread support. If you have it, try the version of program I send to you.

Но с этой программой у меня тоже ничего не получилось.
Точнее, она запустилась, но я не увидела распараллеливания.
Посмотрела диспетчер задач, там загрузка процессора была всего 16%.

У Стефана нет опыта в распараллеливании.

Но вот то, что он написал, уже вроде бы показывает путь к решению задачи.
"Скомпилировать с поддержкой многопоточности...".
Значит, там есть специальный ключ для этого.

Просила gris задать вопрос на форуме dxdy.ru, но с этим тоже глухо.
На форуме есть wrest, он точно знает, как сделать многопоточный режим в PARI/GP.

Цитата из письма gris

Я не знаю, что там надо распараллеливать. И вылезать с наивными вопросами не стану. Может быть сам посмотрю.

ВотЪ!
Оказывается, он не знает, что надо распараллеливать.
А вы знаете, господа? :)

Распараллелить надо программу, опубликованную здесь
https://boinc.progger.info/odlk/forum_thread.php?id=285&postid=14484

И помнится, я это писала в теме.

И разве вопрос про многопоточность такой уж наивный?
Прямо тривиальность, которую все прекрасно знают. Да?
Ну вот я не знаю, увы.
А gris ведь тоже не знает, хотя уже давно в PARI/GP работает!
Не хочется разве узнать?
Я не могу читать документацию на английском, gris может.
Так почему бы не попробовать?

Ещё предлагала gris GPT попытать о многопоточности.
Это тоже не хочется.
Да и зачем?
Ему ничего распараллеливать не надо.

Я уже забыла ссылку на бесплатный GPT.
Поискать что ли?
Вон Стефано сразу ИИ спросил!
Конечно, толку-то никакого.
Но всё-таки интересно, что он будет отвечать.
Хотя у меня стойкое ощущение, что этот GPT кроме наезженных и хорошо известных вопросов ничего не знает и не умеет.
Я его пытала по одной своей задаче о кортежах, он всю дорогу писал одни ошибки.
(Это, помнится, была задача генерации специальных последовательностей из простых чисел.)
Где-то я публиковала его ответы по этой задаче, там такая ахинея!

Кстати, вот тема на форуме Math Help Planet
https://mathhelpplanet.com/viewtopic.php?f=44&t=80044

Ну, в этой теме мало.
Где-то я больше писала.

Ну вот, вошла по этой ссылке
https://poe.com/GPT-4
Даже зарегистрировалась.
Задала вопрос

Можете ли вы сделать многопоточный вариант программы из однопоточной программы, написанной на PARI/GP?

В ответ получила

You have reached the limit of messages you can send in this chat.

This bot is only available to subscribers.

Какой лимит достигла?
Я задала всего один вопрос!
Везде обман :)

А тем временем тест на черепашке выдал приближения!

(18:41) gp > \r 13porc_53_valids_test.txt
   logfile = "13porc_53_valids_test_res.txt"
0 from number
0 to   number
[0,12,42,60,66,90,96,102,126,132,150,180,192]
patterns length 13
32589158477190044730 period
search in 0 (0.E-19) - 32589158477190044730 (3.3 E19)
central 3: [90,96,102]
prove by 53#: [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53]
145544026521600 formulae expected
10243406473386520831: [0, 12, 40, 60, 66, 78, 96, 102, 108, 132, 172, 180, 192]
valids=9
453947110

10953476282801586931: [0, 36, 42, 60, 66, 70, 90, 102, 126, 132, 138, 180, 192]
valids=9
553432817

Ура!
Всё работает.

Смотрите, до второго приближения сгенерировано 553432817 добавок.
Солидная порция.

Всё-таки эта версия быстрее работает.
Надо проверять добавки сразу.

Прервала тест и на Ахиллесе-3.
Посмотрели на порции выбираемых добавок.

Ещё нашлось приближение к центральной 13-ке с valils=12

516292323033685232431: [0, 12, 36, 60, 66, 90, 96, 102, 126, 132, 150, 180, 192]
516292323033685232431: [0, 0, -6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
516292323033685232431: [1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
valids=12
code=1535

Это на периоде 59#.

Очень интересные результаты выдала новая программа поиска центральных 13-ок в нулевом периоде (для периода 61#).

Показываю консоль работы программы (Ахиллес-3)

break[8]> \r 13porc_61_valids_test.txt
   logfile = "13porc_61_valids_test_res.txt"
0 from number
0 to В  number
[0,12,42,60,66,90,96,102,126,132,150,180,192]
patterns length 13
117288381359406970983270 period
search in 0 (0.E-19) - 117288381359406970983270 (1.2 E23)
central 3: [90,96,102]
prove by 61#: [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61]
321361210559692800 formulae expected
14822866122504877971931: [0, 40, 48, 60, 66, 90, 96, 102, 126, 132, 150, 180, 192]
valids=11
number form=811742382

43408369216417702971871: [0, 12, 48, 60, 66, 90, 96, 102, 126, 148, 166, 180, 192]
valids=10
number form=855091706

9971025156794972194321: [0, 12, 42, 48, 66, 90, 96, 102, 126, 132, 148, 150, 192]
valids=10
number form=1119486387

37483735944286251964741: [0, 12, 46, 60, 78, 90, 96, 102, 126, 148, 150, 180, 192]
valids=10
number form=1362607979
. . . . . . . 

Наконец-то приближения пошли прямо в программе (для valids>9), при этом выводится номер добавки, давшей приближение.

Когда я начинала разработку этого алгоритма, gris воскликнул: "Ого! Счёт пошёл на миллионы!"
А теперь счёт пошёл на миллиарды.
Вот эта добавка 37483735944286251964741 - 1362607979-я.

А всего добавок ну совсем не много :)
321361210559692800 штук.

В этой программе центральная 13-ка ищется в интервале
(1922760350154212639070, 117288381359406970983270)

Солидный интервал.
Если программу выполнить до конца, будут найдены все центральные 13-ки, имеющиеся в этом интервале.
Гарантированно!

Кластер или суперкомпьютер это взял бы.
Один ПК в один поток, конечно, не возьмёт.
Если бы распараллелить программу...