Different results in llr2 1.3.0
 

We were testing for PRPs in the form 6^$a+$a and found conflicting results between LLR2 1.3.0 and other versions.

In LLR2 1.1.0 the sum 6^85481+85481 is found to be PRP:
[CODE]
.\llr2_1.1.0_win64_201114.exe -d -q"6^85481+85481"
Starting probable prime test of 6^85481+85481
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3
6^85481+85481 is base 3-Fermat PRP! (66518 decimal digits) Time : 10.909 sec.
Starting Lucas sequence
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, P = 5, Q = 3
6^85481+85481 is Fermat and Lucas PRP, Starting Frobenius test sequence
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, Q = 3
6^85481+85481 is Fermat, Lucas and Frobenius PRP! (P = 5, Q = 3, D = 13) Time : 56.028 sec.[/CODE]

The same happens with OpenPFGW 4.0.3:
[CODE]
pfgw_win_4.0.3\distribution> .\pfgw64.exe -q"6^85481+85481"
PFGW Version 4.0.3.64BIT.20220704.Win_Dev [GWNUM 29.8]

6^85481+85481 is 3-PRP! (11.1294s+0.0009s)[/CODE]

LLR2 1.3.0 however determines this is not prime:
[CODE]
llr2-1.3.0-win64> .\llr2.exe -d -q"6^85481+85481"
Starting probable prime test of 6^85481+85481
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3
6^85481+85481 is not prime. RES64: BA67AB5CB68EFF1B. OLD64: 2F37021623ACFD4E Time : 10.505 sec.[/CODE]

I'm told one of the differences is the version of gwnum, with the older apps using 29.8 and LLR2 1.3.0 using 30.9

Yeah, I can personally confirm this, being the one to initially get a conflicting result after I attempted to run a confirmatory test on the PRP 6^85,481 + 85,481. It confused me greatly.

Correct results using LLR 4.0.3
 

[QUOTE=MischaR;619031]We were testing for PRPs in the form 6^$a+$a and found conflicting results between LLR2 1.3.0 and other versions.

In LLR2 1.1.0 the sum 6^85481+85481 is found to be PRP:
[CODE]
.\llr2_1.1.0_win64_201114.exe -d -q"6^85481+85481"
Starting probable prime test of 6^85481+85481
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3
6^85481+85481 is base 3-Fermat PRP! (66518 decimal digits) Time : 10.909 sec.
Starting Lucas sequence
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, P = 5, Q = 3
6^85481+85481 is Fermat and Lucas PRP, Starting Frobenius test sequence
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, Q = 3
6^85481+85481 is Fermat, Lucas and Frobenius PRP! (P = 5, Q = 3, D = 13) Time : 56.028 sec.[/CODE]

The same happens with OpenPFGW 4.0.3:
[CODE]
pfgw_win_4.0.3\distribution> .\pfgw64.exe -q"6^85481+85481"
PFGW Version 4.0.3.64BIT.20220704.Win_Dev [GWNUM 29.8]

6^85481+85481 is 3-PRP! (11.1294s+0.0009s)[/CODE]

LLR2 1.3.0 however determines this is not prime:
[CODE]
llr2-1.3.0-win64> .\llr2.exe -d -q"6^85481+85481"
Starting probable prime test of 6^85481+85481
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3
6^85481+85481 is not prime. RES64: BA67AB5CB68EFF1B. OLD64: 2F37021623ACFD4E Time : 10.505 sec.[/CODE]

I'm told one of the differences is the version of gwnum, with the older apps using 29.8 and LLR2 1.3.0 using 30.9[/QUOTE]

LLR Version 4.0.3 gives also correct results :

jpenne@crazycomp:~/Chance$ llr64 -d -q"6^85481+85481"
Starting probable prime test of 6^85481+85481
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3
6^85481+85481 is base 3-Fermat PRP! (66518 decimal digits) Time : 23.654 sec.
Starting Lucas sequence
Using zero-padded FMA3 FFT length 25K, Pass1=320, Pass2=80, clm=2, P = 5, Q = 3
6^85481+85481 is Fermat and Lucas PRP, Starting Frobenius test sequence
Using zero-padded FMA3 FFT length 25K, Pass1=320, Pass2=80, clm=2, Q = 3
6^85481+85481 is Fermat, Lucas and Frobenius PRP! (P = 5, Q = 3, D = 13) Time : 110.724 sec.
jpenne@crazycomp:~/Chance$ llr64 -oBPSW=1 -d -q"6^85481+85481"
Starting probable prime test of 6^85481+85481
Using zero-padded FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 2
6^85481+85481 is base 2-Fermat PRP! (66518 decimal digits) Time : 25.134 sec.
Starting Lucas sequence
Using zero-padded FMA3 FFT length 25K, Pass1=320, Pass2=80, clm=2, P = 1, Q = 2
6^85481+85481 is Fermat and BPSW PRP, Starting Frobenius test sequence
Using zero-padded FMA3 FFT length 25K, Pass1=320, Pass2=80, clm=2, Q = 2
6^85481+85481 is Fermat, BPSW and Frobenius PRP! (P = 1, Q = 2, D = -7) Time : 108.835 sec.

Regards,
Jean

For what it is worth, PARI/GP's function [C]ispseudoprime(6^85481+85481)[/C] returns 1 (i.e. this [I]is[/I] a probable prime). I believe its implementation is independent of gwnum? It does a test that is more thorough than just a 3-PRP test.

Also, this PRP was reported in 2014 by Henri Lifchitz: [URL="http://www.primenumbers.net/prptop/searchform.php?form=6%5E85481%2B85481"]6^85481+85481[/URL]

/JeppeSN

[QUOTE=MischaR;619031]We were testing for PRPs in the form 6^$a+$a and found conflicting results between LLR2 1.3.0 and other versions.[/QUOTE]

If you meant this post as a warning not to use LLR2 1.3.0 that is great.

But if you meant it as a "bug report", I think you posted it in the wrong place. There are no LLR2 development threads/forums here it seems, LLR2 seems to come from here:
[url]https://github.com/patnashev/llr2[/url]

AFAIK, llr2 does not do a PRP test. llr2 cannot do a primality test on this number. So it might be PRP, but llr2 can't tell you because it didn't do a PRP test.

If I am wrong about llr2 regarding its ability to do a PRP test, then please let us know.

[QUOTE=rogue;619060]AFAIK, llr2 does not do a PRP test. llr2 cannot do a primality test on this number. So it might be PRP, but llr2 can't tell you because it didn't do a PRP test.

If I am wrong about llr2 regarding its ability to do a PRP test, then please let us know.[/QUOTE]

An older version of llr2 with gwnum 29.8 is correct, there is a bug in the gwnum 30.9 in the latest llr2 app and was reported today from the primegrid dev, k*b^n+/-1 should not be affected.

Another sample for Riesel / Sieve:

input
175000000000:P:1:51:257
607920 35218

llr2.exe gwnum 30.9
11920*51^35219+1 is not prime. RES64: 5326FBF23EE99827 Time : 12.728 sec.

llr3.8.21
607920*51^35218+1 is not prime. RES64: 5326FBF23EE99827. OLD64: 8C5E80CE11E6EA41 Time : 26.106 sec.

llr2 gwnum 30.4
11920*51^35219+1 is not prime. RES64: 5326FBF23EE99827 Time : 38.737 sec.

llr2 gwnum 29.8
607920*51^35218+1 is not prime. RES64: 5326FBF23EE99827 Time : 51.552 sec.

The app converts the number 607920 / 51 = 11920

[B]@George: only gwnum 30.x is affected[/B]

[QUOTE=rogue;619060][...]
If I am wrong about llr2 regarding its ability to do a PRP test, then please let us know.[/QUOTE]

As far as I understand [URL="https://mersenneforum.org/member.php?u=16221"]Pavel Atnashev[/URL] who made LLR2, it can do a test of such numbers (c ≠ ±1), even with Gerbicz hardware error check and Pietrzak fast verification. But see subsequent info from rebirther above. /JeppeSN

[QUOTE=JeppeSN;619161]As far as I understand [URL="https://mersenneforum.org/member.php?u=16221"]Pavel Atnashev[/URL] who made LLR2, it can do a test of such numbers (c ≠ ±1), even with Gerbicz hardware error check and Pietrzak fast verification. But see subsequent info from rebirther above. /JeppeSN[/QUOTE]

It looks like its correct, the residue is the same as in other versions but we need pay attention on these cases.

This isn't an issue with the latest version of "regular" LLR (4.0.3), with gwnum 30.6:

[code]607920*51^35218+1 is not prime. RES64: 5326FBF23EE99827. OLD64: 8C5E80CE11E6EA41 Time : 21.168 sec.
[/code]