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

[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