mersenneforum.org PRPNet 5.4.3 Released
 Register FAQ Search Today's Posts Mark Forums Read

2020-07-05, 13:00   #155
rogue

"Mark"
Apr 2003
Between here and the

22·7·11·19 Posts

Quote:
 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:

Code:
+---------------------+------------+-----------+-----------+---------------------+------------+------------------+---------------+----------------+----------------------+-----------------------+----------------+------------------------+
| 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?

 2020-07-05, 13:16 #156 Happy5214     "Alexander" Nov 2008 The Alamo City 33×13 Posts 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.
2020-07-05, 15:00   #157
rogue

"Mark"
Apr 2003
Between here and the

22×7×11×19 Posts

Quote:
 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.

2020-07-05, 15:35   #158
Happy5214

"Alexander"
Nov 2008
The Alamo City

15F16 Posts

Quote:
 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).

Last fiddled with by Happy5214 on 2020-07-05 at 15:36 Reason: Quote

2020-07-05, 18:40   #159
rogue

"Mark"
Apr 2003
Between here and the

22·7·11·19 Posts

Quote:
 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.

2020-07-07, 09:03   #160
Happy5214

"Alexander"
Nov 2008
The Alamo City

33×13 Posts

Quote:
 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).

2020-07-07, 11:59   #161
rogue

"Mark"
Apr 2003
Between here and the

10110110111002 Posts

Quote:
 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.

2020-07-11, 11:25   #162
Happy5214

"Alexander"
Nov 2008
The Alamo City

5378 Posts

Quote:
 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.
Attached Files
 PRP_LLR.log (26.6 KB, 7 views)

2020-07-11, 12:48   #163
rogue

"Mark"
Apr 2003
Between here and the

22×7×11×19 Posts

Quote:
 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:

Code:
   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.

2020-07-11, 14:51   #164
Happy5214

"Alexander"
Nov 2008
The Alamo City

33×13 Posts

Quote:
 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).

 Similar Threads Thread Thread Starter Forum Replies Last Post ltd Prime Sierpinski Project 86 2012-06-06 02:30 rogue Software 84 2011-11-16 21:20 Joe O Sierpinski/Riesel Base 5 1 2010-10-22 20:11 rogue Conjectures 'R Us 220 2010-10-12 20:48 rogue Conjectures 'R Us 250 2009-12-27 21:29

All times are UTC. The time now is 04:41.

Wed Aug 12 04:41:32 UTC 2020 up 26 days, 28 mins, 1 user, load averages: 2.33, 1.99, 1.96