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

[VAL]

Когда цепочка из 8 чисел, имеющих по 2160 делителей, нашлась очень быстро, стало понятно, что и цепочка длиной 9 не за горами.
$M(2160)\ge 9$

(Оффтоп)

n = 51811269199566221716864194461799226615069173192652310223960756374479080627779764387862216712800154293785219465729570840602429957728612238671868 
n+1 = 11^(4) * 37^(2) * 43^(2) * 53^(2) * 85427 * 1380 357499 * 423 020400 399033 051751 * 9977 307236 343095 701973 533328 860924 539786 447721 149183 137260 123172 299634 194621 525366 725622 926227 (94 digits)  
n+7 = 5^(8) * 7^(4) * 73^(2) * 834 629641 * 27722 624159 * 379 968519 499900 448102 057510 006670 572089 (39 digits) * 1 179099 779435 575036 463227 326230 278220 661885 654846 955243 236677 060241 822029 (73 digits)

Почти сразу после нашлась длинная цепочка для $k=2520$. Теперь это $k$ самое большое из тех, для которых известны длинные цепочки.
$M(2520)\ge 8$

(Оффтоп)

n = 1099987580463572703691945569672606413641468257718102327471040995740155637973737173108749190243771681569412629537133095426949779895690324808181494003151527054671870 
n+1 = 3^(14) * 17^(6) * 73^(2) * 78992 558268 666011 970937 * 22 953775 069824 695573 811269 723419 (32 digits) * 986076 630540 811555 423327 788683 006978 456493 729829 089147 624922 915030 375831 010203 408949 322253 (90 digits);
n+6 = 2^(2) * 13^(6) * 31^(4) * 79^(2) * 744113 * 4 747168 986218 877219 345107 * 2 798292 671095 120296 955325 940943 944027 749582 285378 865109 260121 647917 443395 565173 445798 930148 886912 221631 322917 778691 (115 digits);

Впрочем, скорее всего, и этот рекорд не продержится долго. (А вот следующий обновить будет не просто.)

[Huz]

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

Когда цепочка из 8 чисел, имеющих по 2160 делителей, нашлась очень быстро, стало понятно, что и цепочка длиной 9 не за горами.
$M(2160)\ge 9$

I tried Alpertron for $(n+3)/(13^4 \cdot 31^2 \cdot 41^2 \cdot 47^2 \cdot 11735827 \cdot 701788478335421)$ for a bit over an hour, then my machine crashed.

[VAL]

Huz в сообщении #1569865 писал(а):

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

Когда цепочка из 8 чисел, имеющих по 2160 делителей, нашлась очень быстро, стало понятно, что и цепочка длиной 9 не за горами.
$M(2160)\ge 9$

I tried Alpertron for $(n+3)/(13^4 \cdot 31^2 \cdot 41^2 \cdot 47^2 \cdot 11735827 \cdot 701788478335421)$ for a bit over an hour, then my machine crashed.

That is not $n+3$. Small divisors belong to $n+5$.

n+5 =  13^4 × 31^2 × 41^2 × 47^2 × 1049 016911 × 2095 979563 × 1 231778 030666 235570 607387 × 187 699025 490701 527118 983615 991323 152083 607982 344733 364840 902856 678671 247518 347025 586167 (87 digits)

And I seem to have missed real case $n+3$
Now I will try to factorize it.

[Dmitriy40]

51811269199566221716864194461799226615069173192652310223960756374479080627779764387862216712800154293785219465729570840602429957728612238671868+3 (143 digits) = 3^14 × 59^2 × 61^2 × 11735827 (ECM, curve 1) × 701788478335421 (ECM, curve 3) × 738390327527906149357497447159902128062814004307143 (51 digits) (Division) × 137517205988183479180239927935409806437944739665880536839 (57 digits)

[VAL]

Обещанный вчера рекорд не заставил себя долго ждать.
$M(3600(\ge 8$

(Оффтоп)

n = 16337196350337127461017820366387703467967050295635433470362672572540078369684501408173441034950114818174717797569425527085587544358611589582364579151870
n+1 = 3^(8) * 29^(4) * 31^(4) * 310729 * 22 683750 005615 680912 460603 * 894 303462 476950 255555 871355 959513 (33 digits) * 604765 728405 885086 032653 248502 982618 776662 774894 419327 925354 220896 374781 (72 digits)  
n+2 = 2^(14) * 37^(4) * 83^(4) * 1 036471 * 32 440003 * 777053 834380 244527 303802 596609 * 2956 006329 344911 732394 003397 343421 833829 883609 771928 099317 321752 974278 753740 625582 048071 280481 (94 digits)

Касательно цепочки из 9 чисел по 2160 делителей.
По-видимому, я перепутал и вместо $n+3$, не разложившегося с помощью PARI за отведенное время, запихнул в Alpertron $n+1$.
И к тому же почему-то не проверил остальные числа (что я обычно делаю)
Однако, сама цепочка почти наверняка верная. Только это пока не доказано

PS: Пока набирал этот текст, увидел комментарий Дмитрия. Теперь доказано.
Спасибо!

[Dmitriy40]

VAL
Я что-то либо не понял, либо не запомнил: YAFU то у Вас заработала или нет? Трудные случаи только она разлагает за разумное время (часы/дни).

[Dmitriy40]

Huz
In continuation of the previous improvement with the window title: is there a total number of patterns for the enumeration at the beginning of the work or it is obtained interactively only during the work and until the work end is unknown? If exist, I would like to see this number in the log, so that you could use the window title at least approximately to understand how close the work is to completion, otherwise the number in the window title is little informative if more than one pattern is searched. Yes, I can of course run pcoul twice, first with -a, then to work, but this is inconvenient (see for example the bug under windows below). But of course it is still needed - at least to distinguish what kind of pattern search is running in this window.

Also, I have a strange bug under windows: running with the -a switch gives out about two hundred patterns in the console and the program crashes with an unknown error (a windows dialog box appears to close the program and what the error remains unclear). Not only pcoul closes, but also console window, i.e. maybe error happens in console host (I suspect some kind of buffer overflow in windows itself). But output redirection to file works correctly.
It is the same on versions 20221107 and 20221109.
Perhaps after each pattern output (well, it's just easier, because the speed is not important here, you can do flush stdout every couple of dozens if you're not too lazy to add an extra counter)? If not already done.
However, I do not insist on fixing this behavior, it's just an annoying inconvenience.

[VAL]

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

VAL
Я что-то либо не понял, либо не запомнил: YAFU то у Вас заработала или нет? Трудные случаи только она разлагает за разумное время (часы/дни).

На числах до 95 десятичных знаков работает всегда и быстро. А на больших - только если повезет. В большинстве же случаев после вывода на консоль кучи данных завершает работу без результата.
Я пытался подсунуть YAFU те exe-шники, которые Вы рекомендовали. Но безрезультатно.
Приходится пытаться расколоть Alpertron'ом. Иногда удается. Но это процесс не быстрый.

Кстати, вот парочка чисел:

(Оффтоп)

1382980070105341480535698212268007993225508457035132702993185357854929124873911094441369085670474422482528232017314867189287230020044960327148437498+3
9396823261792106211766571603602345815216005644696524037290060990273701549735305777694007166199218203675983492562943076865962888439644960327148437498+5

Если хотя бы одно из них имеет 816 делителей (а я уверен, что оба имеют), то будет доказано $M(816)\ge 8$.

[Huz]

VAL, Dmitriy40 Thanks both; apologies for copying the factors wrongly - I had several factorization attempts on the screen, and clearly confused myself when trying to paste them over.

-- 13.11.2022, 16:17 --

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

Huz
In continuation of the previous improvement with the window title: is there a total number of patterns for the enumeration at the beginning of the work or it is obtained interactively only during the work and until the work end is unknown?

Do you mean the range of "b###" identifiers? No, this is obtained interactively during the work: the fixed primes are iterated in the normal manner, then I look at the -a or -b options to decide what to do at the point it will transition to unfixed primes.

In principle it would be possible for the code to run through them twice. But that's quite a lot of extra code just to get a count.

Цитата:

Also, I have a strange bug under windows: running with the -a switch gives out about two hundred patterns in the console and the program crashes with an unknown error (a windows dialog box appears to close the program and what the error remains unclear). Not only pcoul closes, but also console window, i.e. maybe error happens in console host (I suspect some kind of buffer overflow in windows itself). But output redirection to file works correctly.
It is the same on versions 20221107 and 20221109.
Perhaps after each pattern output (well, it's just easier, because the speed is not important here, you can do flush stdout every couple of dozens if you're not too lazy to add an extra counter)? If not already done.

That's odd, I certainly haven't seen that here - but looking at the code I see that the information is output in a stupid way. I will fix it to use the standard way, then it will also automatically get flushed, and if you select a log file it will automatically go there too.
A side-effect of the stupid way is that it tries to update the window title for every pattern, hundreds of times per second. That is probably what causes the crash for you.

[Dmitriy40]

Huz в сообщении #1569924 писал(а):

Do you mean the range of "b###" identifiers? No, this is obtained interactively during the work:

Yes, that one.
Then there's no need, whoever wants to run the code twice himself.

Huz в сообщении #1569924 писал(а):

A side-effect of the stupid way is that it tries to update the window title for every pattern, hundreds of times per second. That is probably what causes the crash for you.

No, this is observed on all versions, both 20221107 and 20221109. The version for windows with update the title console window is not available yet and I haven't tested it.

[Huz]

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

Huz в сообщении #1569924 писал(а):

A side-effect of the stupid way is that it tries to update the window title for every pattern, hundreds of times per second. That is probably what causes the crash for you.

No, this is observed on all versions, both 20221107 and 20221109. The version for windows with update the title console window is not available yet and I haven't tested it.

Oh, good point. In that case you are probably right that it was the lack of flush.

I've pushed an update that should fix this, I'll ask CorporalTermit to make a new build - I think most people would benefit from the window title updates.

[Dmitriy40]

Huz
Can I ask you another little question? I have not encountered this yet, but I wonder: will the second (and subsequent) found candidate be shown in the log if it is larger than the first and therefore is definitely not the best?

[Huz]

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

Huz
Can I ask you another little question? I have not encountered this yet, but I wonder: will the second (and subsequent) found candidate be shown in the log if it is larger than the first and therefore is definitely not the best?

We never see larger results: as soon as we see any result, we update the maximum value to check, and we never check numbers greater than the maximum.

If the target number of divisors has repeated odd prime factors, we may see the same value shown multiple times. (I could fix that, but I find it a useful reminder that we can generate the same number multiple different ways.)

[Dmitriy40]

Huz
Understandably, thanks.
For the task of finding the minimum it is correct, and other tasks - are other tasks.

[Dmitriy40]

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

Кстати, вот парочка чисел:
...
Если хотя бы одно из них имеет 816 делителей (а я уверен, что оба имеют), то будет доказано $M(816)\ge 8$.

Разложил меньшее, как более лёгкое (ушло 6ч в YAFU):

1382980070105341480535698212268007993225508457035132702993185357854929124873911094441369085670474422482528232017314867189287230020044960327148437498+3 (148 digits) = 11^16 × 29^2 × 199 × 3247329743340031 (ECM, curve 26) × 62490811669823633351704046093101412109595175348813 (50 digits) × 886219559278001346562520682475998398317592139009542011378033 (60 digits)
Number of divisors: 816

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

На числах до 95 десятичных знаков работает всегда и быстро. А на больших - только если повезет. В большинстве же случаев после вывода на консоль кучи данных завершает работу без результата.

Вроде бы там как-то можно поднять этот порог переключения на GNFS, но думаю толку мало, ECM находить делители будет гораздо дольше.