PRP CF

ATH · 2017-11-11, 07:51

I found an ECM factor of:
https://mersenne.org/M1322117

and then the exponent was immediately available again for PRP CF test even though it had been tested and verified with the old factors, so that seems to work.

But maybe it should delete the old residues in the "Cofactor PRP" section when a new factor is found and only leave the evidence in the history section?

The name of the section "Cofactor PRP" is also somewhat misleading maybe it should be "Cofactor Status"? or something similar.

Madpoo · 2017-11-13, 18:44

Quote:

Originally Posted by ATH

I found an ECM factor of:
https://mersenne.org/M1322117

and then the exponent was immediately available again for PRP CF test even though it had been tested and verified with the old factors, so that seems to work.

But maybe it should delete the old residues in the "Cofactor PRP" section when a new factor is found and only leave the evidence in the history section?

The name of the section "Cofactor PRP" is also somewhat misleading maybe it should be "Cofactor Status"? or something similar.

Forgive me if I totally misunderstand what the cofactor PRP is doing, but my understanding is, you're doing a PRP test on the cofactor ... so if you have some results (verified or not) that said it wasn't prime, and then indeed a new factor is found, that actually validates those previous "cofactor isn't prime" results.

That said, why would we want to remove or hide them? In my mind, it's akin to the history section of an exponent for all of the trial factoring effort that was done... if a factor is later found (or if the exponent turns out to be a Mersenne prime) should we hide all of the previous work that went into it?

Plus, for PRP type-5 work, as I understand it, residues from previous tests are still useful when doing a new test with the additional factor.

In short, I don't see a problem with including the older stuff unless I'm just missing something obvious. LOL

xilman · 2017-11-13, 19:59

GP2 · 2017-11-13, 20:40

Old type 1 PRP residues are only of historical interest.

Old type 5 PRP residues continue to serve as double checks and triple checks, since the numerical value of the residue doesn't change when new factors are discovered (unless the resulting new cofactor is PRP).

That does raise the question, though, of whether type 5 PRP residues should have the final hex digits permanently masked...

Maybe "Cofactor PRP" in the display could be changed to just "Cofactor".

For Mersenne numbers there are two tests, so we need to distinguish "LL" and "PRP", but for cofactor testing, there is only one kind of test.

R. Gerbicz · 2017-11-13, 22:21

Quote:

Originally Posted by GP2

Maybe "Cofactor PRP" in the display could be changed to just "Cofactor".

For Mersenne numbers there are two tests, so we need to distinguish "LL" and "PRP", but for cofactor testing, there is only one kind of test.

Actually there is an LLT variant for the cofactor testing,
here it my worked out method:

If q=(2^n-1)/d is prime (where q!=3) then
LLT(n,4,n)==(2+S)^(d+K)+(2-S)^(d+K) mod q
where S=sqrt(3)
LLT(n,x0,it)={mp=2^n-1;x=Mod(x0,mp);for(i=1,it,x=x^2-2);return(lift(x))}
and K=kronecker(3,q), where K=+-1.

This test can use composite n values.
To compute the terms of (2+S)^(d+K)+(2-S)^(d+K) use binary exponentation,
in one step we know (2+-S)^e=A+-B*S mod q.

So interestingly, from stored LL residue we can also apply a fast Suyama type test for the new factors.

Notice that we can apply this for n=p;d=1; then we get that if mp is prime then x[p]=2 (because (3/mp)=-1), what you can see from the standard LLT, here we just use two more iterations.

ATH · 2017-12-07, 02:14

There is still an issue with the database when trying to verify cofactors that actually are PRPs:

Quote:

processing: PRP=(true) for M1307/101286184577,141196558805510033914433414063,161633497146742177992711798481
Notice: Undefined variable: WAS_VERIFIED in C:\inetpub\v5\v5server\gimps\0.95_ar2_app.php on line 1569 Notice: Array to string conversion in C:\inetpub\v5\v5server\gimps\0.95_prime_notification.inc.php on line 287 Notice: Array to string conversion in C:\inetpub\v5\v5server\gimps\0.95_prime_notification.inc.php on line 287
PRP result reported for already factored M1307 -- CPU credit is 0.0000 GHz-days.

Prime95 · 2017-12-07, 04:24

Thanks for the reminder. I worked on it but did not test it.

ATH · 2017-12-10, 04:01

I made a small program or "spider" as I think they are often called to "crawl" through the low end of the database looking for the PRP CF candidates below the current PRP CF wavefront that were not verified or verified with the same shift value or same username.

Unfortunately when generating the worktodo lines for the missing exponent I switched the type and base, because in the database it is listed as Type followed by Base, but in the worktodo you need to do the reverse Base followed by Type:
PRP=N/A,1,2,<exponent>,-1,99,0,<base>,<type>,"<list of known factors>"

So unfortunately I "messed" up a lot of exponents like:
https://mersenne.org/M17509
https://mersenne.org/M136429
https://mersenne.org/M267667

I am sorry, I hope I did not mess up too badly for too many exponents.

GP2 · 2017-12-10, 18:43

Quote:

Originally Posted by ATH

I am sorry, I hope I did not mess up too badly for too many exponents.

At worst, they are merely redundant tests with a different residue type. I'll take a look and double check a few if necessary to change their status to Verified, should be pretty fast if they're small exponents.

kruoli · 2017-12-10, 19:38

Quote:

Originally Posted by ATH

Unfortunately I "messed" up a lot of exponents like:
https://mersenne.org/M17509
https://mersenne.org/M136429
https://mersenne.org/M267667

I did a double check on those three - but not because they were required! I did them just out of curiosity. I don't think there should be any mess because of those things.

GP2 · 2018-02-12, 09:56

There are a number of PRP-CF double checks that are overdue without updates up to 50+ days, for exponents from 3.85M up. The vast majority have no progress but some have 90%+ progress.

Most of them are from user "nokno", who is practically the only one still using the buggy earlier pre-v29 PRP code. This user is still turning in results in other ranges, so it's not clear what's happening.

These PRP-CF tests should take only an hour or so, each.

Is there any mechanism in place to automatically expire PRP and PRP-CF assignments, similar to what is done for LL testing?

2017-11-11, 07:51	#1
ATH Einyen Dec 2003 Denmark 3⁵·13 Posts	PRP CF I found an ECM factor of: https://mersenne.org/M1322117 and then the exponent was immediately available again for PRP CF test even though it had been tested and verified with the old factors, so that seems to work. But maybe it should delete the old residues in the "Cofactor PRP" section when a new factor is found and only leave the evidence in the history section? The name of the section "Cofactor PRP" is also somewhat misleading maybe it should be "Cofactor Status"? or something similar.

2017-11-13, 19:59	#3
xilman Bamboozled! "𒉺𒌌𒇷𒆷𒀭" May 2003 Down not across 2⁹·3·7 Posts

2017-11-13, 20:40	#4
GP2 Sep 2003 101000011001₂ Posts	Old type 1 PRP residues are only of historical interest. Old type 5 PRP residues continue to serve as double checks and triple checks, since the numerical value of the residue doesn't change when new factors are discovered (unless the resulting new cofactor is PRP). That does raise the question, though, of whether type 5 PRP residues should have the final hex digits permanently masked... Maybe "Cofactor PRP" in the display could be changed to just "Cofactor". For Mersenne numbers there are two tests, so we need to distinguish "LL" and "PRP", but for cofactor testing, there is only one kind of test.

2017-12-07, 04:24	#7
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 16546₈ Posts	Thanks for the reminder. I worked on it but did not test it.

2017-12-10, 04:01	#8
ATH Einyen Dec 2003 Denmark 3⁵×13 Posts	I made a small program or "spider" as I think they are often called to "crawl" through the low end of the database looking for the PRP CF candidates below the current PRP CF wavefront that were not verified or verified with the same shift value or same username. Unfortunately when generating the worktodo lines for the missing exponent I switched the type and base, because in the database it is listed as Type followed by Base, but in the worktodo you need to do the reverse Base followed by Type: PRP=N/A,1,2,<exponent>,-1,99,0,<base>,<type>,"<list of known factors>" So unfortunately I "messed" up a lot of exponents like: https://mersenne.org/M17509 https://mersenne.org/M136429 https://mersenne.org/M267667 I am sorry, I hope I did not mess up too badly for too many exponents.

2018-02-12, 09:56	#11
GP2 Sep 2003 5·11·47 Posts	There are a number of PRP-CF double checks that are overdue without updates up to 50+ days, for exponents from 3.85M up. The vast majority have no progress but some have 90%+ progress. Most of them are from user "nokno", who is practically the only one still using the buggy earlier pre-v29 PRP code. This user is still turning in results in other ranges, so it's not clear what's happening. These PRP-CF tests should take only an hour or so, each. Is there any mechanism in place to automatically expire PRP and PRP-CF assignments, similar to what is done for LL testing?