mersenneforum.org Problem with LLR 3.8x for PRPing!
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2011-01-21, 14:03 #1 nuggetprime     Mar 2007 Austria 2·151 Posts Problem with LLR 3.8x for PRPing! 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: Code: 245*830^492-1 is not prime. RES64: FC47BD5F01792B65. OLD64: F4D7381D046B822C Time : 230.578 ms. Wrong RES64 from LLR 3.8.4: Code: 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.
 2011-01-21, 22:16 #2 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 3×2,083 Posts 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.)
 2011-01-21, 22:24 #3 nuggetprime     Mar 2007 Austria 12E16 Posts 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.
2011-01-21, 22:56   #4
mdettweiler
A Sunny Moo

Aug 2007
USA (GMT-5)

141518 Posts

Quote:
 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.)

 2011-01-22, 16:28 #5 Jean Penné     May 2004 FRANCE 10608 Posts LLR Version 3.8.4 : user interface bug fixed! 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
 2011-01-22, 21:54 #6 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 11000011010012 Posts 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.) Last fiddled with by mdettweiler on 2011-01-22 at 21:55
2011-01-22, 23:36   #7
Cruelty

May 2005

2·809 Posts

Quote:
 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:
Quote:
 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)...

 Similar Threads Thread Thread Starter Forum Replies Last Post didgogns Msieve 1 2016-11-15 03:31 MattcAnderson Puzzles 4 2014-08-21 04:40 jasong Sierpinski/Riesel Base 5 10 2006-12-27 00:41 Neves Miscellaneous Math 5 2004-02-10 22:59 Neves Puzzles 15 2004-02-05 23:11

All times are UTC. The time now is 19:34.

Fri Sep 18 19:34:36 UTC 2020 up 8 days, 16:45, 1 user, load averages: 1.59, 1.70, 1.89