Problem with LLR 3.8x for PRPing!

[nuggetprime]

To everybody who is PRPing candidates using any 3.8 subversion of LLR:
You are in danger of getting incorrect results or even missing primes!
It doesn't happen very often,but it can:
One number where LLR 3.8.x fails is: 245*830^492-1. See for yourself:
Correct result from LLR 3.7.1,also confirmed with PFGW,phrot,and a self-written GMP program:

245*830^492-1 is not prime.  RES64: FC47BD5F01792B65.  OLD64: F4D7381D046B822C  Time : 230.578 ms.

Wrong RES64 from LLR 3.8.4:

245*830^492-1 is not prime.  RES64: E75504D6062020AD.  OLD64: B5FF0E8212606205  Time : 113.636 ms.

So,please don't PRP your candidates using a 3.8 version of LLR. Use the latest PFGW instead:it automatically checks for roundoff errors which can happen for some numbers like these,and it's just as fast.
Don't forget that this problem also applies to PRPNet clients testing candidates with a 3.8x LLR version!
LLr 3.7.1 or phrot are safe too,but they are significantly slower.

[mdettweiler]

What version of LLR 3.8.x are you using? Some of the earlier 3.8.x versions had some issues with bad residuals, but those have now been corrected. You should be good with the latest 3.8.4, which uses the exact same core code as PFGW.

Note also that LLR sometimes produces a different (but still correct) residual on some bases because it ran the test in a different base. (The technical explanation of this is kind of long, but the upshot is, even when LLR's residuals will occasionally differ from PFGW's, LLR will always be consistent with LLR and PFGW with PFGW.)

[nuggetprime]

This was with LLR 3.8.4.
The issue was also confirmed by Jean Penne.
PFGW,contrary to LLR,detects the rounding error occuring and reruns the test with a larger FFT length.

[mdettweiler]

Originally Posted by nuggetprime

This was with LLR 3.8.4.
The issue was also confirmed by Jean Penne.
PFGW,contrary to LLR,detects the rounding error occuring and reruns the test with a larger FFT length.

Hmm...interesting. I wasn't aware of this. Does LLR not even notice the roundoff error at all, or does it detect it but fail to run the test with a larger FFT? (If the latter, then this could be a relapse of an earlier issue.)

[Jean Penné]

Hi All,

The false residue found by nuggetprime is really due to a rounding error, and LLR is quite able to detect it, redo the iteration using a more reliable code, and, if the error persists, to rerun the test while using a larger FFT. But to have this behavior, it is necessary to set

ErrorCheck=1

in the .ini file.
With the Windows GUI application, it is easy to set this option,
and, normally it might be also easy to do that with the Linux or cllr application, by setting -oErrorCheck=1 in the command line...
Unfortunately, due to a bug in the user interface, this command line option was ignored!
This bug is now fixed, and I updated to day all the V 3.8.4 binaries and sources accordingly.

Here is a test of your problematic example :

I:\D\Jean\LLR\llr384dev>cllr -a6 -oVerbose=1 -oErrorCheck=1 -d -q"245*830^492-1"
Base prime factor(s) taken : 83
Starting N+1 prime test of 245*830^492-1
Using FFT length 448, a = 3
Iter: 2806/4779, ERROR: ROUND OFF (0.5) > 0.4
Continuing from last save file.
Resuming N+1 prime test of 245*830^492-1 at bit 2 [0.04%]
Using FFT length 448, a = 3
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Resuming N+1 prime test of 245*830^492-1 at bit 2806 [58.71%]
Using FFT length 448, a = 3
245*830^492-1 is not prime. RES64: FC47BD5F01792B65. OLD64: F4D7381D046B822C Time : 2.292 sec.

Regards,
Jean

[mdettweiler]

Thanks Jean! Just curious, does setting ErrorCheck=1 slow down the program at all? If not, then perhaps it should be set as the default. (I'm guessing there's little or no speed penalty since PFGW presumably has this error checking enabled by default.)

[Cruelty]

Originally Posted by mdettweiler

Thanks Jean! Just curious, does setting ErrorCheck=1 slow down the program at all? If not, then perhaps it should be set as the default. (I'm guessing there's little or no speed penalty since PFGW presumably has this error checking enabled by default.)

It implies error checking every iteration so yes it slows down the test significantly...
According to LLR readme:

11) Error checking and recovery :

- Error checking is done on the first and last 50 iterations, before
writing an intermediate file (either user-requested stop or a
30 minute interval expired), and every 128th iteration.
- After an excessive (> 0.40) and reproducible round off error,
the iteration is redone using a slower and more reliable method.
- If this error was not reproducible, or if the iteration fails again,
the test is restarted from the beginning, using the next larger
FFT length...

The question: is this "standard" procedure not enough in case of LLR and somehow sufficient in case of PFGW? Also, does it affect only base != 2 or is it some general problem?
I am runnning several base =3 and 10 tests for some time, so I wonder if I should redo any tests now? (not to mention base =2 tests)...