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

[VAL]

EUgeneUS в сообщении #1552791 писал(а):

Но в одном скрипте была опечатка - пропущена запятая. Была быстро найдена путем сравнения с другими тремя

Сие странно
Все программки предварительно запускались. А где не было запятой?

EUgeneUS в сообщении #1552791 писал(а):

4. Остро не хватает возможности перенастроить счет с места останова. Уже был сбой питания, пришлось начать сначала.
5. Так же не хватает какого-то прогресс бара. Например, совершенно не понятно, сколько будет считать каждый скрипт "до конца".

Это взаимосвязанные вопросы. Перезапустить с места останова можно, если перед этим выводился прогресс. А он выводится. Но не часто.
Перенастроить просто. Достаточно в условии "if(ss>12" заменить 12 меньшим числом. Подобрать удобное для себя.
Тогда для перезапуска с места останова начальное значение i1 нужно увеличивать не на шаг (второе слагаемое из следующей строки), а на отработанную долю шага (для удобства округленную вниз).

[Yadryara]

VAL в сообщении #1552790 писал(а):

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

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

Называйте, как хотите. Но эта именно та вероятность, которая нас интересует.

Конечно именно та. И именно её я считал выше. У нас была дискуссия и мне больше нравилось считать именно для попыток, а не для интервала.

И вероятность для одиночных простых(>0.18) порой в 3 раза превышала Вашу. Полагаю, это именно из-за фильтрации на Асме, в ходе которой отсеивались числа делящиеся на простые до 4096.

А вероятность для пары различных простых(0.24) была примерно равна Вашей.

Вероятности для 3-к, 4-к и более различных простых для 12 делителей были не нужны.

[VAL]

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

Вероятности для 3-к, 4-к и более различных простых для 12 делителей были не нужны.

Это для 12 делителей, а для 24 и 48 нужны.

[Dmitriy40]

VAL в сообщении #1552799 писал(а):

EUgeneUS в сообщении #1552791 писал(а):

4. Остро не хватает возможности перенастроить счет с места останова. Уже был сбой питания, пришлось начать сначала.
5. Так же не хватает какого-то прогресс бара. Например, совершенно не понятно, сколько будет считать каждый скрипт "до конца".

Это взаимосвязанные вопросы. Перезапустить с места останова можно, если перед этим выводился прогресс. А он выводится. Но не часто.
Перенастроить просто. Достаточно в условии "if(ss>12" заменить 12 меньшим числом. Подобрать удобное для себя.
Тогда для перезапуска с места останова начальное значение i1 нужно увеличивать не на шаг (второе слагаемое из следующей строки), а на отработанную долю шага (для удобства округленную вниз).

EUgeneUS
А чтобы не морочиться с расчётом доли шага, измените команду

print((i-i1)/(i2-i1)*100.);

примерно в предпоследней строке на команду

printf("%0.2f%%, i=%d\n", (i-i1)/(i2-i1)*100.0,i);

и будет сразу видно по какое i программа уже проверила. И ничего даже складывать/увеличивать не придётся, лишь подставить последнее выведенное значение в i1.
Ну и проценты прогресса будут не длиннющим числом, а культурно.

[Yadryara]

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

Прикину сколько бы так искали пятнашку М12: после проверки $10^{38}/4.4\cdot10^{26}\times46080\approx1.05\cdot10^{16}$ кандидатов

Ещё на первой странице была хотя и грубая, но по порядку верная оценка:

VAL в сообщении #1548034 писал(а):

У меня оценка - $10^{15} - 10^{16}$ цепочек.

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

Для искомой двадцатки я так понимаю никто оценки вероятностей не проводил и ничего озвучивать не собирается ...

Ну вот я тоже спрашивал:

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

VAL в сообщении #1552307 писал(а):

Я же написал, что прогноз по времени обнадеживающий.

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

Думаю, дело в том, что довольно сложно провести такой расчёт.

Я ещё не все вопросы с 12-ю делителями решил, поэтому переходить к другим расчётам пока не буду.

Кстати, формула вероятности для любой 14-ки тоже ведь получается не сильно сложная:

$$11\cdot Y_1^{10}Y_2^4(1-Y_1) + 4\cdot Y_1^{11}Y_2^3(1-Y_2)$$

Для 0-4е35 взял $Y_1=0.200; Y_2=0.246$. И Альфа даёт среднюю частотность любой 14-ки:
одна на 237 миллионов попыток

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

Поражён что 14-ка встретилась так рано.

Действительно весьма рано. Всего лишь после 74 миллионов попыток. Даже раньше чем 1-я 13-ка.

[VAL]

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

Думаю, дело в том, что довольно сложно провести такой расчёт.

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

[Dmitriy40]

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

Надо бы всё-таки проверить, сможет ли Асм и здесь помочь.

Ускорение незначительно, всего раз в 6: время просчёта одинакового диапазона снизилось с 1ч33м до 15м7с, из последних моя программа заняла примерно минуту, остальное PARI с его медленной факторизацией. И это несмотря на фильтрацию 63:1 моей программой.

VAL
Можно ускорить почти вдвое процентов на 15 если перед циклом факториазции до 3млн сделать ровно такой же цикл факторизации до 10тыс, даже не делая дофакторизацию во второй раз лишь остатка от первого.

[EUgeneUS]

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

Ускорение незначительно, всего раз в 6: время просчёта одинакового диапазона снизилось с 1ч33м до 15м7с, из последних моя программа заняла примерно минуту, остальное PARI с его медленной факторизацией. И это несмотря на фильтрацию 63:1 моей программой.

В 6 раз это уже более чем на полпорядка

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

А чтобы не морочиться с расчётом доли шага, измените команду

Спасибо! Теперь стало понятно и наглядно, как запускать после останова. Кстати, уже был второй "неплановый останов", и запланирован минимум один плановый.

VAL в сообщении #1552799 писал(а):

Достаточно в условии "if(ss>12" заменить 12 меньшим числом. Подобрать удобное для себя.

Спасибо!
Заменил на 8. Стали появляться цепочки от 12.
Предварительная оценка времени счета по заданному в программах диапазоне - 7-8.5 дней.

Под катом измененные строки

(Оффтоп)

Строки из изначального скрипта приведены в комментариях.
Ещё вывожу в лог ID-программы (скрипта) по окончанию счета.

\\! if(f3, E=[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];ss=0;t=t+1; for(j=1,17,if(numdiv(n+uu[j])==48,E[j]=1;ss=ss+1)); F=F+E; s=s+ss;if(ss>12,
if(f3, E=[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];ss=0;t=t+1; for(j=1,17,if(numdiv(n+uu[j])==48,E[j]=1;ss=ss+1)); F=F+E; s=s+ss;if(ss>8,
\\! print((i-i1)/(i2-i1)*100.); t1=t1+1;if(ss==17,print(n," YES!!! ");break); print(n);print("# ",E," ",ss+3)))))))));
printf("%0.2f%%, i=%d\n", (i-i1)/(i2-i1)*100.0,i); t1=t1+1;if(ss==17,print(n," YES!!! ");break); print(n);print("# ",E," ",ss+3)))))))));
\\! print(s," ",s1," ",t," ",t1);print(F)};"3_0_12_I___2-24"
print(s," ",s1," ",t," ",t1);print(F)};print("3_0_12_I___2-24");"3_0_12_I___2-24"

-- 17.04.2022, 20:56 --

VAL в сообщении #1552799 писал(а):

Все программки предварительно запускались. А где не было запятой?

(Оффтоп)

В четвертом "блоке" (в четвертой программе) вот в этой строке:

f1=1; for(j=1,17 if(ispseudoprime((n+uu[j])/MM[j]),f1=0;break));

после "17" не было запятой. Наверное, на почте украли при копипастах потерялась.

[EUgeneUS]

EUgeneUS в сообщении #1552856 писал(а):

Предварительная оценка времени счета по заданному в программах диапазоне - 7-8.5 дней.

Уточненная оценка по времени - около 5 дней.
Но с "урожайностью" всё так же грустно. За половину суток на четыре потока:
16-к - две или три.
17-к - две.
18-к и 19-к - ниодной.

[VAL]

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

Можно ускорить почти вдвое процентов на 15 если перед циклом факториазции до 3млн сделать ровно такой же цикл факторизации до 10тыс, даже не делая дофакторизацию во второй раз лишь остатка от первого.

Гм... Подбирая этот параметр, я проверил 10 миллионов, 3 миллиона и 1 миллион. 10 миллионов оказалось намного медленнее, а 3 и 1 сработали почти одновременно. Впрочем, возможно, я взял слишком маленький диапазон.

[Yadryara]

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

Ускорение незначительно, всего раз в 6

О, как! Шестикратное ускорение уже незначительно!?

В разы, как я и говорил. Чем плохо пересесть с кареты на гоночный болид?

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

И потому я продолжаю агитировать за подсчёт статистики только по ALL цепочкам. Ведь много (в несколько раз!) цепочек без ALL мы очевидно упустили.

Тут штука в том, что не только олловские цепочки правильно считаются, но и, например, непрерывные 14-ки.

А чтобы любые 14-ки правильно считались надо большой иф убирать. Чего не хочется делать, чтобы ещё сильнее не снижать и так маленькую скорость обсчёта.

[kotenok gav]

VAL в сообщении #1552790 писал(а):

Я Вам и без запуска скажу. Одна программа нагрузит процессор на $\frac{100}n\%$, где $n$ - количество логических ядер.

Если это так, то... это как-то уж слишком расточительно выполнять одну программу в одном PARI/GP потоке.

[Dmitriy40]

VAL
Я взял для теста $10^7$ значений i начиная с $46\cdot10^6$ (потому что там есть цепочка с ss=9, проходящая даже фильтр с 30млн, а основные тормоза как раз из-за numdiv на вероятных цепочках), для значений параметра 30млн, 10млн, 3млн, 1млн, 300тыс, 100тыс, 30тыс, 10тыс, 3тыс получились времена (везде с округлением до секунд):
104с, 70с, 57с, 54с, 55с, 59с, 64с, 71с, 86с (жирным - текущее значение).
Как прекрасно видно при ухудшении фильтрации в factor тормозить начинает numdiv. И текущее значение близко к оптимальному для одного фильтра.
А теперь те же варианты (без последних двух, только по 30тыс), но с предварительным циклом до 10тыс:
55с, 52с, 51с, 51с, 54с, 59с, 64с.
И теперь варианты размера предварительного фильтра 10млн, 3млн, 1млн, 300тыс, 100тыс, 30тыс, 10тыс, 3тыс, 1тыс при постоянном размере основного в 30млн:
70с, 58с, 54с, 53с, 54с, 54с, 55с, 57с, 63с.
Т.е. достаточно много вариантов отсекается даже относительно плохими но быстрыми фильтрами. А остальное можно допроверить и большим и не слишком тормозным. И оптимальной будет комбинация 10тыс плюс 10-3-1млн, дающая времена 52-51-51с (я бы взял большее значение в расчёте на увеличение чисел при счёте).

PS. Почти вдвое у меня время уменьшалось в другой программе, с ускорителем, с 15с на круг до 8с, это я перепутал.
PPS. Кстати статистика по фильтрации моей программой: на том же интервале 46-56e6 программа вернула в PARI 157180 цепочки, из них проверку на простоту трёх проверяемых чисел прошли 953, после проверок по MM[] осталось 258, после первого factor(,1e4) осталось 19, после второго factor(,3e6) осталась 1, numdiv она прошла. Время работы 6.4с, (вместо 51с без ускорителя), из которых на мою программу пришлось 0.7с, даже 8х получилось, но это интервал маленький, на больших чуть упадёт. Если первый factor(,1e4) убрать, то время станет 10с.

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

О, как! Шестикратное ускорение уже незначительно!?

По сравнению с тысячекратным — да.

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

Тут штука в том, что не только олловские цепочки правильно считаются, но и, например, непрерывные 14-ки.
А чтобы любые 14-ки правильно считались надо большой иф убирать. Чего не хочется делать, чтобы ещё сильнее не снижать и так маленькую скорость обсчёта.

Нет, часть непрерывных 14-ок мы упустили потому что они не дали в проверяемом месте ровно 12 делителей меньше порога проверки простых в моей программе (но дали в непроверяемом месте). Я же про это уже говорил, когда первая такая нашлась (которую тоже должны были упустить).
И дело не только в большом if, а и в фильтрации моей программой. Для их нахождения надо вообще никак не проверять концы в моей программе, т.е. уменьшать количество проверяемых чисел до 10 (к счастью удаление 45 на шаг паттернов не влияет), убирать их проверку в if и оставлять их проверку только уже в numdiv.

EUgeneUS в сообщении #1552856 писал(а):

В 6 раз это уже более чем на полпорядка

Ну, полпорядка это всё же $\sqrt{10}\approx3.2$, а тут вдвое больше, так что $\lg{6}\approx0.8$ порядка.

[EUgeneUS]

kotenok gav в сообщении #1552920 писал(а):

как-то уж слишком расточительно выполнять одну программу в одном PARI/GP потоке

В каком смысле "расточительно"?

[Yadryara]

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

Нет, часть непрерывных 14-ок мы упустили потому что они не дали в проверяемом месте ровно 12 делителей меньше порога проверки простых в моей программе (но дали в непроверяемом месте).

Что означает слово "нет"? Вы спорите с тем утверждением, которого я не делал? Разве я говорил, что все непрерывные 14-ки находятся? Нет, я говорил, что они правильно считаются.

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

Тут штука в том, что не только олловские цепочки правильно считаются, но и, например, непрерывные 14-ки.

Правильно считаются по сравнению с вероятностью, которая считается уже после фильтрации Вашей прогой.

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

Таким образом одна непрерывная 14-ка на 3 миллиарда попыток должна подтвердиться статистикой, а вот одна любая 14-ка на 237 миллионов попыток находиться не будет, а будет встречаться реже.

А то, что для ловли именно 14-к нужна другая прога давно понятно.