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

[VAL]

Надеюсь, 8-ка чисел, имеющих по 3000 делителей в ближайшее время будет поймана. (Если не срастется, у меня есть еще несколько кандидатур).
А пока нашлась кандидатура для $k=2268$.

(Ищем 8-ку по 2268 делителей)

834003679368911045045242378046237841912119263775647053930517386356982904475598603801949376941804946864682326586372747161899125475370654209278287310085369 (153 digits)

Достаточно, чтобы это число было произведением двух двух простых.

[DemISdx]

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

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

Пока получил такой

(Результат)

NFS elapsed time = 31232.1372 seconds.
Total factoring time = 34357.1624 seconds


***factors found***
P73 = 4659575596920579629198682013676869570865533672238849861278896289984314731
P67 = 7398743305100448725395010686115987455426189139963193914224272631637

***factorization:***
34475003752325565577845499367078547514454045820193022964870108659834683835890959522609776627421711411543429654879128170725325284173435744647=4659575596920579629198682013676869570865533672238849861278896289984314731*7398743305100448725395010686115987455426189139963193914224272631637

После него "пропихнул" вперед (надеюсь все правильно сделал, с операторской точки зрения) запуск:

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

Только что нашел кандидатуру, где нужно разложить всего одно число.

Т.е. 126495.
На него уйдет около суток, наверное.
Только тогда, видимо, будет понятно, нужно ли считать оставшиеся четыре (-1 т.к. одно длинное, от показанной пары, таки в расчете на сутки).
Там будем поглядеть...

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

сутки счёта это не год.

[VAL]

DemISdx в сообщении #1702686 писал(а):

[..]
После него "пропихнул" вперед (надеюсь все правильно сделал, с операторской точки зрения) запуск:

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

Только что нашел кандидатуру, где нужно разложить всего одно число.

Т.е. 126495...

Да, его вне очереди. Если распадется на два простых множителя, раскладывать ранее присланные числа не нужно.
В отличие от 83400... Оно нужно для другого $k$.

PS: 83400... тоже можно не разлагать. Alpertron сам справился!

$M(2268) \ge 8$

(Первое число цепочки)

n = 57101599104873547683956416136402200182075104231478919945371282365160074044534677638249576083605777545301827508749551161620811409901380375105174398688966153367460332437498
n+6 = 2^20 × 59^2 × 61^2 × 71^2 × 304206296711827740726779055435114407 × 
2741572703733204592546066732131800214171123233917729591077647969988904644773769456690753329031464983719090220020214367 

[DemISdx]

Ок. Понял.

(Для общего развития)

Поразбирался немного с пакетным режимом запуска YAFU 3.0.
Вроде все просто.

Команда запуска:

yafu-x64.exe "factor(@)" -batchfile run.txt -threads 4 -p >screen4.log

Где файл run.txt должен быть вида:

999999999999999999999999999999999999999999991
999999999999989 * 999999999999999999999999999999999999999999991
99999597927516812804847414529880573 * 99999683550587277607185624599397449

Т.е. без скобок и кавычек.
Число тредов на все расчеты одинаковое.
Но реально, при расчете, программа может использовать и меньшее число тредов, но не большее.
Это видно в логах.

Важное замечание, т.к. результат выводится на экран консоли и убегает вверх,
то используется простое перенаправление вывода в файл ( в виде ">screen4.log").
Чтобы не потерять и не пролистывать все эти строки...

Полное перенаправление (вида ">screen4.log 2>&1") НЕ используется, т.к. файл легко достигает размера 60Мб на одном значении расчета.
Поэтому все нужное пишется в файл "screen4.log", а не на экран консоли (на экран, в таком случае, попадает только stderr канал).
Нужную инфу выдергиваю с помощью команды

cat -s screen4.log|grep -A1 -B8 -e "factorization:" -e "fac: factoring"

Важный момент - команд "cat" и "grep" в винде нет, брал их из окружения компилятора gcc.
Т.е. это не стандартный метод.

Как "пропихнуть" некое значение вперед по очереди исполнения, когда все уже запущено в работу?
Мной делалось так:
1. вношу нужное, внеочередное, число в файл "run.txt", вставляя его сразу после того числа, которое считается прямо сейчас.
2. когда работает режим "-batchfile" создается файлик с фиксированным именем "__tmpbatchfile"
В нем программа, во время работы, размещает все, что было в "run.txt" за минусом первой строки.
А когда текущее число посчитано программа перемещает его содержимое в файл "run.txt".
Т.о. файл "run.txt" уменьшается по мере расчета запланированных значений.

Поэтому п.3
3. Делаю копию "__tmpbatchfile" в виде "1__tmpbatchfile.txt" (на всякий случай).
4. вношу в первую строку файла "__tmpbatchfile" нужное число для "пропихивания".
Собственно и все.
"Пропихнутое" число автоматом начинает считаться после текущего значения.

И еще, все кешированные данные от текущего расчета - удаляются автоматически при переходе к расчету нового значения.

Более глубже пока не разбирался.

[DemISdx]

Пока, судя по сообщениям вида "filtering ETA:":
для 12649... нужно 17-ть с гаком часов.
для 38043 (

DemISdx в сообщении #1702686 писал(а):

-1 т.к. одно длинное, от показанной пары, таки в расчете на сутки

) нужно 24 с гаком часов от настоящего момента.

[Dmitriy40]

Можно убрать "factor(@)" из командной строки и поместить его в каждую строку run.txt:
factor(100)
factor(1271)
и так далее.
Это позволяет делать не только команду факторизации, но и другие (если вдруг понадобятся).

Чтобы не потерять разложение, его можно найти в файле factor.log (делители будут в строках типа prp45=...) или в файле factor.json под именем factors-prime:[] (не разложенные числа будут под именем factors-composite:[]) или ключом -pfile записать в файл primes.dat. Ещё есть ключи -op, -of, -ou примерно о том же. У меня на мелком тесте из всех этих ключей сработал только -of.
Ещё, если найдутся малые простые делители, то они будут в строках типа "div: found prime factor = ...".
Если хочется лишь результат, без кучи логов, то есть ключик -silent.

Поиск строк в файле под виндой делает команда findstr, например найти в factor.log строки prp можно командой findstr /C:", prp" factor.log. Простыми средствами выдавать следующие строки за найденной под виндой нельзя.

[Yadryara]

Гляжу активность нынче возросла. Но... факторизация готовыми прогами лично мне малоинтересна.

Занятное совпадение нынче возникло:

Человечеству не известно ни одного кортежа, симметричной 21-ки из последовательных простых чисел.

Человечеству не известно ни одной 21-ки из последовательных чисел с одинаковым количеством делителей.

То есть очковтирательство по 48 вроде как напрашивается. Про это мало писалось, насколько помню, сочли очень трудным. И не помню, улучшились у народа с тех пор скилы и/или компы... Лично у меня комп намного лучше, но годами я искать конечно не готов...

[Dmitriy40]

Интереснее 36 и 84 - их можно попытаться добить до упора (в 15), как получилось с M(12).

Для M(48) у меня были сделаны программы под SSE, проведён тестовый поиск для выяснения статистики, оказалось каждый круг по 5760 паттернам занимает 70 минут (в один поток), из них 50 минут тратится в PARI на факторизацию, при этом за 13 кругов один лучший результат дал всего лишь 10 правильных числа из 21. Всего в лог попало 93 цепочки. Числа 53-54-значные.
И только две цепочки не имеют лишних делителей до $2^{26}$, с valids=8 и 9.
Перепроверка лучшего результата с valids=10 показала что на самом деле там valids=12 и есть цепочка из 7 правильных чисел подряд, но для такой проверки требуется втрое больше времени.
Каждый круг выдаёт почти 100млн кандидатов, которые надо допроверять на разложения.
5760 программ занимают 870МБ (400МБ архив). Разделение по потокам делается дублированием PARI файла в нужном количестве.
Можно попробовать подключить YAFU для факторизации, но вряд ли это даст ускорение (вызов внешних прог в PARI довольно дорог).

[VAL]

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

Гляжу активность нынче возросла.

С возвращением!
А то Вас нет, и нет. Я уже волноваться начал

Цитата:

Но... факторизация готовыми прогами лично мне малоинтересна.

А вот и объяснение.
Но, как уже написал Дмитрий, разных локальных задач в рамках данной тематики немало.

Цитата:

Занятное совпадение нынче возникло:

Человечеству не известно ни одного кортежа, симметричной 21-ки из последовательных простых чисел.

Человечеству не известно ни одной 21-ки из последовательных чисел с одинаковым количеством делителей.

То есть очковтирательство по 48 вроде как напрашивается. Про это мало писалось, насколько помню, сочли очень трудным. И не помню, улучшились у народа с тех пор скилы и/или компы... Лично у меня комп намного лучше, но годами я искать конечно не готов...

У меня комп прежний.
Полагаю и мои персональные мозги тоже не улучшились
Искать очко имеющимися мощностями, на мой взгляд, дело малоперспективное (впрочем, перебор не грозит, только недобор).
Но можно поискать простаивающие мощности.

-- 22 сен 2025, 22:41 --

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

Интереснее 36 и 84 - их можно попытаться добить до упора (в 15), как получилось с M(12).

Ну 84 на сегодняшний день представляется мне малонаучной фантастикой. А 36 - may be...

[Dmitriy40]

С 2022г я разобрался как быстро считать КТО сразу по нескольким другим простым модулям, это может ускорить счёт раза в два (надо вспоминать по каким простым раньше был линейный перебор и сколько по ним запрещённых остатков). Плюс есть уже полгода как недописанная идея (в одном потоке вроде работает) ещё раз в 5-7 быстрее (но в многопоточном режиме ещё не проверял, могут быть коллизии кэша и тормоза). Плюс у меня появился вычислительный сервер, в 5-6 раз быстрее основного компа за счёт большего количества ядер (правда любой комп Демиса ещё в полтора раза быстрее), но мне пока есть что на нём считать. Если всё это совместить, то можно выиграть порядок-полтора скорости ... Хватит ли этого на М36n15/М48n21 за разумное время я не знаю.

[Yadryara]

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

С возвращением!
А то Вас нет, и нет. Я уже волноваться начал

А я вот не волнуюсь, но грущу. Ибо почти год жду ответа:

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

VAL, где Ваши 24 ядра? Простаивают? Присоединяйтесь, нас ждёт мировой рекорд, если правильно понимаю, 19-252 ищут уже 10-й год и вот наконец-то есть реальный шанс.

Правильно понимал. Хорошо, что нам тогда повезло, ведь совершенно не было уверенности, что мы найдём её не в первом, так во втором периоде. И никто больше так и не помог — втроём справились.

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

Плюс есть уже полгода как недописанная идея (в одном потоке вроде работает) ещё раз в 5-7 быстрее

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

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

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

М36n15/М48n21

Вы вроде бы уже заменили-таки М на D(d) и я похвалил.

Да, нужен сравнительный анализ временных затрат на D(36,14), D(36,15) и на D(48,21).

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

У меня комп прежний.
Полагаю и мои персональные мозги тоже не улучшились

А скилы? Ассемблер освоили или так и ищете на PARI?

[Dmitriy40]

Пример mihaild показывает что чатгпт полезнее ассемблера ... Ну плюс немного навыков программирования (на С).

[DemISdx]

DemISdx в сообщении #1702686 писал(а):

После него "пропихнул" вперед (надеюсь все правильно сделал, с операторской точки зрения) запуск:VAL в сообщении #1702637

писал(а):
Только что нашел кандидатуру, где нужно разложить всего одно число. Т.е. 126495.

"Пропихнутое" вперед уже посчиталось

(Результат по 12649...)

fac: factoring 12649554112872652235923191393686274726058044344064638386868742573749136080535227523673216104835931517848257206050584198327096750148594533706204698282739
fac: using pretesting plan: normal
--
NFS elapsed time = 111508.2733 seconds.
Total factoring time = 123268.9475 seconds


***factors found***
P57 = 113720010575305642440450235666095765434997283828770661961
P96 = 111234197472186212416259872165400500763403779139636900855723905641366494173350802091583887652699

***factorization:***
12649554112872652235923191393686274726058044344064638386868742573749136080535227523673216104835931517848257206050584198327096750148594533706204698282739=113720010575305642440450235666095765434997283828770661961*111234197472186212416259872165400500763403779139636900855723905641366494173350802091583887652699

При этом после него успело посчитаться, неожиданно быстро, следующее за ним число из шестерки (три по две)

(Результат по 26252...)

=== Starting work on batchfile expression #3 ===
factor(2625217294541990373652239812000036965594661802195184152263625144906231135195346598430089254614730355403857736627854198135548124221353781647901)
=============================================
fac: factoring 2625217294541990373652239812000036965594661802195184152263625144906231135195346598430089254614730355403857736627854198135548124221353781647901
fac: using pretesting plan: normal
--
starting SIQS on c95: 15870271025529665164162277580966830940442095563482633716257448722836319745218062440698878005979
Total factoring time = 3425.1477 seconds


***factors found***
P48 = 165417294406563204566010725150224091699890031719
P95 = 15870271025529665164162277580966830940442095563482633716257448722836319745218062440698878005979

***factorization:***
2625217294541990373652239812000036965594661802195184152263625144906231135195346598430089254614730355403857736627854198135548124221353781647901=165417294406563204566010725150224091699890031719*15870271025529665164162277580966830940442095563482633716257448722836319745218062440698878005979

Жду дальнейших указаний, что искать.
Батч моду по остальным пока НЕ прерывал.

[VAL]

DemISdx в сообщении #1702941 писал(а):

DemISdx в сообщении #1702686 писал(а):

После него "пропихнул" вперед (надеюсь все правильно сделал, с операторской точки зрения) запуск:VAL в сообщении #1702637

писал(а):
Только что нашел кандидатуру, где нужно разложить всего одно число. Т.е. 126495.

"Пропихнутое" вперед уже посчиталось

Замечательно!
Таким образом, у нас есть еще одна оценка

$M(3000) \ge 8$

(Оффтоп)

n = 4715089655427205715384941048889758569147661078916034595979113287189804176455062759285238302824546193009696689202433219468463476658050616404204991574740006797971549930699882494
n + 2 = 2^24 × 41^4 × 109^2 × 661769 × 113720010575305642440450235666095765434997283828770661961 × 
111234197472186212416259872165400500763403779139636900855723905641366494173350802091583887652699 

А еще одну оценку удалось усилить, не прибегая к YAFU.

$M(156) \ge 9$

(Оффтоп)

n = 64220176780316948958783156123563055944374333010869127475278258166634174471410830851574452103094971831437455471815455747818356918212890621

Цитата:

Жду дальнейших указаний, что искать.
Батч моду по остальным пока НЕ прерывал.

Не знаю, что батч мода, но, полагаю, ее лучше прервать от греха подальше

На данный момент новых кандидатур на факторизацию нет, но они наверняка скоро появятся.

-- 23 сен 2025, 21:00 --

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

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

С возвращением!
А то Вас нет, и нет. Я уже волноваться начал

А я вот не волнуюсь, но грущу. Ибо почти год жду ответа:

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

VAL, где Ваши 24 ядра? Простаивают? Присоединяйтесь, нас ждёт мировой рекорд, если правильно понимаю, 19-252 ищут уже 10-й год и вот наконец-то есть реальный шанс.

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

Цитата:

Правильно понимал. Хорошо, что нам тогда повезло, ведь совершенно не было уверенности, что мы найдём её не в первом, так во втором периоде. И никто больше так и не помог — втроём справились.

Вот видите! А то бы сейчас сцепились по поводу приоритета

[DemISdx]

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

Не знаю, что батч мода, но, полагаю, ее лучше прервать от греха подальше

Ок. Прервал.
(из прикольного там, это NFS elapsed time = 177791.1922 seconds.
и Total factoring time = 200150.5688 seconds,
т.е. 55 часов расчета)

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

На данный момент новых кандидатур на факторизацию нет, но они наверняка скоро появятся.

Понял.