[QUOTE=Citrix;495713]Is this a bug or is there a way to force the program to do the B2 work despite finding a factor in B1?[/QUOTE]

There is a setting to skip Stage 1 GCD. By default, a GCD is performed after Stage 1, and if it finds a factor, then why should it continue?

You can add the known factors in the worktodo line, then they will not be found again:

Pminus1=k,b,n,c,B1,B2[,"comma-separated-list-of-known-factors"]
ECM2=k,b,n,c,B1,B2,curves_to_run[,"comma-separated-list-of-known-factors"]


Here is an example of ECM on F12 with the known factors included with B1=800M:
ECM2=1,2,4096,1,800000000,80000000000,1,"114689,26017793,63766529,190274191361,1256132134125569,568630647535356955169033410940867804839360742060818433"

[QUOTE=axn;495718]There is a setting to skip Stage 1 GCD. [/QUOTE]

How do I use this setting?

Thank you ATH, your option should also work.

[QUOTE=axn;495718]There is a setting to skip Stage 1 GCD. By default, a GCD is performed after Stage 1, and if it finds a factor, then why should it continue?[/QUOTE]

Some stage 2 setup will do modular inverses. If these find a factor, you have the same problem where prime95 will stop.

[QUOTE=Prime95;495723]Some stage 2 setup will do modular inverses. If these find a factor, you have the same problem where prime95 will stop.[/QUOTE]

Is that only for ECM or for P-1 as well (I don't remember P-1 stage 2 setup requiring modular inverse)?

[QUOTE=axn;495726]Is that only for ECM or for P-1 as well (I don't remember P-1 stage 2 setup requiring modular inverse)?[/QUOTE]

I think that is ECM only.

There's a bug in the PRP code when using a non-standard repunit base (i.e., other than Mersenne b = 2) and a non-standard PRP base, which might possibly indicate a wider problem.

For instance, doing PRP on (3^p − 1) / (3 − 1), which is the base-3 repunit counterpart to the base-2 repunit (2^p − 1) / (2 − 1) aka Mersenne number.

Here the known probable primes are (from [URL="https://oeis.org/A028491"]OEIS sequence A028491[/URL]) 3, 7, 13, 71, 103, 541, 1091, 1367, 1627, 4177, 9011, 9551, 36913, 43063, 49681, 57917, 483611, 877843

This can't use the standard PRP base = 3 because the repunit base is already 3. So, using PRP base 5 and residue type 5, we have the following lines in worktodo.txt:

[CODE]
PRP=1,3,p,-1,99,0,5,5,"2"
[/CODE]

The residues for composite numbers match what they should be, but for the exponents that produce primes, the upper 32-bit half of the 64-bit residue is sometimes wrong:

[CODE]
3 0000000000000001
7 0000000000000001
13 0000000000000001
71 0000000000000001
103 0000000000000001
541 40B03E9E00000001
1091 40ED526E00000001
1367 40ED600100000001
1627 4120480C00000001
4177 4141263900000001
9011 410B27E100000001
9551 C126793A00000001
[/CODE]

Also, it's marking them all as composite rather than as probable primes, even for very small exponents, for example:

[CODE]
{[B]"status":"C"[/B], "k":1, "b":3, "n":13, "c":-1, "known-factors":"2", "worktype":"PRP-5", "res64":"0000000000000001", "residue-type":5, "fft-length":32, "error-code":"00000000", "security-code":"001A001A", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, "timestamp":"2018-09-12 07:40:57", ...
[/CODE]

This is worrisome because if there's a bug that partially overwrites the residue under some circumstances, then perhaps it might possibly affect the Mersenne PRP tests as well.

In case it's useful, I'm attaching a Python script that calculates PRP residues (slowly, for small exponents), which can be used to compare the residues from mprime. For the above values (base-3 repunit with base-5 PRP and 64-bit residues) it can be invoked with:

[CODE]
python ./grpr_py.txt -b 3 -a 5 -t 64 PRIMES_10k.txt
[/CODE]

I can verify that if the final result is less than 33 bits long, then the top 32-bits of a PRP residue are trash.

I've not looked at why it is reporting composite. I suspect type-1 PRP test would report as PRP.

Seems to work on type 1+2 for known repunit primes/PRPs for base 3,5,6,7,10 for p<50000.

It also works for type 3+4 but since they are not available for b!=2, it must be switching to type 1 most likely without informing?

[QUOTE=Prime95;495974]I can verify that if the final result is less than 33 bits long, then the top 32-bits of a PRP residue are trash.

I've not looked at why it is reporting composite. I suspect type-1 PRP test would report as PRP.[/QUOTE]

Yes, the type-1 tests with PRP base a=5 for b=3 do report status=P correctly for the exponents 3, 7, 13, 71, 103, 541, 1091...

But getting back to the type-5 residues, it seems to be doing the calculation differently if b is not 2:

Let:
numer = b[SUP]p[/SUP] − 1
denom = b − 1
repunit = numer / denom

In the case of Mersenne numbers, b = 2 so numer = 2[SUP]p[/SUP] − 1 and denom = 1
In the case of Wagstaff numbers, b = −2 so numer = (2[SUP]p[/SUP] + 1) and denom = 3
If b = 3 then numer = (3[SUP]p[/SUP] − 1) and denom = 2

In the case of Wagstaff b = −2, it is calculating the type-5 residue as:
PRP res = powmod(a, numer − 1, numer)

But for other non-Mersenne bases b != 2, it is calculating the type-5 residue as:
PRP res = powmod(a, repunit − 1, numer)

I don't know if this difference is intentional.

(and obviously for Mersenne b = 2, denom = 1 so there is no difference between the two forms, and I think it's considered a type-1 residue in any case)

So for b != 2 and b != −2, for the composite residues it's doing the calculation correctly but perhaps it's doing the wrong calculation. I'm not sure if the calculation it's actually doing is still compatible with the Gerbicz rapid cofactor-compositeness test.

Whereas for the prime residues, it should be calculating exactly 1, but something goes wrong. I took a look at the 2048-bit residues. For p = 3, 7, 13, 71, 103 the 2048-bit residue is exactly 1, but it gets reported as composite, so maybe some of the bits beyond 2048 are nonzero. And for p = 541, 1091, ... only bits 0 through 31 are exactly 00000001 and all the bits from 32 to 2047 are filled with seemingly random garble.

[QUOTE=GP2;495988]And for p = 541, 1091, ... only bits 0 through 31 are exactly 00000001 and all the bits from 32 to 2047 are filled with seemingly random garble.[/QUOTE]

Sorry, obviously I meant to say that the bits from 32 to maximum are filled with random garble, obviously p = 541 doesn't have 2048 bits of residue.


Anyway, for b != 2, the Type-5 residues as currently being calculated by mprime/Prime95 don't have the basic property of being invariant as the number of factors changes.

For example, for b=3, the repunits are ( 3[SUP]p[/SUP] − 1 ) / 2, and we have to use the PRP base 5 instead of 3.

For residue type 1 we have:

[CODE]
PRP=1,3,2131,-1,99,0,5,1,"2"
PRP=1,3,2131,-1,99,0,5,1,"2,459589675789"
PRP=1,3,2131,-1,99,0,5,1,"2,459589675789,147045472166651"
[/CODE]

and the output is:

[CODE]
{"status":"C", "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2", "worktype":"PRP-5", [B]"res64":"8E75A8D17A4BE62C"[/B], "residue-type":1, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ... }
{"status":"C", "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2,459589675789", "worktype":"PRP-5", [B]"res64":"362984CF537671B3"[/B], "residue-type":1, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
{[B]"status":"P"[/B], "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2,459589675789,147045472166651", "worktype":"PRP-5", "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
[/CODE]

while for residue type 5 we have:

[CODE]
PRP=1,3,2131,-1,99,0,5,5,"2"
PRP=1,3,2131,-1,99,0,5,5,"2,459589675789"
PRP=1,3,2131,-1,99,0,5,5,"2,459589675789,147045472166651"
[/CODE]

and the output is:

[CODE]
{"status":"C", "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2", "worktype":"PRP-5", [B]"res64":"C6369199A87B8799"[/B], "residue-type":5, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
{"status":"C", "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2,459589675789", "worktype":"PRP-5", [B]"res64":"DD08BBFDEC5278FB"[/B], "residue-type":5, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
{[B]"status":"C"[/B], "k":1, "b":3, "n":2131, "c":-1, "known-factors":"2,459589675789,147045472166651", "worktype":"PRP-5", [B]"res64":"57CA39292A83D0FD"[/B], "residue-type":5, "fft-length":160, "error-code":"00000000", "security-code":"10A610A6", "program":{"name":"Prime95", "version":"29.4", "build":8, "port":8}, ...}
[/CODE]

and for both type-1 and type-5, the residues, as calculated by mprime, change as we add known factors to the factor string.


And additionally, type-5 fails to recognize that the final cofactor is a probable prime (actually [URL="http://factordb.com/index.php?id=1100000000094644030"]a certified prime[/URL]).