Matching BAD LL results?

[PhilF]

How can 2 LL tests have matching bad residues?

https://www.mersenne.org/report_expo...0612829&full=1

EDIT: I just noticed they have the same shift count, so maybe that's a clue.

[Prime95]

You noticed the big clue. There was a time long ago when prime95 had a communication bug and reassigned a user a new Sxxxxx user id. When that happened a LL result could get posted under both user ids.

[Madpoo]

Originally Posted by PhilF

How can 2 LL tests have matching bad residues?

https://www.mersenne.org/report_expo...0612829&full=1

EDIT: I just noticed they have the same shift count, so maybe that's a clue.

Over the weekend I did a little cleanup and marked tests as "bad" for any exponents that were factored, but actually did have a valid pair of matching results (different shifts).

I did a cleanup like that a while back and just had to touch up a few.

Besides that one, there were something like 4-5 others like that. They had "matching" residues, but the shift count was the same. That was probably a result of the same result being submitted twice.

There are some unicorns in there, where the same residue was arrived at *twice* with different shift counts. But there's a history to that (the user had a bad system that was generating false positives):
https://www.mersenne.org/M42525269
https://www.mersenne.org/M43714607
https://www.mersenne.org/M45111893

There are some older ones that I don't know the backstory:
https://www.mersenne.org/M4589707
https://www.mersenne.org/M39988591

To date, those 5 are the only instances where a residue was matched, having different shift counts. In each, the user was the same. 3 of those was some type of hardware issue for user Xolotl but the other two... ? The residues weren't all zeroes like we might expect with hardware problems (an interim residue zeroed out for some reason and stuck that way).

But those examples were the main reason why I started the mini project to independently verify tests. It was a needle-in-a-haystack thing where I wasn't even sure the needle was in the haystack to begin with, but there you go.

[LaurV]

Originally Posted by Madpoo

Over the weekend I did a little cleanup and marked tests as "bad" for any exponents that were factored, but actually did have a valid pair of matching results (different shifts).

Huh? That is horrible!
It affects our good/bad history. A guy with 100% good tests will now appear as having 10% bad results in the past, because some of the exponents he LL-ed are now factored?

[VBCurtis]

If I ever get mad at LaurV, I'm going to grab a set of his completed tests and head right into ECM.

[Uncwilly]

Originally Posted by Madpoo

There are some older ones that I don't know the backstory:
https://www.mersenne.org/M4589707

For the fun of it I did another run on this. That way we have 2 matching with non-zero shifts. Didn't take long.

[ixfd64]

Originally Posted by LaurV

Huh? That is horrible!
It affects our good/bad history. A guy with 100% good tests will now appear as having 10% bad results in the past, because some of the exponents he LL-ed are now factored?

I think Aaron is talking about cases where a matching LL result is obtained after the factor, like this one: http://mersenne.org/m34567381

Previously, the bad result was also marked as "Verified."

[kriesel]

Originally Posted by Madpoo

Over the weekend I did a little cleanup and marked tests as "bad" for any exponents that were factored, but actually did have a valid pair of matching results (different shifts).

I did a cleanup like that a while back and just had to touch up a few.

If you are talking about marking as bad, a completed primality run that was verified by matching the 64-bit residue of another completed run by a different user for the same exponent and primality test type, and also was factored, that seems very unfortunate, if it pollutes the statistics indicating the reliability of the primality tests, making them look worse than they are. Fudging the stats that way is itself bad. Please stop doing so, and undo it if possible. There's a difference between a correctly performed useful run, or correctly performed useless run, and incorrectly performed run. If an accurately performed primality test is later made moot by a blindingly fast quantum computer factoring the exponent, that does not mean the primality test was bad; it was only supplanted by more specific information about the exponent, a specific factor.

I saw a case recently where an exponent just above 100M had SIX matching residues listed. I do not think the last 4 should be counted as errors in the program(s) that produced them.

[kriesel]

Originally Posted by ixfd64

I think Aaron is talking about cases where a matching LL result is obtained after the factor, like this one: http://mersenne.org/m34567381

Previously, the bad result was also marked as "Verified."

I don't understand the point you're trying to make with that link.
The factor was found in 2015; ten years before that the mismatched residue primality test marked bad was submitted, not the other way around. Madpoo's 2019 residue is not marked bad, although it was performed after the factor was found. Madpoo's was the tiebreaker triple-check to determine if either the 2005 or the 2006 primality test were correctly performed. A case could be made that the triple-check was not necessary, since a factor had been found and verified. Or that the double-check was not necessary yet, since the exponent had not been adequately P-1 factored yet.

[GP2]

I think Madpoo just expressed himself a bit confusingly.

Only bad residues are marked as bad, now and before.

If an exponent has an unverified residue (or residues), then sometimes a factor is found before a double check (or triple check) is done. In that case, the residue status needs to be changed away from Unverified, to ensure that no further LL tests are assigned by Primenet. So it gets set to "Verified (Factored)".

The problem is that "Verified (Factored)" can mean two different things:

1. Matching LL tests created "Verified" residues, and then a factor was found.
2. A single LL test, or two or more mismatched LL tests, created "Unverified" residues, and then a factor was found. So the status is really unknown, not actually verified.

In any case, sometimes Madpoo did another LL test anyway on the factored exponent, just to improve the good/bad statistics that he uses to find strategic double checks. But those tests were done manually, because obviously Primenet doesn't assign unneeded LL tests for factored exponents. That means he needed to manually set the status to "Bad" for any residues now known to be bad which were previously of unknown status but marked "Verified (Factored)".

[Madpoo]

Originally Posted by LaurV

Huh? That is horrible!
It affects our good/bad history. A guy with 100% good tests will now appear as having 10% bad results in the past, because some of the exponents he LL-ed are now factored?

If an LL test is bad, it doesn't matter if the Mersenne # was factored or not.

Maybe I didn't make it clear, but I was only marking them as bad if they were actually bad. Those exponents all had a valid pair of matching residues from different shift counts.

Of the results that just recently got marked bad, about a dozen were cases where there was already a mismatch between the first and second test and then a factor was found. I took a handful of them and ran a 3rd test to see which was correct, and GP2 took a couple.

I did a previous cleanup like that a while back, so this was just catching up with a few new cases.

And when I did my previous cleanup, I missed a bunch where there were actually *two* matching residues recorded, but with the same shift count (same test was submitted twice). Just an oversight when I queried for them before. GP2 was the one who pointed those out. In each of those cases, there were a pair of valid, matching results.

There were the handful (5) that had *different* shift counts but ended up being bad, so those were the really peculiar ones.

And finally I cleaned up all of those funky "Myrman" residues. Most were off by a single bit, usually the last one. But I checked a bunch out and some were off by a bit somewhere else instead, or in addition to, the LSB. Which was strange. And instead of 64-bit residues, they were anywhere from a measly 7-24 bits, or maybe in rare cases 31-32 bits.

Anyway, since these residues always generate questions, and like it or not, they stem from a bug in the custom code he used, I ended up marking them as bad. Because technically they are. Apologies to Myrman if he's still around... we know what the deal is with those, but in the interest of treating all tests the same it had to be done.

One final category of "weirdness" I cleaned up... tests that suffered from the unusual bug where the shift count was between exponent-64 and exponent-1 or whatever. The end result was a residue that was kind of truncated to only a certain # of bits which didn't match the real residue.

I had a couple of those myself, and there were a handful (I think 4 or 5) others like that. Ultimately I ended up removing those results. They were technically bad, but because of a particular bug.

Maybe I should have done the same with the Myrman results, just removing them since it was a program bug and not an error during the test... hmm... I'm just now contemplating that. But since Myrman isn't active anymore (to my knowledge) and the people with the funny shift-count residues are somewhat active (at least me and one other I know of), I figured deleting them rather than marking them bad would have less stigma.

Does that help explain what was involved?