View Single Post
Old 2011-02-28, 21:14   #6
Jean Penné
Jean Penné's Avatar
May 2004

23·3·23 Posts
Default The two bugs on LLR 3.8.5 are fixed!


These two bugs are now fixed :

- For 10^500+961, it is really a bug of the strong Fermat PRP code in the Llr.c file. It will be fixed in the Development version ; here is the correct behaviour :

Starting probable prime test of 10^500+961
Using all-complex FFT length 192, a = 3
10^500+961 is base 3-Strong Fermat PRP! Time : 121.052 ms.
Starting Lucas sequence
Using all-complex FFT length 192, P = 5, Q = 3
10^500+961 is strong-Fermat and Lucas PRP, Starting Frobenius test sequence
Using all-complex FFT length 192, Q = 3
10^500+961 is strong-Fermat, Lucas and Frobenius PRP! (P = 5, Q = 3, D = 13) Time : 72.780 ms.

For 5*10^19737+3, it is a gwnum problem : gwnum chooses a full-complex 4K FFT, which seems to be too small, and causes a segmentation fault after a few iterations... And the test works if I force the program to choose the third next larger FFT! Here is the result, using the uncorrected LLR on Linux :

~/llr385src/linuxllr $ ./llr -a3 -oVerbose=1 -oLucasPRPtest=1 -oFFT_Increment=3 -d -q"5*10^19737+3"
Starting Lucas sequence
5*10^19737+3 is Lucas PRP, Starting Frobenius test sequence
5*10^19737+3 is Frobenius PRP! (P = 4, Q = 2, D = 8) Time : 127.685 sec.

The chosen FFT is then Zero padded 10K...

Note : The -oLucasPRPtest=1 is necessary here, to skip the Fermat test which reset the FFT increment at its completion... This drawback will be corrected in the Development version. I shall release it soon...

I shall also warn George about this gwnum problem.
Best Regards,
Jean Penné is offline   Reply With Quote