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

[Huz]

Dmitriy40 Ok, I guess that's a limit on the number of processes you can run simultaneously then.

I doubt it will make a difference, but you could try running with "-Ls0" to suppress progress reports to the screen, and redirect console output to another file (or a null device), just to see if that stops it trying to allocate the console.

[Dmitriy40]

Obviously it will not help, the console is not only stdout (and strerr).

There is another problem, which is 100% repeatable: when I try to continue counting, it crashes with an error. Contents of D12n13-b1161.txt:

001 pcoul(12 13) -p200000 -f13 -g10 -x600000000000000000000000000 -b1161 *RT*
305 173^2 2^2.3 13^2 2.11^2 3.5^2 2^5 7^2 2.3^2 53^2 2^2.5 3.84017^5 2 97^2 (51509.37s)

Running the command:

C:\2>pcoul -f13 -v -x6e26 -g10 -p2e5 -b1161 -rD12n13-b1161.txt 12 13
path D12n13-b1161.txt
001 recover pcoul(12 13) -p200000 -f13 -g10 -x600000000000000000000000000 -b1161 *RT*
prep_nextt 2 for 84017^6 at 10

That is, it seems that the continuation with the fifth power glitches, always or sometimes.
In this case, the line about the startup appears in the file:

001 recover pcoul(12 13) -p200000 -f13 -g10 -x600000000000000000000000000 -b1161 *RT*

[Huz]

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

There is another problem, which is 100% repeatable: when I try to continue counting, it crashes with an error. Contents of D12n13-b1161.txt:

001 pcoul(12 13) -p200000 -f13 -g10 -x600000000000000000000000000 -b1161 *RT*
305 173^2 2^2.3 13^2 2.11^2 3.5^2 2^5 7^2 2.3^2 53^2 2^2.5 3.84017^5 2 97^2 (51509.37s)

Running the command:

C:\2>pcoul -f13 -v -x6e26 -g10 -p2e5 -b1161 -rD12n13-b1161.txt 12 13
path D12n13-b1161.txt
001 recover pcoul(12 13) -p200000 -f13 -g10 -x600000000000000000000000000 -b1161 *RT*
prep_nextt 2 for 84017^6 at 10

That is, it seems that the continuation with the fifth power glitches, always or sometimes.
In this case, the line about the startup appears in the file:

001 recover pcoul(12 13) -p200000 -f13 -g10 -x600000000000000000000000000 -b1161 *RT*

Bother, I thought I had fixed that. I'll check tomorrow to remind myself precisely what it means, but you can bypass it by editing the file to replace "3.84017^5" with "3". (I usually copy the line and edit the copy, to preserve the history.)

[Dmitriy40]

Yes, I did so, only corrected to the square (for reliability), well, it will count a little more, not too bad.

[Dmitriy40]

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

This is some little-understood problems with the Windows, this is what it says when you try to manually run one of the failed variant:

This seems to be a limitation of MSVC or cygwin1.dll, not Windows - there is nothing to stop other console applications from running in any quantity.

[Huz]

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

Bother, I thought I had fixed that.

Hmm, I still think I fixed that - can you confirm that you were using the latest release tagged 20230303? I can reproduce this "prep_nextt" problem with the previous release (20230208) but not with the latest.

[Dmitriy40]

Yes, 20230208 is what I use - the description for 20230303 says to fix bug only with -W, which I don't use. Accordingly, I did not think that these two versions may differ in behavior without -W.

[Huz]

Ah, my apologies, that bugfix is also relevant without -W. But generally it is always worth checking with the latest version, since I probably won't list every fixed bug or every small speed-up.

[Dmitriy40]

Yes, I know, I just forgot that I'm not using the latest version (I didn't want to stop and restart the long calculations). I looked at the list of differences and remembered that there is nothing important/necessary and therefore there is no point in bothering with restarting.

[Huz]

I have found two bugs that affect releases 20230208 and 20230303; please see issue 4 for details. The fixes will be in release 20230413, and I will ask DemIS to prepare Windows builds.

The first bug only affects use of a minimum prime (for example the 50 in "-p50:100").

The second bug is more general, but concerns a case that for most types of use is unlikely to be hit.

If you can give me one or more examples of command lines you have used with either of these releases, either here or by email, I will try to analyse whether the results could have been affected by either of these bugs.

My apologies for the errors.

[EUgeneUS]

Huz
Thanks for the info.
Do I understand correctly that these bugs are missing in earlier versions?

I have one thread running with the key -p50:200. But I'm using some old version from last year.

I would like to ask you, not in relation to the errors found:

1. Is it possible to change the keys -x and -p after recovery the calculation? f.e:
а) before recovery -x21e31, after recovery -x10e31
b) before recovery -x7e31:21e31, after recovery -x7e31:10e31
с) before recovery -p500, after recovery -p200
d) before recovery -p50:200, after recovery -p50:150

2. What are your current plans for the proof T(6,13)? Maybe as the BOINC project.

[Huz]

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

Huz
Thanks for the info.
Do I understand correctly that these bugs are missing in earlier versions?

Yes, the buggy function was introduced by commit 4368e146a4, dated 2023-02-08.

Цитата:

I would like to ask you, not in relation to the errors found:

1. Is it possible to change the keys -x and -p after recovery the calculation? f.e:
а) before recovery -x21e31, after recovery -x10e31
b) before recovery -x7e31:21e31, after recovery -x7e31:10e31
с) before recovery -p500, after recovery -p200
d) before recovery -p50:200, after recovery -p50:150

Generally, making it more restrictive should be fine, but note that changing the restrictions may change the batches it counts - I recommend checking with "-a" that the number of batches is the same with the old restrictions and the new restrictions. I think that would only happen with changes to "-x", not with changes to "-p", but hopefully it should be easy to check and be sure.

Цитата:

2. What are your current plans for the proof T(6,13)? Maybe as the BOINC project.

They are stalled right now: the intention was first to automate calibration for "-g" (and if possible for "-W") for optimal use, then to add BOINC support. But I got stuck on the first part, and the BOINC expert who had volunteered to help with the second part stopped responding. I expect to get back to both of those at some point, but have no specific timescale in mind.

For the last few days I've been looking at the related sequence A309981, which seems equally or even more interesting. The bugs I found today were spotted while trying to extend pcoul to support searches related to that sequence.

[EUgeneUS]

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

but note that changing the restrictions may change the batches it counts

It looks strange that changing these limits can lead to a change in the number of batches. I can't imagine why this is happening.
In any case, for the current calculations in an attempt to reduce the estimate T(6,14), in one thread the calculation of only one batch is started.

[Huz]

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

It looks strange that changing these limits can lead to a change in the number of batches. I can't imagine why this is happening.
In any case, for the current calculations in an attempt to reduce the estimate T(6,14), in one thread the calculation of only one batch is started.

If some batch would attempt to allocate, say, $7^{11}$, but that exceeds the maximum to be considered, then it will skip that one. Since it is not counted, the index of all the following batches will change.

Here's an example:

% ./pcoul -x1e9 -f11 -a 12 12 | grep ^203 | tail -1
203 b1001: . 2 3 2^2.7 5 2.3 . 2^3 3^5 2.5^2 7^2.11 2^2.3 [sq=2]
% ./pcoul -x1e18 -f11 -a 12 12 | grep ^203 | tail -1
203 b1485: . 2.11^2 3 2^2.7 5 2.3 . 2^3 3^5 2.5^2 7^5 2^2.3 [sq=2]
% ./pcoul -x1e27 -f11 -a 12 12 | grep ^203 | tail -1
203 b1485: . 2.11^2 3 2^2.7 5 2.3 . 2^3 3^5 2.5^2 7^5 2^2.3 [sq=2]
% 

So it would seem the batch list has stabilized by $10^{18}$, since $10^{27}$ gave the same count; but about one third of those batches are skipped when the limit is reduced to $10^9$.

[Huz]

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

I have found two bugs that affect releases 20230208 and 20230303; please see issue 4 for details. The fixes will be in release 20230413, and I will ask DemIS to prepare Windows builds.

Thanks DemIS, the Windows build is now available from the release page.