mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2020-07-05, 13:00   #155
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

22·7·11·19 Posts
Default

Quote:
Originally Posted by Happy5214 View Post
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?
rogue is online now   Reply With Quote
Old 2020-07-05, 13:16   #156
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

1010111112 Posts
Default

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.
Happy5214 is offline   Reply With Quote
Old 2020-07-05, 15:00   #157
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

133348 Posts
Default

Quote:
Originally Posted by Happy5214 View Post
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.
rogue is online now   Reply With Quote
Old 2020-07-05, 15:35   #158
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

33·13 Posts
Default

Quote:
Originally Posted by rogue View Post
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
Happy5214 is offline   Reply With Quote
Old 2020-07-05, 18:40   #159
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

22×7×11×19 Posts
Default

Quote:
Originally Posted by Happy5214 View Post
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.
rogue is online now   Reply With Quote
Old 2020-07-07, 09:03   #160
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

33×13 Posts
Default

From the LLR thread:

Quote:
Originally Posted by Jean Penné View Post
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).
Happy5214 is offline   Reply With Quote
Old 2020-07-07, 11:59   #161
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

10110110111002 Posts
Default

Quote:
Originally Posted by Happy5214 View Post
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.
rogue is online now   Reply With Quote
Old 2020-07-11, 11:25   #162
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

33×13 Posts
Default

Quote:
Originally Posted by rogue View Post
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
File Type: log PRP_LLR.log (26.6 KB, 7 views)
Happy5214 is offline   Reply With Quote
Old 2020-07-11, 12:48   #163
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

16DC16 Posts
Default

Quote:
Originally Posted by Happy5214 View Post
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.
rogue is online now   Reply With Quote
Old 2020-07-11, 14:51   #164
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

33·13 Posts
Default

Quote:
Originally Posted by rogue View Post
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).
Happy5214 is offline   Reply With Quote
Reply

Thread Tools


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

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

Wed Aug 12 04:04:22 UTC 2020 up 25 days, 23:51, 1 user, load averages: 2.17, 2.52, 2.33

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.