mersenneforum.org  

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

Reply
 
Thread Tools
Old 2019-05-11, 02:54   #1
PhilF
 
PhilF's Avatar
 
Feb 2005
Colorado

3×11×13 Posts
Default Matching BAD LL results?

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.

Last fiddled with by PhilF on 2019-05-11 at 02:56
PhilF is offline   Reply With Quote
Old 2019-05-11, 03:07   #2
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

22·7·241 Posts
Default

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.
Prime95 is offline   Reply With Quote
Old 2019-05-13, 18:10   #3
Madpoo
Serpentine Vermin Jar
 
Madpoo's Avatar
 
Jul 2014

62678 Posts
Default

Quote:
Originally Posted by PhilF View Post
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.
Madpoo is offline   Reply With Quote
Old 2019-05-14, 04:09   #4
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

5×23×73 Posts
Default

Quote:
Originally Posted by Madpoo View Post
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?
LaurV is offline   Reply With Quote
Old 2019-05-14, 05:01   #5
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

4,001 Posts
Talking

If I ever get mad at LaurV, I'm going to grab a set of his completed tests and head right into ECM.
VBCurtis is offline   Reply With Quote
Old 2019-05-14, 05:46   #6
Uncwilly
6809 > 6502
 
Uncwilly's Avatar
 
"""""""""""""""""""
Aug 2003
101Ɨ103 Posts

777310 Posts
Default

Quote:
Originally Posted by Madpoo View Post
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.
Uncwilly is offline   Reply With Quote
Old 2019-05-14, 06:16   #7
ixfd64
Bemusing Prompter
 
ixfd64's Avatar
 
"Danny"
Dec 2002
California

2,251 Posts
Default

Quote:
Originally Posted by LaurV View Post
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."

Last fiddled with by ixfd64 on 2019-05-14 at 06:16
ixfd64 is online now   Reply With Quote
Old 2019-05-14, 13:50   #8
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

D8116 Posts
Default

Quote:
Originally Posted by Madpoo View Post
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 is offline   Reply With Quote
Old 2019-05-14, 13:58   #9
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

D8116 Posts
Default

Quote:
Originally Posted by ixfd64 View Post
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.

Last fiddled with by kriesel on 2019-05-14 at 14:13
kriesel is offline   Reply With Quote
Old 2019-05-14, 14:47   #10
GP2
 
GP2's Avatar
 
Sep 2003

2×1,289 Posts
Default

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)".

Last fiddled with by GP2 on 2019-05-14 at 14:58
GP2 is offline   Reply With Quote
Old 2019-05-14, 16:12   #11
Madpoo
Serpentine Vermin Jar
 
Madpoo's Avatar
 
Jul 2014

1100101101112 Posts
Default

Quote:
Originally Posted by LaurV View Post
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?
Madpoo is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Largest number of LL tests before matching residues achieved? sdbardwick Lounge 1 2015-02-03 15:03
Can 1227133513 be the only composite number matching the conditions? miket Math 5 2014-08-12 00:41
Three matching tests not closing exponent? Dubslow PrimeNet 8 2012-04-27 18:19
Residue not matching due to masked bits patrik Data 1 2011-09-24 23:44
"Verified" LLs with non-matching short residues? cheesehead Data 6 2010-12-27 22:47

All times are UTC. The time now is 22:46.

Sat Apr 4 22:46:17 UTC 2020 up 10 days, 20:19, 0 users, load averages: 1.26, 1.19, 1.38

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.