An unnecessary triple check ?

S485122 · 2008-09-20, 07:03

I have been assigned the exponent 18992531 for a double check. When I look in the V5 database I get the following result :

Unverified test results
Exponent,User name,Computer name,Residue,Error code (if any),Date found
18992531,C. Cooper / S. Boone,wde2610-21,2FF535C1CB3A92__,,
18992531,C. Cooper / S. Boone,hum115-009,2FF535C1CB3A92__,,

As far as can see the exponent IS already verified. Of course if both results where turned in with the same shift value, the second result cannot be counted as a verification. I regret the loss of shift data that is a consequence of the migration of the database to V5 (there where some 780000 results with and 250000 without such a value in the latest LUCAS_V.) There is the possibility that the data is still in the database but that it is intentionnally hidden.

Jacob

Mini-Geek · 2008-09-20, 11:29

Besides the shift value possibly being the same, it's possible that there's a difference in the last two hidden hex digits. I have to admit, that does seem pretty unlikely (with all other digits matching), but it is a possibility.

Brian-E · 2008-09-20, 11:50

Somewhere (sorry, I cannot remember where) I remember reading that an exponent must be independently re-checked by someone else if both completed LL-tests were completed by the same person - or, in this case, team of two. I did read that it would then be re-checked by specific machines at PrimeNet, but maybe the double testing by the same user is happening too frequently for that to be possible nowadays.

markr · 2008-09-20, 13:32

The last ever hrf3.txt (the old file of unverified LL results) from February has the same two results, so the v4 server also thought they didn't add up to a verified result.

Code:

18992531,curtisc,wde2610-21,WZ5,00000000
18992531,curtisc,hum115-009,WY5,00000000

Note that hrf3.txt didn't show shift values either; it's not just a v5 feature.

S00113 · 2008-09-22, 21:02

Quote:

Originally Posted by S485122

I have been assigned the exponent 18992531 for a double check. When I look in the V5 database I get the following result :

Unverified test results
Exponent,User name,Computer name,Residue,Error code (if any),Date found
18992531,C. Cooper / S. Boone,wde2610-21,2FF535C1CB3A92__,,
18992531,C. Cooper / S. Boone,hum115-009,2FF535C1CB3A92__,,

As far as can see the exponent IS already verified.

Both results were returned by the same person(s). In theory, since they had access to the first result, they could be cheating by reurning the same result again. For this reason GIPMS should not trust a double check done by the same person who did the first time check. It must be a bug which caused the double check assignment to go to the same tester in the first place.

cheesehead · 2008-09-22, 21:39

Quote:

Originally Posted by S00113

Both results were returned by the same person(s). In theory, since they had access to the first result, they could be cheating by reurning the same result again.

True.

Of course, a far more common reason is that users who are running lots of computers, like Cooper/Boone, occasionally accidentally duplicate a worktodo line on different systems.

Quote:

For this reason GIPMS should not trust a double check done by the same person who did the first time check.

... regardless of the reason for, or suspicion about, duplication.

Quote:

It must be a bug which caused the double check assignment to go to the same tester in the first place.

In the absence of data about the particular PrimeNet assignments involved, another possibility is that these were both, from the viewpoint of the systems running them, first-time tests -- neither was assigned as a double check. It's possible that PrimeNet actually made only one assignment, as a first-time test, to computer ID 'wde2610-21', then, on the Cooper/Boone end, some mistake caused computer 'hum115-009' to get a duplicate line in its worktodo.

Or it could have been that after 'wde2610-21' finished and reported its result, that computer failed, and Cooper/Boone then re-allocated its entire list of assignments, both completed and uncompleted, to system 'hum115-009' with only good intentions: in order to be sure that each test was successfully completed and reported.

PrimeNet won't reject any result report just because it's from a computer to which it had not assigned that exponent. It just won't credit that result to that user on the PrimeNet Top Producers list at http://mersenne.org/ips/tops.shtml (not to be confused with the GIMPS Top Producers list at http://www.mersenne.org/top.htm).

S485122 · 2008-09-23, 05:02

With a team like Cooper/Boone I see one other and much simpler posibility : they were assigned the exponent as a first time check and some years later the exponent was assigned to them as a double check. I do not think PrimeNet verifies if the computer requesting doublecheck workunits is member of a team that already did the first time check pn the numbers it assigns.

Jacob

Uncwilly · 2008-09-23, 05:06

Quote:

Originally Posted by S485122

With a team like Cooper/Boone I see one other and much simpler posibility : they were assigned the exponent as a first time check and some years later the exponent was assigned to them as a double check. I do not think PrimeNet verifies if the computer requesting doublecheck workunits is member of a team that already did the first time check pn the numbers it assigns.

Something for the v5 server wishlist.

Prime95 · 2008-09-23, 22:24

Quote:

Originally Posted by S485122

Exponent,User name,Computer name,Residue,Error code (if any),Date found
18992531,C. Cooper / S. Boone,wde2610-21,2FF535C1CB3A92__,,
18992531,C. Cooper / S. Boone,hum115-009,2FF535C1CB3A92__,,

As far as can see the exponent IS already verified.

The shift count was identical. The run started on one computer and finished on two different computers. Not good enough to count as a double-check.

mdettweiler · 2008-09-24, 13:41

Somewhat off-topic, but still related to the topic of extra unnecessary re-checks of exponents: just curious, if I was to do a doublecheck via V5, would V4 eventually do an unnecessary triple-check, since it won't be aware of the fact that it was previously done in V5? (Specifically, that is, if I was to pick out a particular exponent by hand--i.e., it's not in any "special" range that one server or the other has been pre-warned not to hand out?)

2008-09-20, 07:03	#1
S485122 Sep 2006 Brussels, Belgium 6A7₁₆ Posts	An unnecessary triple check ? I have been assigned the exponent 18992531 for a double check. When I look in the V5 database I get the following result : Unverified test results Exponent,User name,Computer name,Residue,Error code (if any),Date found 18992531,C. Cooper / S. Boone,wde2610-21,2FF535C1CB3A92__,, 18992531,C. Cooper / S. Boone,hum115-009,2FF535C1CB3A92__,, As far as can see the exponent IS already verified. Of course if both results where turned in with the same shift value, the second result cannot be counted as a verification. I regret the loss of shift data that is a consequence of the migration of the database to V5 (there where some 780000 results with and 250000 without such a value in the latest LUCAS_V.) There is the possibility that the data is still in the database but that it is intentionnally hidden. Jacob

2008-09-20, 13:32	#4
markr "Mark" Feb 2003 Sydney 3×191 Posts	The last ever hrf3.txt (the old file of unverified LL results) from February has the same two results, so the v4 server also thought they didn't add up to a verified result. Code: 18992531,curtisc,wde2610-21,WZ5,00000000 18992531,curtisc,hum115-009,WY5,00000000 Note that hrf3.txt didn't show shift values either; it's not just a v5 feature.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Triple check required	houding	PrimeNet	14	2015-12-21 09:34
mprime ROUND OFF ERROR: Triple-check advised?	Bdot	Software	5	2012-12-22 22:34
same exponent reassigned for triple-check	S485122	PrimeNet	8	2009-08-16 23:16
First check and double check llrnet servers.	opyrt	Prime Sierpinski Project	3	2009-01-02 01:50
Two priority triple-check exponents	GP2	Completed Missions	13	2004-08-12 00:41

2008-09-20, 11:29	#2
Mini-Geek Account Deleted "Tim Sorbera" Aug 2006 San Antonio, TX USA 17×251 Posts	Besides the shift value possibly being the same, it's possible that there's a difference in the last two hidden hex digits. I have to admit, that does seem pretty unlikely (with all other digits matching), but it is a possibility.

2008-09-20, 11:50	#3
Brian-E "Brian" Jul 2007 The Netherlands 7×467 Posts	Somewhere (sorry, I cannot remember where) I remember reading that an exponent must be independently re-checked by someone else if both completed LL-tests were completed by the same person - or, in this case, team of two. I did read that it would then be re-checked by specific machines at PrimeNet, but maybe the double testing by the same user is happening too frequently for that to be possible nowadays.

2008-09-23, 05:02	#7
S485122 Sep 2006 Brussels, Belgium 13·131 Posts	With a team like Cooper/Boone I see one other and much simpler posibility : they were assigned the exponent as a first time check and some years later the exponent was assigned to them as a double check. I do not think PrimeNet verifies if the computer requesting doublecheck workunits is member of a team that already did the first time check pn the numbers it assigns. Jacob

2008-09-24, 13:41	#10
mdettweiler A Sunny Moo Aug 2007 USA (GMT-5) 3×2,083 Posts	Somewhat off-topic, but still related to the topic of extra unnecessary re-checks of exponents: just curious, if I was to do a doublecheck via V5, would V4 eventually do an unnecessary triple-check, since it won't be aware of the fact that it was previously done in V5? (Specifically, that is, if I was to pick out a particular exponent by hand--i.e., it's not in any "special" range that one server or the other has been pre-warned not to hand out?)