Different results in llr2 1.3.0

[R. Gerbicz]

Originally Posted by JeppeSN

As far as I understand Pavel Atnashev who made LLR2, it can do a test of such numbers (c ≠ ±1), even with Gerbicz hardware error check

Clearly a bug, the algorithm is more than perfect.

[Prime95]

Originally Posted by MischaR

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

A couple of things going on.

First, there was a bug that has been there forever. The routine gwsetaddin does not work with numbers of the form 1*b^n+c using zero-padded FFTs. I guess no one used this routine. I've fixed this bug (except in the x87 code path).

Second, the new routines gwmuladd4 and gwmulsub4 introduced in version 30.4 had problems with zero-padded FFTs. This wasn't much of an issue until gwsquare_carefully and gwmul_carefully switched to using these new routines in version 30.5. This bug has been fixed. I'll put these fixes into a new version 30.10.

[pepi37]

Originally Posted by Prime95

A couple of things going on.

First, there was a bug that has been there forever. The routine gwsetaddin does not work with numbers of the form 1*b^n+c using zero-padded FFTs. I guess no one used this routine. I've fixed this bug (except in the x87 code path).

Second, the new routines gwmuladd4 and gwmulsub4 introduced in version 30.4 had problems with zero-padded FFTs. This wasn't much of an issue until gwsquare_carefully and gwmul_carefully switched to using these new routines in version 30.5. This bug has been fixed. I'll put these fixes into a new version 30.10.

And if you can add

https://mersenneforum.org/showpost.php?p=616316&postcount=757

[JeppeSN]

Originally Posted by Prime95

A couple of things going on.

First, there was a bug that has been there forever. The routine gwsetaddin does not work with numbers of the form 1*b^n+c using zero-padded FFTs. I guess no one used this routine. I've fixed this bug (except in the x87 code path).

Second, the new routines gwmuladd4 and gwmulsub4 introduced in version 30.4 had problems with zero-padded FFTs. This wasn't much of an issue until gwsquare_carefully and gwmul_carefully switched to using these new routines in version 30.5. This bug has been fixed. I'll put these fixes into a new version 30.10.

It was also found that numbers like 1385084*391^3437-1 and 1385270*391^2588-1 can be incorrectly reported as "not prime" by LLR2:

1385084*391^3437-1 is not prime, although Fermat PSP! P = 3, Lucas RES64: CF91244F7FB614D5  Time : 1.384 sec.
1385270*391^2588-1 is not prime, although Fermat PSP! P = 6, Lucas RES64: 90668F73899D0060  Time : 793.228 ms.

Using switch -oForceGeneric=1 says prime, as expected. patnashev will report this bug of gwnum.

[bur]

Can bugs like these be detected by Gerbicz error checking? For the two provided numbers it obviously did not happen, but maybe the base is the problem or the size?

And it made me wonder, how probable is it that undetected bugs are present in LLR2 or prime95 causing primes to be overlooked? For good reason detected primes are double-checked by other software, but not so for composites.

[rebirther]

Originally Posted by bur

Can bugs like these be detected by Gerbicz error checking? For the two provided numbers it obviously did not happen, but maybe the base is the problem or the size?

And it made me wonder, how probable is it that undetected bugs are present in LLR2 or prime95 causing primes to be overlooked? For good reason detected primes are double-checked by other software, but not so for composites.

The current bug is not affected while using Gerbicz error checking. with llr2.

[Jean Penné]

Originally Posted by JeppeSN

It was also found that numbers like 1385084*391^3437-1 and 1385270*391^2588-1 can be incorrectly reported as "not prime" by LLR2:

1385084*391^3437-1 is not prime, although Fermat PSP! P = 3, Lucas RES64: CF91244F7FB614D5  Time : 1.384 sec.
1385270*391^2588-1 is not prime, although Fermat PSP! P = 6, Lucas RES64: 90668F73899D0060  Time : 793.228 ms.

Using switch -oForceGeneric=1 says prime, as expected. patnashev will report this bug of gwnum.

Exactly the same behavior with LLR V4.0.3
Jean

[bur]

Originally Posted by rebirther

The current bug is not affected while using Gerbicz error checking. with llr2.

I thought Gerbicz error checking was automatically used with LLR2, isn't it? When just running ./sllr2 -d -q"1385084*391^3437-1" I get the same output as posted by Jeppe.

Or did I get you wrong?

I noted it is the same with LLR2 1.1.1 - so it's generally not found prime by any LLR?


edit: And yet another question, sorry. Does this mean it's possible to have missed some base-2 Proth primes? Or is it apparently only affecting specific types of numbers?

[rebirther]

Originally Posted by bur

I thought Gerbicz error checking was automatically used with LLR2, isn't it? When just running ./sllr2 -d -q"1385084*391^3437-1" I get the same output as posted by Jeppe.

Or did I get you wrong?

I noted it is the same with LLR2 1.1.1 - so it's generally not found prime by any LLR?


edit: And yet another question, sorry. Does this mean it's possible to have missed some base-2 Proth primes? Or is it apparently only affecting specific types of numbers?

no, Gerbiczcheck is not automatically, you must add -oGerbicz=1 to commandline

[bur]

I checked and Gerbicz is used automatically for Proth numbers. Anyway, from the output it looks like it's not that Gerbicz detects the error, but simply because when Gerbicz is enabled, then LLR2 only performs a PRP test - unless the candidate is a Proth number - and that PRP test is successful either way (see non-Gerbicz output):

$ ./sllr2 -v && ./sllr2 -d -q"1385084*391^3437-1" -oGerbicz=1
LLR2 Program - Version 1.1.1, using Gwnum Library Version 30.4
Gerbicz check is requested, switching to PRP.
Starting probable prime test of 1385084*391^3437-1
Using zero-padded FMA3 FFT length 4K, a = 3, L2 = 15*14
1385084*391^3437-1, bit: 1156 / 3437 [33.63%], 1050 checked.  Time per bit: 0.23
1385084*391^3437-1, bit: 2311 / 3437 [67.23%], 2310 checked.  Time per bit: 0.23

1385084*391^3437-1 is base 3-Fermat PRP! (8916 decimal digits)  Time : 829.397 ms.
(Factorized part = 99.93%)
Candidate saved in file t1748697.in for further test with Primo.

Another thing, I ran LLR2 1.1.1 on two different systems and got different results.

i9-10920x

$ ./sllr2 -v && ./sllr2 -d -q"1385084*391^3437-1"
LLR2 Program - Version 1.1.1, using Gwnum Library Version 30.4
Base factorized as : 17*23
Base prime factor(s) taken : 23
Starting N+1 prime test of 1385084*391^3437-1
Using zero-padded AVX-512 FFT length 4608, a = 3

1385084*391^3437-1 may be prime. Starting Lucas sequence...
Using zero-padded AVX-512 FFT length 4608, P = 3

1385084*391^3437-1 may be prime, trying to compute gcd's
U((N+1)/23) is coprime to N!

1385084*391^3437-1 is prime! (8916 decimal digits, P = 3)  Time : 1.030 sec.

Ryzen 9 3900x

$ ./sllr2 -v && ./sllr2 -d -q"1385084*391^3437-1"
LLR2 Program - Version 1.1.1, using Gwnum Library Version 30.4
Base factorized as : 17*23
Base prime factor(s) taken : 23
Starting N+1 prime test of 1385084*391^3437-1
Using zero-padded FMA3 FFT length 4K, a = 3

1385084*391^3437-1 may be prime. Starting Lucas sequence...
Using zero-padded FMA3 FFT length 4K, P = 3

1385084*391^3437-1 is not prime, although Fermat PSP! P = 3, Lucas RES64: CF91244F7FB614D5  Time : 1.558 sec.

So the bug is only affecting FMA3 FFT?

[rebirther]

You are using an older llr2 app, try the latest
https://github.com/patnashev/llr2/releases

If you only running llr2 use Gerbicz check or take an older llr version with gwnum 29.x, the current gwnum has some bugs.