OFFICIAL "SERVER PROBLEMS" THREAD

[petrw1]

https://www.mersenne.org/assignments...0000&exfirst=1

If I exclude DC it does not show TF assignments.

[LaurV]

Same here...

[GP2]

Originally Posted by GP2

The Exponent Status report in text-only format is a bit garbled. It's missing a semicolon to separate the shift count from the residue type, and there is an extra semicolon at the end.

It's still doing this, I think it's a fairly quick fix?

[GP2]

Originally Posted by GP2

Prime95 29.4 build 5 is refusing to do PRP-CF on a few exponents:

In my results.txt files:

4456310665879544089 does not divide M2207441
12415622589540644657 does not divide M2233183
1219861756779140901119 does not divide M2233019

All of these statements are false, actually.

This is all fixed now, the above is from the Prime95 version 29.4 thread, but it was actually a database problem, caused by the same factor being duplicated in the database.

I just realized that I had reported this duplication of factors for these same exponents some time earlier, but I guess it wasn't fixed at the time. In that message, I suggested that the FACTORS column in the database should have an SQL unique index or unique constraint placed on it, which would prevent duplicates.

It is mathematically impossible for two Mersenne numbers with prime exponents to share the same factor, so this would be the easiest way to prevent the problem from recurring.

[GP2]

One more thing related to M2207441, M2233183, M2233019 and any similar cases:

We now seem to be relying on the "Number of known factors" displayed in the PRP Cofactor section. This suggests that any PRP tests done with a bogus factor string should be removed from the PRP Cofactor section at least, and perhaps even from the History. This prevents any confusion about exactly which factors were used.

Currently, this seems to be done in an inconsistent way:

For M2207441 the bogus 2017-10-18 test does not appear in the PRP Cofactor section, although the equally bogus 2017-10-09 test does appear. Both appear in History.

For M2233183, the bogus 2017-10-18 test does not appear in the PRP Cofactor section, but the presumably equally bogus 2017-10-10 test does appear. Hard to say, since it was a "known_factors" result, but it almost certainly used the same factor string. Since Oliver e-mailed you his old results.txt files, it should be possible to check. In any case both of those old results were obsoleted by the discovery of a new factor on 2017-11-09.

For M2233019, the bogus 2017-10-18 test does not appear in the PRP Cofactor section, but the presumably equally bogus 2017-10-10 test does appear. That was also a "known_factors" result, but it almost certainly used the same bogus factor string. Again, Oliver's old results.txt files could be checked if necessary.

There are a handful of other cases:

For M2210209, I submitted a result with a garbled factor string due to a copy-paste mishap, which was noticed by James Heinrich. In a private message from Madpoo dated 2017-10-11, 16:33 from me, James Heinrich and Prime95, he mentioned that he removed it from the results log and also the cofactor PRP table. There is now no trace of this bogus result in the Exponent Status.

In a followup private message from James Heinrich to the same recipients dated 2017-10-11, 16:38, he mentioned two of alperton's old results for 37811 and M1132997 with garbled and truncated factors, where the factor string must have been copy-pasted incorrectly.

For 37811, this still appears in the History section and in the PRP Cofactor section as a "Bad" result. For consistency with the handling of M2210209, perhaps these should both be removed, or at least in the PRP Cofactor section.

For M1132997, it's the same story.

So there are six cases in all, where the handling ranged from leaving everything as-is to removing all trace of the bogus result. For consistency they should all be handled the same way. I think there is no value in keeping bogus results that originated in garbled input.

PS,
The only genuine Bad result for PRP Cofactor testing that I'm aware of is ATH's result for 3167573, which appears to have been done with an older version before the Gerbicz error checking and recovery code was put into the program.

[GP2]

Originally Posted by GP2

It is mathematically impossible for two Mersenne numbers with prime exponents to share the same factor, so this would be the easiest way to prevent the problem from recurring.

Of course, it is not impossible (as far as we know) for a Mersenne number with prime exponent to have the same factor twice. However, finding any such non-square-free Mersenne number would generate headlines worldwide, because then we'd automatically have the third known Wieferich prime. The odds of this are surely astronomically low.

It's simple enough to test for non-squarefree-ness separately, over the entire database of factors, or at the time any factor is submitted, using standard modular exponentiation library functions, so this unlikely eventuality isn't a reason not to put a unique constraint or unique index on the factors column.

[Madpoo]

Originally Posted by GP2

The Exponent Status report in text-only format is a bit garbled. It's missing a semicolon to separate the shift count from the residue type, and there is an extra semicolon at the end.

This is a recent change that seems to coincide with the switch from "CofactorPRP" to "PRPCofactor".

That's entirely my fault. I was moving some stuff around and got a little sloppy with cut/paste.

Plus, I'm noticing that the order of things isn't the same between PRP and PRP-cofactor and I feel like they should be consistent...

Right now, PRP has:
exponent, type, status, date, user, residue, residue-type, base, shift

However, for whatever reason I set PRP-CF to be:
exponent, type, status, date, user, residue, # of factors, shift, residue-type, base

In short, what was I thinking? I made PRP-CF match the way they're shown in the table, but I didn't update PRP at the same time I guess? I've been dealing with a bad bout of the flu and I probably did that during a feverish period.

I'll try to get that fixed and make more sense... hope it doesn't mess the parsing anyone already has but better to do it now.

[Madpoo]

Originally Posted by GP2

One more thing related to M2207441, M2233183, M2233019 and any similar cases:

Yeah, those "bad" results with missing known_factors still need cleaning. I think I've fixed up what I could from the results data sent to me and now it's a matter of what to do with what's left.

I think I left off the PM threads with the idea of generating a list of the affected exponents with weird PRP-CF results and redo them while tossing the unusable results.

It's just one of those back-burnered things.

[ET_]

I am actually doing PRP-CF and PRP-CF-D.

Do you think I should stop until things are settled?

Luigi

[Prime95]

Originally Posted by ET_

I am actually doing PRP-CF and PRP-CF-D.

Do you think I should stop until things are settled?

As long as you are using prime95 29.4 build 5 you are in good shape.

[ET_]

Originally Posted by Prime95

As long as you are using prime95 29.4 build 5 you are in good shape.

I am, of course