mersenneforum.org  

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

Reply
 
Thread Tools
Old 2017-12-13, 17:14   #1354
petrw1
1976 Toyota Corona years forever!
 
petrw1's Avatar
 
"Wayne"
Nov 2006
Saskatchewan, Canada

23×191 Posts
Default

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

If I exclude DC it does not show TF assignments.
petrw1 is online now   Reply With Quote
Old 2017-12-14, 09:40   #1355
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

2×13×337 Posts
Default

Same here...
LaurV is online now   Reply With Quote
Old 2017-12-14, 20:52   #1356
GP2
 
GP2's Avatar
 
Sep 2003

22·3·5·43 Posts
Default

Quote:
Originally Posted by GP2 View Post
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 is offline   Reply With Quote
Old 2017-12-14, 21:04   #1357
GP2
 
GP2's Avatar
 
Sep 2003

22×3×5×43 Posts
Default

Quote:
Originally Posted by GP2 View Post
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 is offline   Reply With Quote
Old 2017-12-14, 22:16   #1358
GP2
 
GP2's Avatar
 
Sep 2003

22·3·5·43 Posts
Default

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 is offline   Reply With Quote
Old 2017-12-14, 22:24   #1359
GP2
 
GP2's Avatar
 
Sep 2003

A1416 Posts
Default

Quote:
Originally Posted by GP2 View Post
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.
GP2 is offline   Reply With Quote
Old 2017-12-15, 06:51   #1360
Madpoo
Serpentine Vermin Jar
 
Madpoo's Avatar
 
Jul 2014

52×131 Posts
Default

Quote:
Originally Posted by GP2 View Post
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 is offline   Reply With Quote
Old 2017-12-15, 07:25   #1361
Madpoo
Serpentine Vermin Jar
 
Madpoo's Avatar
 
Jul 2014

63138 Posts
Default

Quote:
Originally Posted by GP2 View Post
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.
Madpoo is offline   Reply With Quote
Old 2017-12-15, 17:24   #1362
ET_
Banned
 
ET_'s Avatar
 
"Luigi"
Aug 2002
Team Italia

2×2,383 Posts
Default

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

Do you think I should stop until things are settled?

Luigi
ET_ is offline   Reply With Quote
Old 2017-12-15, 18:04   #1363
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

71·101 Posts
Default

Quote:
Originally Posted by ET_ View Post
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.
Prime95 is online now   Reply With Quote
Old 2017-12-15, 18:21   #1364
ET_
Banned
 
ET_'s Avatar
 
"Luigi"
Aug 2002
Team Italia

112368 Posts
Default

Quote:
Originally Posted by Prime95 View Post
As long as you are using prime95 29.4 build 5 you are in good shape.
I am, of course
ET_ is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Official "Faits erronés dans de belles-lettres" thread ewmayer Lounge 39 2015-05-19 01:08
Official "all-Greek-to-me Fiction Literature and Cinema" Thread ewmayer Science & Technology 41 2014-04-16 11:54
Official "Lasciate ogne speranza" whinge-thread cheesehead Soap Box 56 2013-06-29 01:42
Official "Ernst is a deceiving bully and George is a meanie" thread cheesehead Soap Box 61 2013-06-11 04:30
Official "String copy Statement Considered Harmful" thread Dubslow Programming 19 2012-05-31 17:49

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

Thu Oct 1 15:46:22 UTC 2020 up 21 days, 12:57, 1 user, load averages: 1.43, 1.45, 1.52

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.