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

[Yadryara]

Выяснив вроде всё что надо по 9-кам, я посчитал кое-что по 11-кам:

  Pattern   Naideno  Diapazon         Time
  11-132-1   0 kort.    0-37#     68   min
  11-132-2   2 kort.    0-37#        
  11-144-1   2 kort.    0-37#        
  11-144-2   2 kort.    0-37#        
  11-144-3   2 kort.    0-37#        
  11-144-4   3 kort.    0-37#     72   min   

  11-132-1  31 kort.    0-41#     
  11-132-2  37 kort.    0-41#        
  11-144-1  48 kort.    0-41#        
  11-144-2  19 kort.    0-41#        
  11-144-3  23 kort.    0-41#        
  11-144-4  26 kort.    0-41#    

Видимо, можно по Базе подобрать такой паттерн для которого нашлось 11 кортежей до 41#. Но, чтобы сравнивать время это надо старым способом обсчитать 0-41# за 40+ часов. Неохота.

А почему 11? Потому что прогноз (матожидание) по HL-1 почти 11:

  Паттерн   Прогноз   Диапазон
   19-252   11 kort.     0-71#

[Dmitriy40]

А у меня результаты по 9-108 ровно обратные (на 37#):

Проход от чистых:
17#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 50, 156, 388, 320, 98, 10], sum=1024
9+9+464623: time 6,304 ms
9+9+45779: time 6,394 ms
9+10+314473:1684732833943: [   0,  18,  24,  48,  54,  60,  84,  90, 108], len=9, valids=9, nn=4941982
Проход от грязных:
17#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 50, 156, 388, 320, 98, 10], sum=1024
9+15+169903: time 6,062 ms
9+15+24043:71200853743: [   0,  18,  24,  48,  54,  60,  84,  90, 108], len=9, valids=9, nn=3130834

От грязных до обнаружения решения проверено в полтора раза меньше кортежей.

То же на 31#:

Проход от чистых:
17#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 50, 156, 388, 320, 98, 10], sum=1024
9+9+464623: time 209 ms
9+9+45779: time 211 ms
...
9+11+320473:3905211463: [   0,  18,  24,  48,  54,  60,  84,  90, 108], len=9, valids=9, nn=5382151
Проход от грязных:
17#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 50, 156, 388, 320, 98, 10], sum=1024
9+15+169903: time 211 ms
9+15+24043:71200853743: [   0,  18,  24,  48,  54,  60,  84,  90, 108], len=9, valids=9, nn=111816

Разница вообще в 48 раз в пользу грязных.

Да, я проверял лишь до первого найденного, а не до 6 или 4 или 11.

[Yadryara]

Dmitriy40, но Вы прогу-то не показываете. Как её оценить?

[Dmitriy40]

А для 11-168 на 41# выгоднее от чистых идти:

23#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 64, 486, 2244, 7574, 14018, 14996, 10076, 3674, 606, 22], sum=53760
11+14+115493263: time 944 ms
...
11+14+197920439: time 952 ms
11+14+21794489:52645923442829: [   0,  30,  48,  54,  78,  84,  90, 114, 120, 138, 168], len=11, valids=11, nn=14382564

Проход от грязных перебрал последние две группы (а это больше 176млн кортежей) и решения не нашёл.

(Прога)

v=[0,30,48,54,78,84,90,114,120,138,168];
t0=getwalltime(); pdiv=23; pend=41;
m=vector(pdiv,i,[]); am=vector(#m,i,[]); a=setminus(vector(v[#v]/2,i,i*2),v); all3=vecprod(primes([2,#m]));
{forprime(p=2,#m,
   m[p]=setminus(vector(p,i,i-1),Set(-v%p));
   am[p]=vector(p-1,i,fromdigits(Vecrev(apply(t->(t+i)%p>0,a)),2));
);}
{Iterate(p,b,x0)=my(j,bb,kk,xx);
   for(j=1,#m[p],
      bb=bitand(b,am[p][m[p][j]]);
      kk=hammingweight(bb);
      xx=chinese(x0,Mod(m[p][j],p));
      if(p<#m,
         Iterate(nextprime(p+1),bb,xx);
      ,
         mapput(nums[kk],lift(xx),0);
      );
   );
}
{nums=vector(99,i,Map());
Iterate(3, 2^#a-1, Mod(1,2));
n=#nums; while(n>0&&#nums[n]==0,n--); print1(#m,"#: [0"); s=0; for(k=1,n, print1(", ",t=#nums[k];s+=t;t);); print("], sum=",s);
m=vector(pend,i,[]); am=vector(#m,i,[]); pr=primes([pdiv+1,#m]); nn=0;
forprime(p=2,#m, m[p]=setminus(vector(p,i,i-1),Set(-v%p)); );
forstep(kk=1,#nums,1, foreach(nums[kk],xx, x3=xx[1][1];
   t1=getwalltime();
   forvec(iv=vector(#pr,i,[1,#m[pr[i]]]), nn++;
      x=lift(chinese(concat([Mod(x3,all3)],vector(#iv,i,Mod(m[pr[i]][iv[i]],pr[i])))));
      if(!ispseudoprime(x) || !ispseudoprime(x+v[#v]), next);
      foreach(v,d, if(!ispseudoprime(x+d), next(2)); );
      vv=primes([x,x+v[#v]]); if(#vv<#v, next);
      vv=vv-vector(#vv,i,x);
      zz=Set(concat(vv,v));
      z=vector(#zz,i,if(!setsearch(v,zz[i]),-1,!setsearch(vv,zz[i]),+1,0));
      wi=zz; for(i=1,#wi, wi[i]=strprintf("%4s",concat(if(z[i]<0,"-",z[i]>0,"+",""),wi[i]));); k=#select(t->(t==0),z);
      w=strprintf("%u+%u+%u:%u: [%s], len=%d, valids=%d, nn=%d",#v,kk,x3,x,strjoin(wi,","),#vv,k,nn); print(w); if(#vv==#v, break);
   );
   t3=getwalltime();
   print(#v,"+",kk,"+",x3,": time ",strtime(t3-t1));
   if(#vv==#v, quit);
));
quit;}

[Yadryara]

Спасибо, посмотрю. Это у Вас 11-168-10, там 19 kort. в 0-41#. Лучше 11-168-2, там 13 кортежей. Паттерн с 11-ю штуками пока не нашёл.

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

[Dmitriy40]

А вот ожидаемые объёмы для 13-192. Делим на группы 29#:
29#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 12, 296, 2268, 8936, 25320, 49888, 69616, 68268, 44698, 19892, 5218, 500], sum=294912
До 47# известно 27 кортежей в группах:
29#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 6, 3, 7, 6, 3, 1], sum=27
А значит до нахождения левого надо проверить как минимум полностью группы 13+13, 13+14, 13+15, в которых суммарно 12+296+2268=2576 вариантов, а до нахождения правого кортежа надо проверить как минимум группы 13+23, 13+24, в которых суммарно 5218+500=5718 вариантов. От чистых выгоднее. Это если повезёт и кортеж будет прямо первым в своей группе.
Если не повезёт и придётся проверить примерно половину группы с кортежем, то с чистых придётся проверить 2576+8936/2=7044, с грязных 5718+19892/2=15664. И тоже выгоднее с чистых.

Как-то не прослеживается строгой зависимости от порядка обхода.

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

Это у Вас 11-168-10, там 19 kort. в 0-41#. Лучше 11-168-2, там 13 кортежей.

Я брал строго внутренности 19-252, они более интересны.

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

Смотреть только первый кортеж это очень ненадежно.

Согласен. Однако ищу то 19-252 я именно так!

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

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

Так как мы не знаем распределения чистых 19-252 по группам (пока ни одного не нашли), то лучше не искать реальные кортежи, а лишь оценивать их вероятность (какую долю от общего количества кортежей придётся в среднем проверить) по делению на группы, как вон я чуть выше с 13-192. Это считается быстро (всего лишь деление на группы и всё, сами кортежи искать в группах не надо). И да, на десятках-сотнях вариантов паттернов.
И наверное отдельно проверить зависит ли оно от деления на группы

[Yadryara]

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

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

13 секунд на кортеж! Это вам не 36 секунд старым способом.

По Вашей проге, идя от чистых, первый чистый кортеж 9-108 нашёлся аж за 86 секунд.

По Вашей проге 1-й кортеж для 11-168-10 искался у меня 4 минуты, а 1-й кортеж для 11-168-2 по Вашей же проге — 7 часов. Вот и делай после такого выводы по одному кортежу.

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

И тоже выгоднее с чистых.

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

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

9+9+464623: time 209 ms
9+9+45779: time 211 ms

У меня комп то же самое считал чуть ли не в 5 раз медленнее:

9+9+464623: time 976 ms
9+9+45779: time 1,055 ms

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

И наверное отдельно проверить зависит ли оно от деления на группы

Ну так я проверял. Для 9-108 делил от 11# до 23#. 17# оказался выгоднее всего. А ведь есть ещё экзотические способы деления типа Вашего 29#/17.

[Yadryara]

Да, медленно у меня работает Ваша прога. Моя прога старым способом сделала тотальную проверку (по всему диапазону) за 9.5 минут и нашла все 16 кортежей:

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

  Pattern   Naideno  Diapazon        Time
...
   9-108    16 kort.    0-31#     25.0 min     setsearch   9.5 min

Ваша прога, если убрать стоп после 1-го кортежа, отработала за 16 минут. В среднем по минуте тратила на кортеж. Почему так медленно?

Прикинул: полная отработка 11-168-2 в 0-41# по Вашей проге должна занять у меня не меньше 74 часов.

[Dmitriy40]

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

Почему так медленно?

Ну разве это медленно, 16мин против 9.5мин? Я уж испугался думал в десятки раз разница.
А причины ... У меня внутри цикла forvec делается concat, который весьма тормозной, уже он легко может дать такой проигрыш. Далее, во второй Вашей проге перед проверкой на простоту делается setsearch, который существенно быстрее и отбрасывает много неподходящих вариантов. Плюс у Вас цепочка nextprime, а у меня primes, первая обрывается намного раньше, у меня же выполняется до конца и лишь потом анализируется сколько там оказалось простых.
Короче я просто не заботился о скорости (за исключением добавления проверки по ispseudoprime, уже ускорившей в несколько раз, паразитным эффектом которой стало всегда правильное valids), так что не удивился бы проигрышу и в разы.
Хотя проверил, setsearch улучшила время незначительно, с 51с до 47с на группу (для 13-192). Это под x64, зато под x32 улучшение кратно, с 147с до 57с, почти догнало x64.

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

У меня комп то же самое считал чуть ли не в 5 раз медленнее:

А вот тут почти наверняка половина разницы из-за x64 против x32, всё же работа с длинными числами на x64 ощутимо быстрее. Например 9-108 у меня выполняется за 212мс на группу под gp64 против 555мс под gp32 (а 13-192 за 51с против 147с). Где ещё почти двухкратная разница я не очень уверен, но в общем не удивительно.

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

А ведь есть ещё экзотические способы деления типа Вашего 29#/17.

Они по необходимости, ради упрощения кода (и соответственно ускорения) и сокращения его размера. Есть большая разница оперировать с 64-битными числами (как результатом умножения 32х32) в одном регистре процессора (и одной командой) или с 128-битными (после умножения 64х64), второе заметно медленнее, потому 128-битный результат получается лишь последней операцией (что как раз несложно), но тогда во внутреннем цикле требуется чтобы общий объём перебираемых простых (праймориал) не превышал $2^{32}$ (заодно это вдвое сокращает размер таблицы длиной десяток тысяч элементов) и в то же чтобы время внутренний цикл перебирал не слишком мало вариантов (десяток-два тысяч), иначе возрастёт доля накладных расходов. Вот и получается что приходится 17 (или 13 или 11) перекидывать во внутренний цикл. Какое будет деление на группы для 71# я кстати пока вообще без понятия, там какжется финта с 17 не хватает и придётся выдумывать что-то ещё.

[Yadryara]

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

Моя прога старым способом сделала тотальную проверку (по всему диапазону) за 9.5 минут и нашла все 16 кортежей:

Да, забыл сказать. Моя новая прога ту же тотальную проверку сделала заметно быстрее — за 6.5 минут. 24 секунды на кортеж. И я не разобрался почему.

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

Да, и много чего ещё не понимает. Как ту же теорию вероятностей, даже азы, очень умильно смотреть как "Петухов же обещал найти 19-252 за полгода (или до 1e24), а воз и ныне там" и похожие её высказывания.

Тут возможно дело в сознательном искажении Ваших и моих слов.

Самое главное, что по коротким цепочкам длиной 17 и меньше, теперь можно полностью посчитать прогноз по HL-1 для чистых. Не по моему или Вашему мнению, не на кофейной гуще, а по формулам Харди и Литтлвуда, уважаемых математиков.

Бери программы, да считай какие хочешь кортежи, не длиннее 19-ти.

Нет, надо зачем-то дважды перепутать. Прогноз в 20 штук, который сделан для чистых для 0-61#, отнести ко всем для 67#.

Повторяю, здесь все прогнозы именно по чистым кортежам :

  Паттерн     Прогноз   Диапазон
  17-240-1   20 kort.     0-61#
  17-240-1  300 kort.     0-67#

  19-252     11 kort.     0-71#

Это округлённо.

А количества всех (и грязных и чистых) в 10-20 раз больше. Их легко посчитать.

[Dmitriy40]

Вчера утром нашлась первая центральная 15-ка, в более грязных группах:
19+29:3572117310161407414070591: [ +0, -2, 6, 12, 30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222, 240,+246, 252], len=18, valids=17
На текущий момент обработано 1754 варианта из 13824 или 12.688%, 902 в более чистых и 852 в более грязных.
Центральных 13-ек найдено 16шт, из них по прежнему 2шт с другим паттерном, 8шт в более чистых и 8шт в более грязных группах.
Цепочек с valids=18 найдено 33шт, из них 13шт в более чистых группах и 20шт в более грязных. Распределение их по группам:
29#/17: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6, 7, 0, 0, 0, 0, 9, 8, 2, 0, 1], sum=33
67#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 2, 4, 2, 4, 5, 3, 4, 3, 2, 2], sum=33
Цепочек с len=19 и правильными концами найдено 23096шт. Распределение их по valids=7..18: [2, 31, 255, 1002, 2677, 5010, 6164, 4842, 2357, 660, 89, 7] (представляете как знатно мог бы заспамить тему показывая даже только их с valids от 13 и выше? ). Распределение их по группам:
29#/17: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 18, 368, 1895, 4555, 0, 0, 0, 0, 6899, 6949, 1830, 518, 64], sum=23096
67#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 6, 36, 157, 443, 993, 1455, 1899, 2241, 2829, 3606, 3854, 2863, 1706, 741, 225, 35, 6], sum=23096
Единственная цепочка из группы 19+11 для 67#:
19+23:2663651169256372061953007: [ 0, 6, 12, +30, +42, 72, -86, 90, -92, 96,-110, 120,+126, 132, 156, 162, 180, 210, 222, 240, 246, 252], len=19, valids=16
Распределение только 7шт valids=18 из них по группам:
29#/17: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 2, 0, 0, 0, 0, 1, 1], sum=7
67#: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1, 1, 1, 1, 0, 1], sum=7
Вот тут (в группах 29#/17) я явно вижу преимущество перебора от чистых.
Всего в логи размером 125МБ записано 667628 цепочек с len не меньше 17. Более чистые группы дают в среднем вдвое меньше цепочек чем более грязные.

Расчётное время нахождения второй известной грязной 19-ки (найденной в начале августа), 1.79e24 - конец месяца, числа 29-30. Первой, 1.3e24, найденной старой программой - сильно позже, месяцев через 5.

Вчера придумал как легко исключить посчитанные другим способом в августе 6.15%, но решил не делать, пусть считает всё, экономия пары недель из 9 месяцев не кажется существенной.

[Yadryara]

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

Разве что вот здесь:

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

Распределение только 7шт valids=18 из них по группам:

Это не просто valids=18, а именно дро, то есть len=19? Просто с valids=18, видимо намного больше.

-- 23.09.2024, 16:16 --

Так и есть, с valids=18 33 штуки.

[Dmitriy40]

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

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

Дык два компа, один существенно медленнее (основной рабочий, раз в 5), вот и удобнее идти не пересекаясь, с разных сторон.

[Dmitriy40]

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

Вот подтвердить минимальность известной 17-240-1 - полезно, мне по оценке на это хватило бы недели старой программой, собственно прикину ещё раз: перебрать надо 59# (реально половину, но мне теперь проще весь), в нём 9e14 вариантов, с моей скоростью 1e10/с (для новой программы с КТО) хватит типа суток что ли ... И полтора месяца на 61#, в котором должно быть в 5 раз больше этих цепочек (штук 30) чем известные 6шт до 2e22. Неделю на это жалко, а вот сутки ... Если вспомню как поправить программу под 17-240-1 (с наскока почему-то не получилось, уже пробовал, один из 4-х тестов в проге ошибается (настолько он хитро оптимизирован под 19-252), а без него скорость заметно падает, раза в 2 кажется), то может и посчитаю. Но 59#, не дальше, недель на это жалко.

Вчера дошли руки таки найти тот странный баг в программе, оказалось он не в самом тесте, а в инициализации таблиц для него, слишком переоптимизировал вычисление и одна из констант стала неявной, вот про неё и забыл когда правил код из 19-252 к 17-240 (и соответственно в программе поиска 19-252 бага точно нет, чего опасался). После исправления скорость вернулась к нормальной (1e10 вариантов/с), так что запустил счёт 17-240 (которая центральная в 19-252) по всему 59#, хватило 27ч.
Самое главное: кроме одной известной других 17-240 не нашёл, что можно считать подтверждением её минимальности.
Плюс нашёл все грязные 17-240 во всём 59#, их оказалось 13шт (кроме одной чистой), из них 1шт до 1e20 и 7шт до 1e21 (и чистой). Покажу все 14шт найденных цепочек с valids=17 (и чистую и грязные):
89207733312741151327: [ 0, -4, 6, 24, 36, 66, 84, 90,-112, 114, 120, 126, 150, 156, 174,-192, 204, 216, 234, 240], len=20, valids=17
205467410125360332883: [ 0, 6, 24, 36, 66, 84, 90, 114, 120, 126,-136, 150, 156, 174, 204, 216, 234, 240], len=18, valids=17
348413329032411643373: [ 0, 6, 24, 36, -38, 66, 84, 90, 114, 120, 126, 150, 156, 174,-176, 204, 216,-224,-228, 234, 240], len=21, valids=17
499329670718617444247: [ 0, 6, 24, 36, 66, 84, 90, 114, 120, 126,-146, 150, 156,-170, 174, 204, 216, 234, 240], len=19, valids=17
685422702762503426093: [ 0, 6, 24, 36, -44, -48, 66, 84, -86, 90, 114, 120, 126, 150, 156, 174, 204, 216, 234, 240], len=20, valids=17
874900086586172867047: [ 0, 6, 24, -34, 36, 66, 84, 90, 114, 120, 126, 150, 156, 174, 204,-210, 216, 234, 240], len=19, valids=17
972196171597793081873: [ 0, 6, -14, 24, 36, 66, 84, 90, 114, 120, 126, 150, 156, 174,-180, 204, 216, 234, 240], len=19, valids=17
1006882292528806742267: [ 0, 6, 24, 36, 66, 84, 90, 114, 120, 126, 150, 156, 174, 204, 216, 234, 240], len=17, valids=17, FOUND! - чистая
1104148931136722879627: [ 0, 6, -14, 24, 36, -62, 66, -72, 84, 90, 114,-116, 120, 126,-134,-140, 150, 156,-170, 174, 204, 216, 234, 240], len=24, valids=17
1142044379075513777537: [ 0, 6, 24, 36, 66, 84, 90, -92, 114, 120, 126, 150, 156, 174,-176,-200, 204, 216, 234, 240], len=20, valids=17
1144356700228770973163: [ 0, 6, 24, 36, 66, 84, 90, 114, 120, 126, 150, 156, 174,-176, 204, 216, 234, 240], len=18, valids=17
1149386702406793224047: [ 0, 6, 24, 36, 66, 84, -86, 90, 114, 120, 126,-134, 150, 156, 174, 204,-212, 216, 234, 240], len=20, valids=17
1275845677741545820583: [ 0, 6, -20, 24, 36, -48, 66, 84, 90, -98, 114, 120, 126, 150, 156, 174, 204, 216,-218, 234, 240], len=21, valids=17
1476534327408014082427: [ 0, 6, 24, 36, -52, 66, 84, 90, 114, 120, 126, 150, 156, 174, 204, 216, 234, 240], len=18, valids=17

[Dmitriy40]

В поиске 19-252 вчера и в четверг соответственно найдены (увидел лишь сегодня) две любопытные цепочки:
5873312400086380609606073: [0, 6, 36, 66, 84, 90, 114, 120, 126, 150, 156, 174, 204, 234, 240], n=15 (из 5873312400086380609606067: [ 0, -2, 6, 12, +30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210,+222, 240, 246,+252], len=17, valids=16)
6871322941282233102995147: [ 0, 6, 12, +30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210,+222, 240, 246, 252], len=17, valids=17 (тут даже пропуски симметричны)
К сожалению обе они не являются центральными в 19-252 так как имеют другие паттерны.

После 23.09 найдены и 5шт valids=18 (4шт из них в более чистых), мне понравилась такая:
1777440589720579757739587: [ 0, 6, 12, 30, 42, 72, 90, 96,+120, 126, 132, 156, 162, 180,-194, 210, 222, 240, 246, 252], len=19, valids=18

Все три показанные цепочки в группе 19+24 в 29#/17, в ней осталось досчитать 25 вариантов, сегодня ночью все 4 более чистых группы закончатся и начнётся группа 19+25 с 1896 вариантами.

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

Расчётное время нахождения второй известной грязной 19-ки (найденной в начале августа), 1.79e24 - конец месяца, числа 29-30.

А вот здесь я где-то просчитался, нужно ещё дней 6 до неё, к следующим выходным (она будет в 1371-м варианте, а сейчас проверен 1125-й вариант, при скорости на втором компе 44 вариантов в сутки).