"Verified" LLs with non-matching short residues?

[cheesehead]

Generally, an LL result listed as "Verified LL" (in the "Exponent Status" report, anyway) means that the reported residue matches one or more reported residues from other LL tests on the same exponent. Similarly, an LL result listed as "Bad LL" means that its residue does not match any residue from another LL test on the same exponent. Right?

So, for a given exponent, all the residues for "Verified LL" should match each other -- right?

And the residues reported by GIMPS software to PrimeNet should all be sixteen hexadecimal digits -- right? Shorter residues are from an earlier era -- right?

I just came across this in the Exponent Status report for 1800767:

Verified LL 153BED18D5C5EA4B by "Matt Hicks" 
Verified LL 6A4C by "Alex and Nick Myrman" 
Verified LL 153BED18D5C5EA4B by "S57483"

and this for 1800959:

Verified LL 8EB3906BE7510354 by "Oyvind Pedersen" 
Verified LL 355 by "Alex and Nick Myrman" 
Verified LL 8EB3906BE7510354 by "S57483"

Each of the short Myrman residues fails to match by being just 1 greater than the other "Verified" residues, in the 15 low-order bits. Were those the actual residue values reported by the Myrmans, or are they some artifact of a problem elsewhere?

There are several other results listed for "Alex and Nick Myrman" for unfactored exponents between 1800590 and 1800960, each with "Bad LL" and a (nonmatching) 16-hexadecimal-digit residue. So, it doesn't appear that the Myrman results were (all) ancient.

1) Why are some of the Myrman residues shown as short values?

2) Why are those short Myrman residues labeled as "Verified" even though they don't match other residues for the same exponents?

3) Are there anomalies in any other "Alex and Nick Myrman" results?

4) Are there any other cases of non-matching residues (short or not) in the database that are listed as "Verified" in the Exponent Status reports? If so, are any of those exponents erroneously being considered as having been successfully DCed?

[Prime95]

Nick Myrman wrote his own LL program a decade ago. It had problems with the last bit of the residue. Rather than reject his results as bad, I accepted them as legitimate double-checks.

I suspect all have been triple-checked by now.

Slowinski also had short residues. Brian Beesley made it a personal crusade to make sure these were all triple-checked.

[davar55]

I had and have a similar problem with the hex output routine in my
personal version of LL tester. But I was extending it to work on
both larger (up to 40M or 80M) and smaller (<1000) exponents,
and didn't have it fully analyzed back then, and so left it alone.

Recommend quadruple checks when this happens.

[KingKurly]

Originally Posted by Prime95

Nick Myrman wrote his own LL program a decade ago. It had problems with the last bit of the residue. Rather than reject his results as bad, I accepted them as legitimate double-checks.

I suspect all have been triple-checked by now.

Slowinski also had short residues. Brian Beesley made it a personal crusade to make sure these were all triple-checked.

Is there a list of small exponents for which a triple check might be useful? Or is that list empty? (I wouldn't mind running some such tests, but I suppose you'd have to take my word for it that I didn't look at the published residues. I assure you I have no interest in doing that; it rather defeats the purpose of the exercise.)

For kicks, I'm running M1800767 right now. It should be done in the next 15 minutes or so. I hope this doesn't count as poaching.

Edit: The 153BED18D5C5EA4B residue for M1800767 is correct, and I was awarded a whopping 0.0977 GHz-days for my troubles. I'm going to wait until I hear back from Prime95 before I do any more of this sort of work.

[davar55]

Wasn't the moral issue of poaching being discussed in another thread?

[Prime95]

Originally Posted by KingKurly

Is there a list of small exponents for which a triple check might be useful? Or is that list empty?

I suspect the list is empty.

[Mini-Geek]

Originally Posted by Prime95

I suspect the list is empty.

I suspect it is not, but that only trusted party(ies) could run the triple checks for it to do any good. (the list might be formed, at least in part, by looking for suspicious activity, e.g. user B often submits "double checks" in a non-verifiable way of user A's work shortly after user A "completes" a first-time test, verifiable or not)