PRPNet 5.5 Released

[Happy5214]

Jean released LLR 3.8.24 yesterday (https://www.mersenneforum.org/showthread.php?t=25701), and Riesel prime tests now default to PRP, only running an LLR test if the PRP test passes. I can't upgrade my PRPNet client's LLR version, even though it would benefit from the added error checking, because it would render the old LLR residues already on the servers incompatible with the new PRP residues which the program would generate. Would there be a way to make PRPNet compatible with LLR 3.8.24? I'd imagine it would need to distinguish PRP residues from LLR residues in the DB.

[rogue]

Originally Posted by Happy5214

Jean released LLR 3.8.24 yesterday (https://www.mersenneforum.org/showthread.php?t=25701), and Riesel prime tests now default to PRP, only running an LLR test if the PRP test passes. I can't upgrade my PRPNet client's LLR version, even though it would benefit from the added error checking, because it would render the old LLR residues already on the servers incompatible with the new PRP residues which the program would generate. Would there be a way to make PRPNet compatible with LLR 3.8.24? I'd imagine it would need to distinguish PRP residues from LLR residues in the DB.

In the database it stores the name and version of the program that completed the PRP test:

+---------------------+------------+-----------+-----------+---------------------+------------+------------------+---------------+----------------+----------------------+-----------------------+----------------+------------------------+
| CandidateName       | TestID     | TestIndex | WhichTest | TestedNumber        | TestResult | Residue          | PRPingProgram | ProvingProgram | PRPingProgramVersion | ProvingProgramVersion | SecondsForTest | CheckedGFNDivisibility |
+---------------------+------------+-----------+-----------+---------------------+------------+------------------+---------------+----------------+----------------------+-----------------------+----------------+------------------------+
| 60205462*66^11006-1 | 1592742375 |         0 | Main      | 60205462*66^11006-1 |          0 | 887C4F7FD01A5D2A | llr64         | na             | 3.8.23               | na                    |          1.387 |                      0 |
+---------------------+------------+-----------+-----------+---------------------+------------+------------------+---------------+----------------+----------------------+-----------------------+----------------+------------------------+

If PRPNet is capturing the residue, program name, and version for llr 3.8.24, what else do you need it to do?

Or are you saying it is not capturing this detail? Or are you saying that it captures it incorrectly?

[Happy5214]

LLR 3.8.24 residues (PRP) are incompatible with residues from earlier versions of LLR (LLR), which makes double-checking LLR residues with the new version impossible unless I can force the new version to run an LLR test instead of a PRP test, a setting which I don't see and would anyway defeat the purpose of upgrading.

[rogue]

Originally Posted by Happy5214

LLR 3.8.24 residues (PRP) are incompatible with residues from earlier versions of LLR (LLR), which makes double-checking LLR residues with the new version impossible unless I can force the new version to run an LLR test instead of a PRP test, a setting which I don't see and would anyway defeat the purpose of upgrading.

I don't know how I could possibly address this. If the new version of llr is outputting different residues, how is PRPNet supposed to compare the new residues to the old residues to verify that the test results match?

If there is a command line option to llr to generate different residues, then specify that in prpclient.ini. In other words instead of "llr.exe" use "llr.exe -xxx" where xxx is the command line option.

[Happy5214]

Originally Posted by rogue

I don't know how I could possibly address this. If the new version of llr is outputting different residues, how is PRPNet supposed to compare the new residues to the old residues to verify that the test results match?

If there is a command line option to llr to generate different residues, then specify that in prpclient.ini. In other words instead of "llr.exe" use "llr.exe -xxx" where xxx is the command line option.

I've asked in the LLR thread whether I can force an LLR test.

Does the client know if it's doing a double-check and, if so, does it know the version that did the original test? We could flag residues from the new version as being either LLR or PRP, assume all earlier LLR versions output LLR residues, and direct the client to pass the appropriate argument to LLR (if such an argument exists).

[rogue]

Originally Posted by Happy5214

I've asked in the LLR thread whether I can force an LLR test.

Does the client know if it's doing a double-check and, if so, does it know the version that did the original test? We could flag residues from the new version as being either LLR or PRP, assume all earlier LLR versions output LLR residues, and direct the client to pass the appropriate argument to LLR (if such an argument exists).

I believe the client knows if it is a double-check, but has no knowledge of the first test.

[Happy5214]

From the LLR thread:

Originally Posted by Jean Penné

Yes, indeed! You have only to set -oErrorChecking=0 in the command line.
Then, the PRP testing in not done, except if the k multiplier length is more than 10% of the length of the number tested.
Regards,
Jean

How much work would it be to pass the program name and version to the client with the double-check, letting the client determine which program and parameters to use? I'd imagine it would have utility apart from this (e.g. ensuring PFGW results are checked with PFGW instead of LLR, avoiding a triple-check).

[rogue]

Originally Posted by Happy5214

How much work would it be to pass the program name and version to the client with the double-check, letting the client determine which program and parameters to use? I'd imagine it would have utility apart from this (e.g. ensuring PFGW results are checked with PFGW instead of LLR, avoiding a triple-check).

Right now it isn't the client's decision. Before this new release of llr, there were no issues in comparing residues between llr and pfgw of different versions of llr. Forcing the client to use one option or the other isn't trivial until the llr output has some indication that it is outputting the new residue instead of the old. If so then the client could communicate that to the server and the server could echo back to the client when double-checking. It probably isn't a huge amount of work, but isn't high on my priority list.

All I can suggest for now is that you add the command line option in the prpclient.ini file so that they are always compatible regardless of the version of llr. When you get to a point where you need to load a new server or add more candidates, remove the command line option.

[Happy5214]

Originally Posted by rogue

Right now it isn't the client's decision. Before this new release of llr, there were no issues in comparing residues between llr and pfgw of different versions of llr. Forcing the client to use one option or the other isn't trivial until the llr output has some indication that it is outputting the new residue instead of the old. If so then the client could communicate that to the server and the server could echo back to the client when double-checking. It probably isn't a huge amount of work, but isn't high on my priority list.

After some testing, I've found that the PRP residues are denoted by "RES64", while the LLR residues are denoted by "LLR Res64", as displayed in the attached log. The console output is similar.

[rogue]

Originally Posted by Happy5214

After some testing, I've found that the PRP residues are denoted by "RES64", while the LLR residues are denoted by "LLR Res64", as displayed in the attached log. The console output is similar.

Are you saying that the client isn't finding the correct residue?

If you look at LLRProgram.cpp, it has this code to find the residue:

   while (!strstr(line, "probable prime") && !strstr(line, "is prime") && !strstr(line, "RES64") &&
          !strstr(line, "Res64") && !strstr(line, "Fermat PRP") &&
          !strstr(line, "composite") && !strstr(line, "small factor"))

It is possible that this needs to be adjusted.

[Happy5214]

Originally Posted by rogue

Are you saying that the client isn't finding the correct residue?

I haven't actually tried it with the client yet. I was responding to your comment on how the client could distinguish between PRP residues and LLR residues (the bolded part of the quote).