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

[Dmitriy40]

Только что найдена:
L5-03:7472486235320208974406418076964688737817897278084328007277230419379287291: 1, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, valids=12+0, maxlen=12, ALL, FOUND!!!
На первом месте реально 4096 делителей. Полное разложение (остальных мест) потребовало 3 минуты.

[VAL]

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

Только что найдена:
L5-03:7472486235320208974406418076964688737817897278084328007277230419379287291: 1, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, valids=12+0, maxlen=12, ALL, FOUND!!!
На первом месте реально 4096 делителей. Полное разложение (остальных мест) потребовало 3 минуты.

Ура!
Я и не сомневался.
Надо бы в OEIS послать. Хотя, не знаю... Они еще и пятнашку по 12 делителей не опубликовали

А у себя я инфу уже обновил.

Мне кажется, что до 15 чисел по 36 делителей мы не доберемся. 15 простых подряд (после отделения обязательных множителей) найти нереально. А факторизация будет безнадежно тормозить.

[Yadryara]

Dmitriy40, проздравляю

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

А мне написал, что приготовил обновление.
Но, видать оно где-то отлеживается. Вместе с обновлением A119479

Вполне возможен человеческий фактор. Например, по ошибке отправил старую версию. Так что пишите ему или в дискуссию, тем более что ещё один рекорд только что состоялся.

То же самое и про A119479. Надо написать, напомнить.

[VAL]

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

о же самое и про A119479
. Надо написать, напомнить.

Так уже.
И не раз.
И тишина...

[EUgeneUS]

На день выпал, а столько уже произошло

VAL, Yadryara
В A292580 написано:

Цитата:

As of 2022-04-13 this a-file is being actively maintained by Hugo van der Sanden and updated about once a month: he welcomes email via his wiki page if you have corrections or improvements for that data.

То есть следующее обновление файла надо ждать около 13 мая.

А вот с фиксацией 15-ки в A119479 - не понятно. Начинаю подозревать плохое

-- 24.04.2022, 04:33 --

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

VAL в сообщении #1203960

писал(а):
Правда, чем реализация этого проекта может помочь человечеству, я пока не знаю.
Нынче этого понимания ни у кого так и не появилось?

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

-- 24.04.2022, 04:35 --

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

ОК. Вечером или завтра запущу счет дня на два.

Так и не запустил дальнейший счет без ускорителей. И уже не запущу, буду запускать 13-18 с ускорителями. Прошу понять и простить

-- 24.04.2022, 04:38 --

По "а-файлу" из A119479 у меня вот какой вопрос остался.
Там иногда огромные числа указаны в качестве точных значений. Например:

...
T(46,4) 353836514683135138284365423400852607743740081787109373 Hugo van der Sanden 2022-04-13
...
T(47,3) 12229485870130123102579152313423230896109004106619977392256259918212890623 Don Reble 2015-01-22

Интересно, каким способом доказывалась минимальность этих\таких цепочек?

-- 24.04.2022, 04:39 --

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

Только что найдена:

Поздравляю!

[EUgeneUS]

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

По планированию.
Предлагаемый круг по паттернам 1e70 у меня занимает полтора часа в одном потоке, т.е. за сутки в 4 потока могу просчитать примерно 65e70, учитывая что у всех скорость была ниже разделять работу удобно по 1e72 или кратно ему. При этом 0-1e72 мною уже просчитан в рамках тестовых запусков.
Сколько у вас будет считаться 1e70 или 1e72 проверьте сами, для этого в архивах приложен тестовый файлик M36n13-Test1.gp с интервалом всего 1e68, на несколько минут счёта, с примером его вывода.

На правах первого заявившего резервирую себе 7-10e72, вдруг там снова быстро попадётся искомое.

Взял себе диапазон снизу: 1-2е72. Считается в четыре потока. Предварительно время счета: около 4 часов на круг в одном потоке. Измерял "на глазок" (не как в readme).
Как пройдет круг - сообщу более точные оценки времени.

[Yadryara]

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

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

Почему в любом случае ?

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

По "а-файлу" из A119479 у меня вот какой вопрос остался.

Нет там никакого "а-файла". Процитирован A-файл из A292580.

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

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

...
T(46,4) 353836514683135138284365423400852607743740081787109373 Hugo van der Sanden 2022-04-13
...
T(47,3) 12229485870130123102579152313423230896109004106619977392256259918212890623 Don Reble 2015-01-22

Интересно, каким способом доказывалась минимальность этих\таких цепочек?

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

А те значения, которые считаются минимальными — как раз в основном тексте A292580.

[EUgeneUS]

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

Почему в любом случае ?

Что "с формализацией", что без неё.

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

Нет там никакого "а-файла". Процитирован A-файл из A292580
.

Да, конечно, из A292580. Моя ошибка в копипасте номера последовательности.

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

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

А те значения, которые считаются минимальными — как раз в основном тексте A292580
.

Хм.
1. В основном тексте указана последовательность до первого неизвестного члена (по которому известна только верхняя граница):

5, 2, 6, 14, 33, 12, 44, 603, 242, 10093613546512321, 24, 104, 230, 3655, 11605, 28374, 171893, 48, 2511, 7939375, 60, 735, 1274, 19940, 204323, 368431323, 155385466971, 18652995711772, 15724736975643

Следующий будет - T(6,10).

2. В разделе EXAMPLE приведено бОльшее количество известных членов последовательности. Но опять же далеко не все. Таблица в примерах заканчивается строкой $T(16, i)$.
Однако, известны точные значения и для таких членов: $T(17,1), T(17,2), T(18,1), T(18,2)$ и т.д.

3. В а-файле, насколько понимаю, верхние границы указываются со знаком

<=

а известные точные значения без оного. Вот характерный пример:

T(18,5) 95457996726524 Hugo van der Sanden 2022-04-13
T(18,6) <= 3328073741768311547 Hugo van der Sanden 2022-04-13

Читается однозначно:
а) Для $T(18,5)$ Хуго, почему-то считает $95457996726524$ точным значением.
б) А для $T(18,6)$ Хуго, почему-то считает $3328073741768311547$ оценкой верхней границы, а не точным значением.

[VAL]

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

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

...
T(46,4) 353836514683135138284365423400852607743740081787109373 Hugo van der Sanden 2022-04-13
...
T(47,3) 12229485870130123102579152313423230896109004106619977392256259918212890623 Don Reble 2015-01-22


Интересно, каким способом доказывалась минимальность этих\таких цепочек?

Вот здесь написано как
(перед второй таблицей).

[Yadryara]

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

3. В а-файле, насколько понимаю, верхние границы указываются со знаком Код:

<=

Да, конечно. Теперь уже моя невнимательность.

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

есть и безоговорочные
$60, 735, 1274, 19940, 204323$ для $i = 1, 2, ... , 5$.

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

Ещё нашёл $368431323$ для $i = 6$.

Эти значения минимальные по той простой причине, что я в джипишной проге просто перебирал все числа подряд с нуля.

[EUgeneUS]

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

Yadryara в сообщении #1550928

писал(а):
Ещё нашёл $368431323$ для $i = 6$.
Эти значения минимальные по той простой причине, что я в джипишной проге просто перебирал все числа подряд с нуля.

В а-файле есть этот результат:

T(6,6) 368431323 Giovanni Resta 2017-09-20

[EUgeneUS]

Посчитался круг 1е70. Ниже статистика по 4-м потокам

N=93814588, 17822.555s (9987.699s in PARI) per round 100e70.
N=93809044, 18341.907s (10334.536s in PARI) per round 125e70.
N=93816513, 18064.024s (10094.326s in PARI) per round 150e70.
N=93818847, 18426.350s (10549.661s in PARI) per round 175e70.

До 2е72 досчитается где-то за $5.33$ суток.

[VAL]

Обновили A119479

[EUgeneUS]

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

Обновили A119479

Ура!

Dmitriy40
Некоторые соображения по ускорению.
Вот первая запись в логе M36n13-1.txt:

L1-01:1001726701821517392238119533904484954554338451276394912620020396454986491:  1,  1,  1, 36, 36, 36,  1, 36, 36,  1,  1, 36,  1,  valids=6+0, maxlen=3, ALL

Как видно, пытались разложить все 13 чисел, при этом уже после единицы в седьмой позиции было ясно, что ни 13, ни 12, ни даже 11 не получится.
Предложение - даже не пытаться раскладывать явно бракованные цепочки (которые не дадут 12 или 13). То есть: если получаем единицу не в последней или первой позиции, то сразу бросаем и переходим к следующей.
Порядок разложения предлагается такой (для L-паттернов, для R-паттернов д.б. симметричный):
1. $4, 5, 6, 8, 9, 12$ - проверяем места, где обычно 36 множителей, это раскладывается быстрее.
2. $7, 10, 11, 3, 2$ - проверяем места, в том порядке, как более "эффективно" увеличивается цепочка.
3. $1, 13$ - проверяем края. Проверять надо оба края всегда, если хотим найти все "maxlen=12"

Если хотим ловить и "maxlen=11", то порядок предлагается такой:
1. $4, 5, 6, 8, 9,$ - проверяем места, где обычно 36 множителей, это раскладывается быстрее, кроме 12-й позиции.
2. $7, 10, 11, 3$
3. $12, 2$ - если в 12-й позиции не 36, и во 2-й позиции "1", останавливаемся.
4а. Eсли в 12-й позиции 36, проверяем 13-ю. Вне зависимости от результата переходим к 4б
4б. Eсли во 2-й позиции не "1", проверяем 1-ю.

[Dmitriy40]

Интервал 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, а таковая проводится за доли секунды на каждое место, хоть для $10^{70}$, хоть для $10^{90}$. Ну а сколько займёт полная факторизация кандидатов в решения не столь важно, их всего несколько десятков на недели счёта будет (можно будет ещё оптимизировать условия для полного разложения, я просто морочиться пока не стал).

-- 24.04.2022, 16:31 --

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

Предложение - даже не пытаться раскладывать явно бракованные цепочки (которые не дадут 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-й строке программы.