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

[Huz]

New release is available at v20221113.

This has support for -v to update window title, and hopefully fixes the issue with -a.

[Dmitriy40]

Huz
Bug with -a are not corrected: https://i.imgur.com/kFTcgqQ.png
Text on window: "Прекращена работа программы Окно консоли узла" = "The program Node Console window has been closed" (or something like that).
The difference from the behavior of previous versions: when click "Close program" in this window closed and pcoul and conhost.
The redirect to the file continues to work correctly.
I think this is not a critical bug and can be spit on.

With switch -v the title window is updates, that ok, bXXX: XX XX XX.

Stopping two searches and starting them in a new version in one case went to count (hopefully further, not again, in the log "recover" and the running time continued to go on), the second does not start, swearing "could not apply_single(13, 73, 6)". Regardless of the version (the previous working produces exactly the same) or switch -v.

[Huz]

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

Huz
Bug with -a are not corrected

Bother, in that case I don't know what the problem is. If I get any other ideas I'll let you know.

Цитата:

Stopping two searches and starting them in a new version in one case went to count (hopefully further, not again, in the log "recover" and the running time continued to go on), the second does not start, swearing "could not apply_single(13, 73, 6)".

Yes, I have seen this happen too, my apologies that I didn't already fix it.

When this happens, you have the option of editing the last 305 line to remove just the prime power it is complaining about (which in this example would, I think, be $73^6$ in the 13th position, counting from 0). So if the entry is "2.73^6", replace it with "2"; if the whole entry is "73^6", replace it with ".". If that is not enough to fix it, there may be a bigger problem; in that case please send me the log file. I suggest making a copy of the log file before editing in any case.

In certain cases when a new allocation is made, the function apply_single() decides that it can immediately process this; it then gives the same return value as when the allocation is invalid, to signal that no further processing is necessary. This happens mainly if after applying the allocation no more divisors are needed, and is therefore quite rare. When recovering a previous run, the code that tries to restore things to the previous state does not have a way to distinguish between "this was an error" and "this was fine, but I already dealt with it".

[Dmitriy40]

Huz
In new version, if she started to continue work after old version, not increment bXXX in window title, other 3 numbers is counting over full interval, but b0 remains b0 ... The patterns are enumerating, in the log everything is correct, b0 remains only in window title.

The README does not written that the -b key also supports setting the range of patterns with a colon, like -x. This is fully works and very handy!

[Huz]

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

Huz
In new version, if she started to continue work after old version, not increment bXXX in window title, other 3 numbers is counting over full interval, but b0 remains b0 ... The patterns are enumerating, in the log everything is correct, b0 remains only in window title.

Is that with a single "b" value, or with a range? I did some tests with a single "b" value which seemed to work correctly here.

If you could let me know the first line of the log file, and the last 305 line (either here or by email), I can try to reproduce the problem.

Цитата:

The README does not written that the -b key also supports setting the range of patterns with a colon, like -x. This is fully works and very handy!

The README used to document that, until I discovered that recovery does not work with a range. I don't have a good fix for that right now - it might need the code to enumerate the batches twice that we discussed a few messages ago.

[Dmitriy40]

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

When this happens, you have the option of editing the last 305 line to remove just the prime power it is complaining about (which in this example would, I think, be $73^6$ in the 13th position, counting from 0). So if the entry is "2.73^6", replace it with "2"; if the whole entry is "73^6", replace it with ".". If that is not enough to fix it, there may be a bigger problem; in that case please send me the log file.

Did I understand correctly that degrees are checking in ascending order and ^5 will always be later than ^2?
I was upset that I can not will continue the long process and deleted the log. And started a completely different calculation. Sorry.

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

Is that with a single "b" value, or with a range?

This is without specifying -b at all.
I'll show you the log in email.

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

The README used to document that, until I discovered that recovery does not work with a range. I don't have a good fix for that right now - it might need the code to enumerate the batches twice that we discussed a few messages ago.

No, I think double-passing is evil.
Wouldn't it be enough to add the number bXXX to line 305 of the log? At most we will get incompatibility of new logs with old programs, but going forward (old logs with new programs) will be compatible, and usually it is enough.

[Huz]

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

Did I understand correctly that degrees are checking in ascending order and ^5 will always be later than ^2?

Yes. Let $n$ be the number of divisors, then the order is (highest prime dividing $n$) first, then increasing order. So $n=60$ will take (power + 1) in order $[5, 10, 15, 20, 30, 60, 3, 6, 12, 2, 4]$,

Цитата:

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

The README used to document that, until I discovered that recovery does not work with a range. I don't have a good fix for that right now - it might need the code to enumerate the batches twice that we discussed a few messages ago.

No, I think double-passing is evil.
Wouldn't it be enough to add the number bXXX to line 305 of the log? At most we will get incompatibility of new logs with old programs, but going forward (old logs with new programs) will be compatible, and usually it is enough.

At the moment, on recovery it does not work out what batch it is, because it sets up the stack directly from the last 305 line. If you pass "-b123", it assume that is the current batch. This also explains why it shows b0 if you recover a run where no batch was specified. I need to work out a better way to handle that, but that may require identifying batches in a different way - which would be inconvenient for the current push towards $D(12,11)$.

[Dmitriy40]

Huz
Yes, I've already realized that it's not enough.
Well, then leave it as it is.
The pattern enumeration can also be organized externally (for /f in windows console).

[Huz]

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

Stopping two searches and starting them in a new version ... the second does not start, swearing "could not apply_single(13, 73, 6)".

I think I have a fix for this; I will test it locally for a few days before pushing it.

A correction to my earlier explanation: it is trying to apply $73^5$ (not $73^6$) at the 13th position. The power has been incremented at this point.

[EUgeneUS]

Если кому-то интересно.
У меня (для диапазона b1836-b2166) закончился счет паттернов с $LCM \geqslant 1331114400$.
Всего 118 штук (не считая паттернов с квадратами, которые посчитались почти моментально).
Потребовалось несколько дней (5-6).
А вот остальные 167 паттернов из этого диапазона с $LCM \leqslant 42688800$ будут у меня считаться по грубым оценкам около 160 дней

[Dmitriy40]

Huz
After thinking about it again, I again stopped understanding what prevents the analysis of the log from continuing with the correct pattern number: when we start with the pattern number, then obviously the numbers in the pattern are not taken out of thin air or from the ceiling, and the program somehow calculates exactly what numbers should be in the pattern with the ordered number. That is, it is doing double work. And when analyzing the log you only need to change the condition for stopping this work and moving on to the main search - compare not the pattern number, but its content. And you don't even need to write it into the log. Although it will make it easier to recover the state from the log.

And there are really two problems with b0 when continuing the log computation: that it is equal to zero; and that it no longer changes with counting patterns (when called for more than one pattern).

[Yadryara]

Статистика на сегодня пока что такая.

$\tikz[scale=.08]{ \fill[green!90!blue!50] (110,160) rectangle (125,170); \fill[green!90!blue!50] (110,140) rectangle (125,150); \fill[green!90!blue!50] (0,120) rectangle (140,140); \draw (0,210) rectangle (10,220); \draw (10,210) rectangle (45,220); \draw (45,210) rectangle (55,220); \draw (55,210) rectangle (65,220); \draw (65,210) rectangle (75,220); \draw (75,210) rectangle (85,220); \draw (85,210) rectangle (95,220); \draw (95,210) rectangle (110,220); \draw (110,210) rectangle (125,220); \draw (125,210) rectangle (140,220); \draw (0,200) rectangle (10,210); \draw (10,200) rectangle (45,210); \draw (45,200) rectangle (55,210); \draw (55,200) rectangle (65,210); \draw (65,200) rectangle (75,210); \draw (75,200) rectangle (85,210); \draw (85,200) rectangle (95,210); \draw (95,200) rectangle (110,210); \draw (110,200) rectangle (125,210); \draw (125,200) rectangle (140,210); \draw (0,190) rectangle (10,200); \draw (10,190) rectangle (45,200); \draw (45,190) rectangle (55,200); \draw (55,190) rectangle (65,200); \draw (65,190) rectangle (75,200); \draw (75,190) rectangle (85,200); \draw (85,190) rectangle (95,200); \draw (95,190) rectangle (110,200); \draw (110,190) rectangle (125,200); \draw (125,190) rectangle (140,200); \draw (0,180) rectangle (10,190); \draw (10,180) rectangle (45,190); \draw (45,180) rectangle (55,190); \draw (55,180) rectangle (65,190); \draw (65,180) rectangle (75,190); \draw (75,180) rectangle (85,190); \draw (85,180) rectangle (95,190); \draw (95,180) rectangle (110,190); \draw (110,180) rectangle (125,190); \draw (125,180) rectangle (140,190); \draw (0,170) rectangle (10,180); \draw (10,170) rectangle (45,180); \draw (45,170) rectangle (55,180); \draw (55,170) rectangle (65,180); \draw (65,170) rectangle (75,180); \draw (75,170) rectangle (85,180); \draw (85,170) rectangle (95,180); \draw (95,170) rectangle (110,180); \draw (110,170) rectangle (125,180); \draw (125,170) rectangle (140,180); \draw (0,160) rectangle (10,170); \draw (10,160) rectangle (45,170); \draw (45,160) rectangle (55,170); \draw (55,160) rectangle (65,170); \draw (65,160) rectangle (75,170); \draw (75,160) rectangle (85,170); \draw (85,160) rectangle (95,170); \draw (95,160) rectangle (110,170); \draw (110,160) rectangle (125,170); \draw (125,160) rectangle (140,170); \draw (0,150) rectangle (10,160); \draw (10,150) rectangle (45,160); \draw (45,150) rectangle (55,160); \draw (55,150) rectangle (65,160); \draw (65,150) rectangle (75,160); \draw (75,150) rectangle (85,160); \draw (85,150) rectangle (95,160); \draw (95,150) rectangle (110,160); \draw (110,150) rectangle (125,160); \draw (125,150) rectangle (140,160); \draw (0,140) rectangle (10,150); \draw (10,140) rectangle (45,150); \draw (45,140) rectangle (55,150); \draw (55,140) rectangle (65,150); \draw (65,140) rectangle (75,150); \draw (75,140) rectangle (85,150); \draw (85,140) rectangle (95,150); \draw (95,140) rectangle (110,150); \draw (110,140) rectangle (125,150); \draw (125,140) rectangle (140,150); \draw (0,130) rectangle (10,140); \draw (10,130) rectangle (45,140); \draw (45,130) rectangle (55,140); \draw (55,130) rectangle (65,140); \draw (65,130) rectangle (75,140); \draw (75,130) rectangle (85,140); \draw (85,130) rectangle (95,140); \draw (95,130) rectangle (110,140); \draw (110,130) rectangle (125,140); \draw (125,130) rectangle (140,140); \draw (0,120) rectangle (10,130); \draw (10,120) rectangle (45,130); \draw (45,120) rectangle (55,130); \draw (55,120) rectangle (65,130); \draw (65,120) rectangle (75,130); \draw (75,120) rectangle (85,130); \draw (85,120) rectangle (95,130); \draw (95,120) rectangle (110,130); \draw (110,120) rectangle (125,130); \draw (125,120) rectangle (140,130); \node at (4.7,215){\text{1044}}; \node at (28,215){\text{LCM}}; \node at (50,215){\text{3}}; \node at (60,215){\text{4}}; \node at (70,215){\text{5}}; \node at (80,215){\text{6}}; \node at (90,215){\text{7}}; \node at (103,215){\text{Total}}; \node at (118,215){\text{Done}}; \node at (133,215){\text{Work}}; \node at (5.6,205){\text{1.}}; \node at (36,205){\text{554400}}; \node at (50,205){\text{8}}; \node at (60,205){\text{30}}; \node at (70,205){\text{28}}; \node at (104,205){\text{66}}; \node at (90,205){\text{}}; \node at (5.6,195){\text{2.}}; \node at (35,195){\text{3880800}}; \node at (50,195){\text{8}}; \node at (60,195){\text{46}}; \node at (70,195){\text{60}}; \node at (80,195){\text{28}}; \node at (103,195){\text{142}}; \node at (133,195){\text{1}}; \node at (5.6,185){\text{3.}}; \node at (35,185){\text{6098400}}; \node at (50,185){\text{8}}; \node at (60,185){\text{46}}; \node at (70,185){\text{78}}; \node at (80,185){\text{48}}; \node at (103,185){\text{180}}; \node at (133,185){\text{1}}; \node at (5.6,175){\text{4.}}; \node at (34,175){\text{42688800}}; \node at (50,175){\text{8}}; \node at (60,175){\text{54}}; \node at (70,175){\text{94}}; \node at (80,175){\text{60}}; \node at (90,175){\text{10}}; \node at (103,175){\text{226}}; \node at (133,175){\text{2}}; \node at (5.6,165){\text{5.}}; \node at (32,165){\text{1331114400}}; \node at (50,165){\text{}}; \node at (60,165){\text{8}}; \node at (70,165){\text{30}}; \node at (80,165){\text{28}}; \node at (104,165){\text{66}}; \node at (118,165){\text{2}}; \node at (133,165){\text{1}}; \node at (5.6,155){\text{6.}}; \node at (32,155){\text{8116970400}}; \node at (50,155){\text{}}; \node at (60,155){\text{8}}; \node at (70,155){\text{26}}; \node at (80,155){\text{24}}; \node at (104,155){\text{58}}; \node at (133,155){\text{1}}; \node at (5.6,145){\text{7.}}; \node at (31,145){\text{14642258400}}; \node at (60,145){\text{8}}; \node at (70,145){\text{42}}; \node at (80,145){\text{66}}; \node at (90,145){\text{36}}; \node at (103,145){\text{152}}; \node at (118,145){\text{117}}; \node at (133,145){\text{1}}; \node at (5.6,135){\text{8.}}; \node at (31,135){\text{56818792800}}; \node at (60,135){\text{8}}; \node at (70,135){\text{38}}; \node at (80,135){\text{40}}; \node at (90,135){\text{10}}; \node at (104,135){\text{96}}; \node at (118,135){\text{96}}; \node at (5.6,125){\text{9.}}; \node at (28,125){\text{19488845930400}}; \node at (70,125){\text{8}}; \node at (80,125){\text{26}}; \node at (90,125){\text{24}}; \node at (104,125){\text{58}}; \node at (118,125){\text{58}}; }$

[EUgeneUS]

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

Статистика на сегодня пока что такая.

Это же по расчету программами Дмитрия (линейный перебор с ускорителями)?
Можно озвучить время расчета двух проверенных паттернов с $LCM=1331114400$ и количество проверямых чисел в них?

[VAL]

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

Разложил меньшее, как более лёгкое (ушло 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

Спасибо!
А Alpertron безуспешно бился более 16 (!) суток.

$M(816)\ge 8$

(Оффтоп)

n = 1382980070105341480535698212268007993225508457035132702993185357854929124873911094441369085670474422482528232017314867189287230020044960327148437498 
n+1 = 3^(16) * 31^(2) * 257987 * 206 273358 512447 * 25 381720 436126 794755 173204 526234 937271 (38 digits) * 24 750868 340529 932250 330084 332271 412631 944313 591722 316093 018511 737215 119011 283041 (80 digits)  
n+3  = 11^16 * 29^2 * 199 * 3247329743340031 (ECM, curve 26) * 62490811669823633351704046093101412109595175348813 (50 digits) * 886219559278001346562520682475998398317592139009542011378033 (60 digits)

[Yadryara]

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

Это же по расчету программами Дмитрия (линейный перебор с ускорителями)?

Да, старые исправленные проги от 4-го числа.

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

Можно озвучить время расчета двух проверенных паттернов с $LCM=1331114400$ и количество проверямых чисел в них?

По 6 проверяемых чисел:

LCM1331114400-761474745-7: end, time: 57016.599s

LCM1331114400-761474745-6: end, time: 55358.379s