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

[VAL]

Еще 3 ласточки для статистики:
21135461977802037026679975877947772766510933212316777041
70437172728442738145826233107972019231551263680606378641
186343812137685490861073791408013792663482136579483490841

[EUgeneUS]

Huz

Thanks for the advice!
The first option didn't work because the batch contained $2^8$ and $3^8$, and pcoul simply refused to calculate it.
The second option worked, and pcoul seems to be calculating as I want.
Furthermore, I discovered I was using the wrong batch and replaced it.
Now the startup line are:

pcoul -x5e70 -r36-14log-5 -p83 "-px1^5,3^8,1^11,1^17,1^35" -g1 -f13 36 14

and the beginning of the log file is:

(Оффтоп)

305 b0: 3^8 2.7^2 13^2 2^2.3 5 2.11^2 3 2^8 7 2.3^2.5^2 . 2^2 3 2
001 pcoul(36 14) -p83 -px1^5,3^8,1^11,1^17,1^35 -f13 -x50000000000000000000000000000000000000000000000000000000000000000000000 *RT*
305 b0: 3^8 2.7^2.61^2 13^2.43^2 2^2.3.73^2 5.23^2.41^2 2.11^2.59^2 3.29^2.79^2 2^8 7.19^2.83^2 2.3^2.5^2 17^2.67^2 2^2.71^2 3.31^2.47^2 2.37^2.53^2 (580.67s) [41193673 69594 5989 494 48 4 0 0 0 0 0 0 0 0]
305 b0: 3^8 2.7^2.73^2 13^2.59^2 2^2.3.37^2 5.23^2.71^2 2.11^2.61^2 3.29^2.47^2 2^8 7.19^2.83^2 2.3^2.5^2 17^2.43^2 2^2.53^2 3.31^2.79^2 2.41^2.67^2: 5 / 6 (1160.83s) [82316866 139160 11924 1023 94 9 2 0 0 0 0 0 0 0]
305 b0: 3^8 2.7^2 13^2.37^2 2^2.3 5.23^2.83^2 2.11^2 3.29^2.71^2 2^8 7.19^2.53^2 2.3^2.5^2 17^2.73^2 2^2.61^2 3.31^2.79^2 2.41^2.67^2 (1742.28s) [122784099 207527 17746 1523 141 13 2 0 0 0 0 0 0 0]
305 b0: 3^8 2.7^2.59^2 13^2.79^2 2^2.3 5.23^2.73^2 2.11^2.83^2 3.29^2.61^2 2^8 7.19^2.47^2 2.3^2.5^2 17^2.53^2 2^2.37^2 3.31^2.71^2 2.43^2.67^2 (2320.12s) [162250295 274171 23419 2024 192 17 2 0 0 0 0 0 0 0]
305 b0: 3^8 2.7^2.79^2 13^2.41^2 2^2.3 5.23^2.61^2 2.11^2.67^2 3.29^2.73^2 2^8 7.19^2.71^2 2.3^2.5^2 17^2.37^2 2^2.59^2 3.31^2.53^2 2.47^2.83^2 (2894.33s) [200922602 339315 29104 2503 230 19 3 0 0 0 0 0 0 0]
305 b0: 3^8 2.7^2.41^2 13^2.79^2 2^2.3.53^2 5.23^2.37^2 2.11^2.73^2 3.29^2.59^2 2^8 7.19^2.43^2 2.3^2.5^2 17^2.71^2 2^2.83^2 3.31^2.67^2 2.47^2.61^2: 5 / 6 (3470.08s) [239739793 405386 34723 2986 283 23 3 0 0 0 0 0 0 0]

But I have new questions.
1. The log file contains two types of lines.
a)

(Оффтоп)

305 b0: 3^8 2.7^2.73^2 13^2.59^2 2^2.3.37^2 5.23^2.71^2 2.11^2.61^2 3.29^2.47^2 2^8 7.19^2.83^2 2.3^2.5^2 17^2.43^2 2^2.53^2 3.31^2.79^2 2.41^2.67^2: 5 / 6 (1160.83s) [82316866 139160 11924 1023 94 9 2 0 0 0 0 0 0 0]

I understand this line, and everything works as expected.

b)

(Оффтоп)

305 b0: 3^8 2.7^2.59^2 13^2.79^2 2^2.3 5.23^2.73^2 2.11^2.83^2 3.29^2.61^2 2^8 7.19^2.47^2 2.3^2.5^2 17^2.53^2 2^2.37^2 3.31^2.71^2 2.43^2.67^2 (2320.12s) [162250295 274171 23419 2024 192 17 2 0 0 0 0 0 0 0]

Here, in one position (

2^2.3

), the square of a prime number is missing.
What does this mean? How does pcoul work in this case?

2. Which -g and -j launch keys would you recommend to speed up pcoul in this launch mode?

[Huz]

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

Huz

Thanks for the advice!

(Оффтоп)

Цитата:

The first option didn't work because the batch contained $2^8$ and $3^8$, and pcoul simply refused to calculate it.

Hmm, that's odd, sounds like a bug - I will have to look into it. Fixed primes should not be affected by -p options. Can you show me the exact command-line you used for that case?

Цитата:

305 b0: 3^8 2.7^2.59^2 13^2.79^2 2^2.3 5.23^2.73^2 2.11^2.83^2 3.29^2.61^2 2^8 7.19^2.47^2 2.3^2.5^2 17^2.53^2 2^2.37^2 3.31^2.71^2 2.43^2.67^2 (2320.12s) [162250295 274171 23419 2024 192 17 2 0 0 0 0 0 0 0]

Here, in one position ("2^2.3"), the square of a prime number is missing.
What does this mean? How does pcoul work in this case?

It just shows what is allocated at the instant of reporting. When it has tried all the allocations at one position, it removes the last allocation and tries the next value at the previous level of recursion. So in this case it has just done that, and has not yet allocated a new value in the fourth position.

Цитата:

2. Which -g and -j launch keys would you recommend to speed up pcoul in this launch mode?

It probably won't make much difference with a small -p like this, and specifically it will make no difference if it always allocates all the available squares.

For $n=36$ which has a repeated odd prime factor, I would always use '-j2': this will prefer to allocate where the remaining number of divisors is lowest, so it will allocate a second square in $2.17^2$ before allocating a first square in $2$. For situations where not every square is allocated, this is faster since there are only half as many combinations of $(p^2q^2, 1)$ as there are of $(p^2, q^2)$.

For the '-g' option you can try a few values in a short run to see if they make any difference - I would start with some powers of 10 like '-g1', '-g10', 'g100' and maybe '-g10:', '-g100:' (which are effectively 1/10, 1/100), and if you see an actual difference try to refine it from there. Again, it will make a difference only by changing whether all the available squares are allocated before trying to walk: it will walk earlier (and therefore allocate less) when '-g' is smaller.

[EUgeneUS]

Huz
Thank you!

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

Hmm, that's odd, sounds like a bug - I will have to look into it. Fixed primes should not be affected by -p options. Can you show me the exact command-line you used for that case?

I'll try to repeat this, but a little later, maybe on the weekend.

[VAL]

Очередные ласточки:
18952352870980595522257690923038215596226439375542293841
54477862119775232999131041680369052347455001037201794641

[Yadryara]

Уважаемые господа итераторы Ежели таковые тут есть.

Демис нашёл ещё одну дрофу А впс, тестируя новёхонькую прогу, нашёл самую настоящую двадцаточку. Непрерывную и на порядок меньше единственной известной до этого. Обе 20-ки показал внизу.

Start                                                  Location              Valids
91961526307286709380597649336434597932204049205291537  1111111111111111111111    22  Na

52556626259340931919271848023566857910792017169        111111111111111111111     21  An
953053682563059391009495134514684931986461616262041    1111111111111 11111111    21  An
1328766570318407148648043882346041718157664490666641   11111111111 1111111111    21  De
2266980202621739730115894445902081013987272845487441   1111111111111111 11111    21  Vl
2550753441024057082514762312963741224747964954721938   111111111111111 111111    21  De
2688473770797955760939553844723490761611048797755538   1 11111111111111111111    21  De
51521500527643954131531898942025036268191023083065041  111111111111111 111111    21  Vl
52675007895915990003494373421520559128421574224871441  1111111111111111 11111    21  Vl

1343688799116140536185862959273033940943830770546841   11111111111111111111      20  An
17668887847524548413038893976018715843277693308027547  11111111111111111111      20  Vl

[VAL]

Еще парочка ласточек:
15201744745831553574932530993096117888755326977972433041
117307911562154778103634907404435656648602031136514871441

Мне понравилась примирительная между покерной и орнитологической терминология с дрофами.
Только вот сами дрофы куда-то исчезли Так что, возможно, точнее будет дронты

[Yadryara]

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

Так что, возможно, точнее будет дронты

Дронтозавры

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

Только вот сами дрофы куда-то исчезли

Так вот же они выше, целых 8 штук.

А о ласточках я уже и не рассказываю и пока тщательно не считаю, ибо их полным-полно, около полусотни.

Это в поиске D(48,22). А поиск D(48,23), как очень трудный, лучше делать коллективно.

[EUgeneUS]

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

Hmm, that's odd, sounds like a bug - I will have to look into it. Fixed primes should not be affected by -p options. Can you show me the exact command-line you used for that case?

I tried to reproduce the error I reported earlier. Apparently, I misinterpreted pcoul's behavior.

I observed three behavioral patterns:
1. Refusal to perform calculations with a diagnostic indicating that the first line of the log file cannot be parsed.

2. Start the calculation, but ignore the first line. The first specified line in the log file is deleted. The calculation starts again, but from a completely different batch.

3. Normal start of calculation with the batch specified in the first line.

These behaviors are independent of the -p option and do not depend on whether a valid batch is specified.
Apparently, it depends on the special characters that end the first line.

If a bad batch is specified that requires more prime squares than allowed by the -p option, then the calculation starts without finding any candidates - as can be seen in the log file.

Examples of log files:

(Оффтоп)

1. Bad batch, normal start:

305 b0: 2.7^2 . 2^2.3 11^2 2.5^2 3.13^2 2^8 7 2.3^8 5 2^2 3 2 .
001 pcoul(36 14) -p1 -px85^2 -f13 -x500000000000000000000000000000000000000000000000000000000000000000000000 *RT*
305 b0: 2.7^2.79^2 17^2.47^2 2^2.3 11^2.37^2 2.5^2.71^2 3.13^2.53^2 2^8 7.23^2.73^2 2.3^8 5.29^2.59^2 2^2.83^2 3.31^2.61^2 2.41^2.43^2 19^2.67^2 (581.75s) [0 0 0 0 0 0 0 0 0 0 0 0 0 0]

2. Correct batch, normal start:

305 b0: 3^8 2.7^2 13^2 2^2.3 5 2.11^2 3 2^8 7 2.3^2.5^2 . 2^2 3 2
001 pcoul(36 14) -p1 -px85^2 -f13 -x500000000000000000000000000000000000000000000000000000000000000000000000 *RT*
305 b0: 3^8 2.7^2.71^2 13^2.47^2 2^2.3.61^2 5.23^2.59^2 2.11^2.41^2 3.29^2.67^2 2^8 7.19^2.73^2 2.3^2.5^2 17^2.43^2 2^2.83^2 3.31^2.79^2 2.37^2.53^2: 18 / 74 (581.95s) [80226972 133591 11093 946 78 9 1 0 0 0 0 0 0 0]

3. Ignore the first line and remove it from the log file. Just the very beginning:

001 pcoul(36 14) -p1 -px85^2 -f13 -x500000000000000000000000000000000000000000000000000000000000000000000000 *RT*

In all cases the launch line is:

pcoul -x5e71 -rlog -p1 "-px85^2" -g1 -f13 36 14

[VAL]

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

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

Так что, возможно, точнее будет дронты

Дронтозавры

"Завров" добавлять не обязательно. Дронты "благополучно" вымерли и без них.

Цитата:

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

Только вот сами дрофы куда-то исчезли

Так вот же они выше, целых 8 штук.

А о ласточках я уже и не рассказываю и пока тщательно не считаю, ибо их полным-полно, около полусотни.

Разумеется, речь о D(48,23)

Цитата:

Это в поиске D(48,22). А поиск D(48,23), как очень трудный, лучше делать коллективно.

А кто против?
Я ведь заранее указал, что беру только комплекты 16-19-14, 8-7-14 и 8-22-14 из класса 1-1-17-4(11) ( указаны позиции чисел 32, 121 и 169), чтобы другие могли подключиться, не дублируя.

Но, пожалуй, пока никто занял другие комплекты, я расширю свой выбор. Пусть это будут, например, комплекты 16-22-14 и 8-18-14.

Почему так много. Дело в том, что практически договорился о выделении мне еще порядка 70 потоков.
Осталось только утрясти технические аспекты. Конечно, этот процесс может затянуться, но я оптимист.

PS: Для D(48,23) (в отличие от D(48,22)) указание позиций лишь двух чисел 16 и 121 может привести к путанице (зеркальный паттерн для 16-22, начинается с 8-2, не совпадая при этом с другим). Поэтому для D(48,23) удобно маркировать комплекты не двумя, а тремя числами, указывая позиции 32, 121 и 169. При этом можно не использовать зеркальность, а считать все комплекты равноправными.
Переобозначил выбранные комплекты в соответствии с этим замечанием.

PPS: Надеюсь, в PS я нигде не ошибся, но хорошо бы это проверить.

[Yadryara]

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

PPS: Надеюсь, в PS я нигде не ошибся, но хорошо бы это проверить.

Не проверял, но есть серьёзное подозрение, что Вы ошиблись с крупным шрифтом:

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

из класса 1-1-17-4(10)

Уверены что 10, а не 11! ?

Всё ж таки не вручную посчитано:

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

Показанная серия паттернов вроде лучшая: 1-1-17-4-11! То есть тоже 162 комплекта

[VAL]

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

Уверены что 10, а не 11! ?

Уверен,.. что 11

[Huz]

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

I observed three behavioral patterns:
1. Refusal to perform calculations with a diagnostic indicating that the first line of the log file cannot be parsed.

That sounds like correct behaviour.

Цитата:

2. Start the calculation, but ignore the first line. The first specified line in the log file is deleted. The calculation starts again, but from a completely different batch.

If the last text in the log file does not end in a newline character (ASCII 0x0a), I assume this is a partial line written before a crash, and remove it. I guess it would be possible to make an exception for the very first line; however I am currently testing substantial fixes to the '-I' parameter, and if that works as intended the intention is that you should not need to manipulate log files at all.

Цитата:

If a bad batch is specified that requires more prime squares than allowed by the -p option, then the calculation starts without finding any candidates - as can be seen in the log file.

It seems this is just normal behaviour: it comes to the 18th allocation, intends to allocate unused primes in the range $(17, 85)$, asks for the next available prime and finds that it has completed the range, so it de-recurses and tries something else. It will keep doing that until it has exhausted the $17!$ permutations of the available primes in the first 17 allocations.
I will think about whether there is some way for it to detect this situation without uselessly cycling through all the permutations; but maybe easier would be for the console display (optionally) to include the stats, so that you can easily see it is not doing anything useful without having to wait for the logs to appear.

Hugo

[Yadryara]

Мастодронт нашёлся

2360057651230701547259149734429258634439690624634841

[Yadryara]

И ещё один. Такой же: с пропуском на 4-и месте. Таким образом, их уже 10 штук.

Start                                                  Location              Valids
91961526307286709380597649336434597932204049205291537  1111111111111111111111    22  Na

52556626259340931919271848023566857910792017169        111111111111111111111     21  An
953053682563059391009495134514684931986461616262041    1111111111111 11111111    21  An
1328766570318407148648043882346041718157664490666641   11111111111 1111111111    21  De
2266980202621739730115894445902081013987272845487441   1111111111111111 11111    21  Vl
2360057651230701547259149734429258634439690624634841   111 111111111111111111    21  An
2550753441024057082514762312963741224747964954721938   111111111111111 111111    21  De
2688473770797955760939553844723490761611048797755538   1 11111111111111111111    21  De
6409631199918333339130693117319740331089755273738841   111 111111111111111111    21  An
51521500527643954131531898942025036268191023083065041  111111111111111 111111    21  Vl
52675007895915990003494373421520559128421574224871441  1111111111111111 11111    21  Vl