Интервал 7-8e72 просчитался, в облако выложен (файл Result.7e72.txt), из интересного покажу:
R4-18:7167910031037162499395767027887812111634507532942253205117495203306779897: 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 1, 1, valids=11+0, maxlen=11, ALL
R3-15:7391364337011446683116201940001175898293700141046213537433668685372328697: 1, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 72, valids=11+0, maxlen=11, ALL
L5-03:7472486235320208974406418076964688737817897278084328007277230419379287291: 1, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, valids=12+0, maxlen=12, ALL, FOUND!!!
L3-20:7694524087471394886160550667561718786030502558372759479877211756152791291: 1, 1, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, valids=11+0, maxlen=11, ALL
EUgeneUSОценка по одному кругу может быть не слишком точна, в зависимости от попавшихся плохо разложимых цепочек время может плавать процентов на 30, это победить не удаётся. Немного уменьшить этот разброс можно отказавшись от полного разложения цепочек valids=11 изменив цифру 11 на скажем 12 в 48-й строке "
if(k0>0 && k0+k>=11, \\Вероятные 13-ки и 12-ки и 11-ки проверим до упора".
Или можно вообще отказаться от доразложения цепочек, не дающих ровно 11шт по 36 делителей в центре (необходимое условие для 12-ки и 13-ки), заменив условие в той же строке на такое: "
if(k0>0 && #select(x->(x==0 || x==36),s[2..12])==11,". Для тестового круга 1e68 это уменьшает время на те же 8%, что и отказ от допроверки непроверяемых мест вообще (см. ниже).
Например у меня круг 1e70 в 95% занимает где-то 6200с±200с, но несколько раз на 100e70 встретились времена больше 8500с и раз 7 больше 7500с (точнее не знаю, у меня круги по другому считаются, хотя и того же размера).
Совет: объединить статистику в один файл с правильной сортировкой по возрастанию чисел можно командой "
type file1 file2 file3 file4 | findstr "maxlen" | sort /+6 > Result". Файлы указать свои, в любом порядке, выходной тоже любой. Запускать в отдельном окне консоли в папке с логами, можно и при работающем счёте. Правильно работает только для интервалов с одинаковой длиной чисел (например для всех 1-10e72, но не для 0-2e72 и не для 9-11e72, почему в частности и удобно делить статистику по диапазонам).
VALЯ не думаю что факторизация станет ограничивающим фактором для M36n15, ведь в 99% случаев достаточно частичной факторизации,
точно не дающей ни n14 ни n15, а таковая проводится за доли секунды на каждое место, хоть для
, хоть для
. Ну а сколько займёт полная факторизация кандидатов в решения не столь важно, их всего несколько десятков на недели счёта будет (можно будет ещё оптимизировать условия для полного разложения, я просто морочиться пока не стал).
-- 24.04.2022, 16:31 --Предложение - даже не пытаться раскладывать явно бракованные цепочки (которые не дадут 12 или 13). То есть: если получаем единицу не в последней или первой позиции, то сразу бросаем и переходим к следующей.
Такой вариант рассматривался, ради поиска лишь 12-ки и 13-ки, но жаль статистики по остальным.
К тому же Вы не совсем правильно понимаете затраты времени: на места с 1 они незначительны, доли секунды на каждое, основные затраты на места с 0 и на цепочки, которые при
частичном разложении дали 5 и более 0 (т.е.
предварительный valids>=11) и стали проверяться "до упора" (при этом в логе они будут всегда "+0" в valids и отличить их от остальных типа 6+0, 7+0, 8+0, 9+0, 10+0 становится трудно). Да, их можно ещё оптимизировать (например плюнуть на 0 за барьерами из 1 и допроверять лишь 0 с 36 с обоих сторон и даже порядок проверки указать), но это
значительного ускорения думаю не даст.
А проверка всех 6-ти проверяемых мест вообще самая быстрая из всех, там всегда по 36 делителей, другие в лог просто не попадают. Но она хоть и быстрая, но из-за огромного количества цепочек после фильтрации (N=94млн на круг 1e70) именно она и тратит основное время. Но её уже никак не ускоришь. Например для тестового круга 1e68 проверка только 6-ти проверяемых мест занимает 92% времени. Т.е.
любые способы ускорения дальнейшей проверки (вплоть до мгновенной) уберут лишь флуктуации времени в сильный плюс от некоторого минимального на круг, которое порядка 90% от среднего на несколько кругов. Ну и зафига париться ради <10% ускорения с потерей статистики? Мне это необходимым не кажется. Впрочем чуть выше привёл способ это сделать "малой кровью", изменением условия в 48-й строке программы.