mersenneforum.org  

Go Back   mersenneforum.org > Prime Search Projects > Conjectures 'R Us

Reply
 
Thread Tools
Old 2011-01-21, 14:03   #1
nuggetprime
 
nuggetprime's Avatar
 
Mar 2007
Austria

2·151 Posts
Default 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.
nuggetprime is offline   Reply With Quote
Old 2011-01-21, 22:16   #2
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3×2,083 Posts
Default

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.)
mdettweiler is offline   Reply With Quote
Old 2011-01-21, 22:24   #3
nuggetprime
 
nuggetprime's Avatar
 
Mar 2007
Austria

12E16 Posts
Default

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.
nuggetprime is offline   Reply With Quote
Old 2011-01-21, 22:56   #4
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

141518 Posts
Default

Quote:
Originally Posted by nuggetprime View Post
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.)
mdettweiler is offline   Reply With Quote
Old 2011-01-22, 16:28   #5
Jean Penné
 
Jean Penné's Avatar
 
May 2004
FRANCE

10608 Posts
Default 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
Jean Penné is offline   Reply With Quote
Old 2011-01-22, 21:54   #6
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

11000011010012 Posts
Default

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
mdettweiler is offline   Reply With Quote
Old 2011-01-22, 23:36   #7
Cruelty
 
Cruelty's Avatar
 
May 2005

2·809 Posts
Default

Quote:
Originally Posted by mdettweiler View Post
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)...
Cruelty is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the problem here? didgogns Msieve 1 2016-11-15 03:31
problem 2.4 MattcAnderson Puzzles 4 2014-08-21 04:40
Sieving, PRPing, and what I feel is a common misunderstanding jasong Sierpinski/Riesel Base 5 10 2006-12-27 00:41
51 problem Neves Miscellaneous Math 5 2004-02-10 22:59
51 problem 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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.