Trippple Checks

[Mark Rose]

Originally Posted by Madpoo

EDIT: Wow, I just looked at the 40-55M range and saw you moved it from 69-72 bits up to 74 bit depth for them. Above and beyond. :)

So that's why all those exponents are moving so high on mersenne.info. I was wondering...

[VictordeHolland]

Another 6 down:
M22067161 has a factor: 1526640087454398117503
M22163117 has a factor: 1355085266422807430143
M22430269 has a factor: 1552111458122877633929
M23165851 has a factor: 1455843379959852370607
M23269483 has a factor: 2045719464136752580457
M23893223 has a factor: 2316938128178530687993

[Madpoo]

Originally Posted by VictordeHolland

Another 6 down:
M22067161 has a factor: 1526640087454398117503
M22163117 has a factor: 1355085266422807430143
M22430269 has a factor: 1552111458122877633929
M23165851 has a factor: 1455843379959852370607
M23269483 has a factor: 2045719464136752580457
M23893223 has a factor: 2316938128178530687993

Nice work. Taking those to 71 bits it seems? Very good.

Attached is an updated list. It's being whittled down pretty steadily. Once I get through the larger exponents (60M and up) I'll scoop up whatever smaller ones there are which should get it moving along.

[VictordeHolland]

Originally Posted by Madpoo

Nice work. Taking those to 71 bits it seems? Very good.

Yes, I'm taking the 20M-30M of the list to 71 bits, should be ready in about a week. That is probably the last TF I'll run on this list, then it is up to the LL-ers.

[Madpoo]

Originally Posted by Madpoo

It looks like George has marked my previously bad results as verified. There is still this odd one where the residue from "Reto Keiser" is different in just one nibble... an F instead of 2.

That one seems like it's a little too close but also different, and it's version is v16 of Prime95 so I'm kind of wondering if that's just some mistake that it was marked as good?

I'll be honest, I wrote a query to find the mismatches but I sat and stared at this for a while before my brain noticed that one little difference. Took me back to an old data entry temp job I had as a teen, comparing figures from two printouts. Ugh.

This exponent http://www.mersenne.org/M3365707 was still bugging me, with the one weird result showing up as good.

I just ran it 3 more times on 3 different computers and got the same residue as before, and matching the ones from 2 other people.

My new runs got marked as bad because it checked against that first one in the list with the increasingly mismatched residue.

For George: I hope you don't mind, but in this one case I marked my new results as good and went ahead and marked that one from "Reto Keiser" as bad. Since the client used in his case was Prime95 v16 and not one of those other ones, it seemed more and more like it got accidentally marked as good at some point along the way.

If anyone else feels like doing extra checks on that just to make sure I'm not blowing smoke... it took 18 minutes to run on my humble desktop with an i7-3770 at stock speed (3.4 GHz). If your results match the now-established residue it should verify okay, now that the weird one is marked bad.

I also ran it on a 10-core CPU which took about 17 minutes, and on an 8-core CPU which took about 17 minutes. Interesting there that for that exponent, the extra cores didn't really speed it up noticeably. Oh well. Maybe by a few seconds if I'd really been paying attention.

[LaurV]

That expo is at the limit of 168k and 200k FFT. It takes ~7 minutes for a Titan at the default 168k, but is coming with rounding errors and extending the FFT. With 200k from start it takes ~8 minutes. Both give the correct residue, the one you got. However, I won't be so fast in marking Reto's residue bad. It is most probably a typo from the time when those were manually checked, as George said. Reto is a long time contributor, no reason to anger him Possible, move his residue down the list, or "correct" it and keep it "good". It is technically impossible to get a residue which differs in 3 bits only.

[Madpoo]

Originally Posted by LaurV

That expo is at the limit of 168k and 200k FFT. It takes ~7 minutes for a Titan at the default 168k, but is coming with rounding errors and extending the FFT. With 200k from start it takes ~8 minutes. Both give the correct residue, the one you got. However, I won't be so fast in marking Reto's residue bad. It is most probably a typo from the time when those were manually checked, as George said. Reto is a long time contributor, no reason to anger him Possible, move his residue down the list, or "correct" it and keep it "good". It is technically impossible to get a residue which differs in 3 bits only.

The problem is, it needs to be marked as something other than "verified" in the database, and because it came from a common application version it can't be excluded like those other special ones that were known to generate odd-but-correct residues. Marking it "bad" is really the only logical choice...it could be marked "suspect", but the rule is that once an exponent is verified by double-checking, any residues that don't match the confirmed result are, by definition, "bad".

I guess it shouldn't really matter why it was bad, whether it was manually typed in and just got fat-fingered (rather than cut/paste?) or the computer barfed during it's run. I just don't know if GIMPS should be in the business of going back and changing residues based on a notion that we think we know what it should have been? LOL

It's an entry that ported over from the v4 database and since that would have all been transferred directly, it would have existed in it's weird form since it was first checked in. Not sure about the date of that check-in but it would have been long ago and I doubt anyone remembers the circumstances.

Hopefully Reto won't take it personally in this one instance. I'm sure it's some odd glitch and maybe the result of someone manually typing in a residue for some reason, mistaking a 2 for an F. I won't lose sleep over the how, but showing it as verified in the database was clearly incorrect in it's current form.

[Prime95]

Originally Posted by LaurV

However, I won't be so fast in marking Reto's residue bad. It is most probably a typo from the time when those were manually checked, as George said. Reto is a long time contributor, no reason to anger him Possible, move his residue down the list, or "correct" it and keep it "good".

Very likely my fault due to the highly manual database update process back in those days. Madpoo, alternatively you can mark it good and update ar2.php to ignore Reto's residue for that one exponent.

[Prime95]

Originally Posted by Madpoo

It's an entry that ported over from the v4 database and since that would have all been transferred directly, it would have existed in it's weird form since it was first checked in. Not sure about the date of that check-in but it would have been long ago and I doubt anyone remembers the circumstances.

FYI, the v4 database was NOT the master database. I maintained the master database at home in text files. This database was a superset of the v4 database, by adding in manual results sent to me by email.

In ar2.php you can add the clause along the lines of "AND (exponent != 3365707 or user_id != reto's_user_id)" rather than eliminate all v16 residues for all exponents.

[Madpoo]

Originally Posted by Prime95

FYI, the v4 database was NOT the master database. I maintained the master database at home in text files. This database was a superset of the v4 database, by adding in manual results sent to me by email.

In ar2.php you can add the clause along the lines of "AND (exponent != 3365707 or user_id != reto's_user_id)" rather than eliminate all v16 residues for all exponents.

If you're pretty sure it was checked in okay (and I'm guessing it was) and it just got typo'd along the way, we can go ahead and change the residue in the database... since this is the only oddball example I found where an incorrect residue was marked as verified, I think that's reasonable. And probably more pleasant in the long run than having an extra "and" clause for a one-off case every time someone checks in a result.

Especially since years from now you'd look back at that and think "now why are we excluding that one result?" ... I know I'd forget...probably in a week.

[Madpoo]

Originally Posted by Madpoo

If you're pretty sure it was checked in okay (and I'm guessing it was) and it just got typo'd along the way, we can go ahead and change the residue in the database... since this is the only oddball example I found where an incorrect residue was marked as verified, I think that's reasonable. And probably more pleasant in the long run than having an extra "and" clause for a one-off case every time someone checks in a result.

Especially since years from now you'd look back at that and think "now why are we excluding that one result?" ... I know I'd forget...probably in a week.

Okay... be it heretofore recorded for all posterity, that on April 1, 2015 (and not as a prank), Madpoo did knowingly change the stored residue of an exponent in the DB.

The recorded residue by user "Reto Keiser" was changed from "849F0256FF290214" to "849F0256F2290214" and marked as "verified".

That should take care of that tricky one. After what George mentioned, I'm pretty sure the error came up as a result of the old method of entering residues the old fashioned way. I won't lose sleep over it. As noted, it would be extremely implausible for a bad run to come up with a residue that was so close. :)