20220713, 09:10  #1 
May 2004
FRANCE
2×5×61 Posts 
LLR Version 4.0.2 released.
Hi All,
I uploaded today the version 4.0.1 of the LLR program. You can find the new Version 4.0.2 now on my personal site : http://jpenne.free.fr/ The 32bit Windows and Linux compressed binaries are available as usual. The Linux 64bit binaries are released here, and also the Mac OS 64bit binaries. The Mac OS 32bit is not released here because I have not the 32bit hwloc library which is needed, and could not build it on my Mac mini... I uploaded also the complete source in a compressed file ; it may be used to build the 64bit Windows binaries. What is new in this version : The Affinity managing was not really implemented on LLR... This issue is now fixed on Linux and WIN32 versions. The option oAffinity=2 allows the progam to run on logical core 2. You may now also choose a list of cores by setting oAffinity="2,3,5" for example. The Mac OS binary remains identical to 4.0.1 one because Affinity management seems not to be available on MAC OS platforms. In previous Version 4.0.0, one call to free() function was missing in Gerbicz error checking code ; this caused an important memory leak... This issue is now fixed here! This version is linked with the last version 30.6 of George Woltman's gwnum library. No really new feature, from 3.8.24, but some improvements related to reliability and speed. I avoid now the use of giants functions invg() and gcdg() which are slow and seem not to be very reliable. To do that, I am using gtompz() and mpztog() conversion functions. Also, I replaced everywhere the gwnum squaring and multiplication functions gwsquare() and gwmul() by their new forms : gwsquare2(), gwmul3(), gwmul3_carefully(), etc... As usual, I need help to build the 64bit Windows binaries. I uploaded also the GNU gmp6.1.0 compressed source I used on 32bit VC6.0 I hope it can be used to build this library on Windows 64bit and link it with LLR... Please, inform me if you encountered any problem while using this new version. Best Regards, Jean 
20220730, 13:16  #2 
"Alexander"
Nov 2008
The Alamo City
863 Posts 
The NewPGen 0x100 mask support which was added in version 4.0.0 (which was taken to mean 2k*b^n3) completely breaks support for srsieve, which includes that bit in the standard Riesel and Proth masks (which are 258 and 257 in srsievegenerated outputs, respectively).

20220812, 14:53  #3 
May 2004
FRANCE
610_{10} Posts 
Windows 64 bits console binaries are now available!
Hi all,
Thanks to the help of Mark Rodenkirsch and George Woltman, I succeeded to build the Win64 console binaries cllr64 and cllrd64. So, these two binaries are now available on my personal site : http://jpenne.free.fr I did not upload the new source because the build of the Win64 GUI version is not yet possible using it. Nevertheless, I hope these binaries would be useful. Best Regards, Jean 
20220815, 14:52  #4 
May 2004
FRANCE
2×5×61 Posts 
Windows 64 bits GUI application is now available!
Hi All,
Finally, I succeeded to build the Win64 GUI application of LLR 4.0.2 so, you can now download it on my personal site. Best Regards, Jean 
20220815, 15:36  #5 
Dec 2011
After milion nines:)
7·229 Posts 
This is my input file called input.npg
Code:
1600000000000000:M:1:10:258 962 11943 Why Morrison prime test is running and from where is candidate 1924*10^119433? And what is service control manager that cannot be opened? Thanks for reply. Last fiddled with by pepi37 on 20220815 at 15:37 
20220815, 18:07  #6  
May 2004
FRANCE
1142_{8} Posts 
Quote:
I drop it in LLR because its code causes many unresolved addresses at link... To avoid continuing the test of a Cunnigham chain after a prime is found, use the option oUseCharCode=1 Regards, Jean 

20220815, 20:21  #7  
Dec 2011
After milion nines:)
7×229 Posts 
Quote:
I dont need it at all, I just ask what is that option :) Thanks for answer Best regards 

20220928, 15:33  #8 
Sep 2022
5 Posts 
LLR may return a wrong result after a seemingly successful test
There is a potentially unwanted feature in all versions of llr:
Given as input a sufficiently large number of the form k*2^n+1, before running a Proth or LucasLehmerRiesel primality test, the program only checks if k<2^n without checking if k is odd and, if it isn't, rewriting the number (by halving k until it's odd, checking that k isn't 1 and adding the number of times k was halved to n). As a result, the test is run using wrong values of k and n and the program reports Proth and Riesel primes written differently as composite. When llrCUDA is given the same input it sometimes reports the number as composite after just the Fermat PRP test. This shouldn't be possible, so it's either misprinting what it's doing or there's another issue. Below are some examples, followed by a Proth test run by Proth20 (which has checks in place). Code:
login@debian:~/Downloads$ ./llr402linux64/llr64 d q"5046*2^349007+1" Starting Proth prime test of 5046*2^349007+1 Using allcomplex FMA3 FFT length 24K, Pass1=512, Pass2=48, clm=2, a = 11 5046*2^349007+1 is not prime. Base11 Proth RES64: 91E6E3224C101AF9. Time : 31.468 sec. login@debian:~/Downloads$ ./llr402linux64/llr64 d q"2523*2^349008+1" Starting Proth prime test of 2523*2^349008+1 Using allcomplex FMA3 FFT length 24K, Pass1=512, Pass2=48, clm=2, a = 11 2523*2^349008+1 is prime! (105066 decimal digits) Time : 30.436 sec. login@debian:~/Downloads$ ./llr402linux64/llr64 d q"5046*2^3490061" Starting Fermat PRP test of 5046*2^3490061 Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3 5046*2^3490061 is a Fermat Probable prime! (105065 decimal digits) Time : 29.183 sec. Starting Lucas Lehmer Riesel prime test of 5046*2^3490061 Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2 5046*2^3490061 is not prime. LLR Res64: 780F16FCFA632B43 Time : 26.023 sec. login@debian:~/Downloads$ ./llr402linux64/llr64 d q"2523*2^3490071" Starting Fermat PRP test of 2523*2^3490071 Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2, a = 3 2523*2^3490071 is a Fermat Probable prime! (105065 decimal digits) Time : 29.064 sec. Starting Lucas Lehmer Riesel prime test of 2523*2^3490071 Using FMA3 FFT length 24K, Pass1=384, Pass2=64, clm=2 2523*2^3490071 is prime! (105065 decimal digits) Time : 25.877 sec. login@debian:~/Downloads$ ./llrcuda386src/llrCUDA d q"5046*2^349007+1" Starting Proth prime test of 5046*2^349007+1 Using complex irrational base DWT, FFT length = 49152, a = 11 5046*2^349007+1 is not prime. Base11 Proth RES64: 0000000000000001. Time : 141.737 sec. login@debian:~/Downloads$ ./llrcuda386src/llrCUDA d q"2523*2^349008+1" Starting Proth prime test of 2523*2^349008+1 Using complex irrational base DWT, FFT length = 49152, a = 11 2523*2^349008+1 is prime! (105066 decimal digits) Time : 140.751 sec. login@debian:~/Downloads$ ./llrcuda386src/llrCUDA d q"5046*2^3490061" Starting Fermat PRP test of 5046*2^3490061 Using real irrational base DWT, FFT length = 40960, a = 3 5046*2^3490061 is not prime. RES64: 74CEEAD9C89D6450. Time : 124.897 sec. login@debian:~/Downloads$ ./llrcuda386src/llrCUDA d q"2523*2^3490071" Starting Fermat PRP test of 2523*2^3490071 Using real irrational base DWT, FFT length = 40960, a = 3 2523*2^3490071 is a Fermat Probable prime! (105065 decimal digits) Time : 124.103 sec. Starting Lucas Lehmer Riesel prime test of 2523*2^3490071 Using real irrational base DWT, FFT length = 40960 V1 = 3 ; Computing U0...done. 2523*2^3490071 is prime! (105065 decimal digits) Time : 121.779 sec. login@debian:~/Downloads$ ./proth20/bin/proth20 q"5046*2^349007+1" proth20 0.9.1 linux64 gcc8.3.0 Copyright (c) 2020, Yves Gallot proth20 is free source code, under the MIT license. Testing 2523 * 2^349008 + 1, 105066 digits, size = 2^16 x 21 bits, plan: 256_4 sq_256 p2i_4_64 2523 * 2^349008 + 1 is prime, a = 11, time = 00:00:46 Last fiddled with by ruckuslemur on 20220928 at 16:05 
20220928, 21:41  #9  
"Alexander"
Nov 2008
The Alamo City
863 Posts 
Quote:


20220929, 20:43  #10 
Sep 2022
5 Posts 
Which iteration count do you mean? I tried hardcoding a "final_count += 1;" in GerbiczTest() at line 7458 of Llr.c (nonCUDA) and the Proth test still reported 5046*2^349007+1 as composite, though with a different RES64. Incrementing final_count by more than 1 caused the program to crash, but tests with odd k ran fine with final_count incremented by 1 so that variable likely isn't the iteration count for the test.
Last fiddled with by ruckuslemur on 20220929 at 20:53 
20221005, 17:56  #11  
May 2004
FRANCE
610_{10} Posts 
Thanks!
Quote:
There are really bugs in IsLLRP() and IsProthP() codes (wrong values of base and exponent passed to gwSetup() function when k is even). These bugs will be fixed in the next release of LLR and of llrCUDA. Best Regards, Jean 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
LLR Version 3.8.21 Released  Jean Penné  Software  26  20190708 16:54 
LLR Version 3.8.20 released  Jean Penné  Software  30  20180813 20:00 
LLR Version 3.8.19 released  Jean Penné  Software  11  20170223 08:52 
LLR Version 3.8.9 released  Jean Penné  Software  37  20131031 08:45 
llr 3.8.2 released as devversion  opyrt  Prime Sierpinski Project  11  20101118 18:24 