mersenneforum.org llr 3.8 questions
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2010-02-01, 13:37 #1 VJS     Dec 2004 13×23 Posts llr 3.8 questions Are we going to be switching to the 3.8 llr version SB says 2-5% faster... perhaps we have and I'm still using the old client...
 2010-02-01, 13:59 #2 opyrt     Apr 2008 Oslo, Norway 110110012 Posts Hi VJS! Jean has not released any new client to his webpage, so I'm currently trying to get hold of the friendly guys over at PG to ask if they'll be willing to share it with us. I'm also in the process of creating new client packages with prpclient 2.4.7 (same as our servers), so getting the new llr-client now would be perfect. I'll keep this thread updated! Edit: Looks like 3.8.0 will be officially released very, very soon. Thanks to Lennart for letting me know. :) Last fiddled with by opyrt on 2010-02-01 at 14:39
2010-02-01, 19:52   #3
Joe O

Aug 2002

20D16 Posts

Quote:
 Originally Posted by opyrt Hi VJS! Jean has not released any new client to his webpage, so I'm currently trying to get hold of the friendly guys over at PG to ask if they'll be willing to share it with us. I'm also in the process of creating new client packages with prpclient 2.4.7 (same as our servers), so getting the new llr-client now would be perfect. I'll keep this thread updated! Edit: Looks like 3.8.0 will be officially released very, very soon. Thanks to Lennart for letting me know. :)
Quote:
 Originally Posted by T.Rex Last news is that Jean delivered a stable 3.8.0 version. He is now working on the documentation. A lot of work, he said. I should read his work before publishing it, I proposed, and he accepted. Wait some more. T.

 2010-02-01, 20:02 #4 opyrt     Apr 2008 Oslo, Norway 7×31 Posts Thanks alot, Joe!
 2010-02-08, 10:06 #5 opyrt     Apr 2008 Oslo, Norway 7·31 Posts Just an update: The official release of llr 3.8.0 is likely to be released this week. It will probably not be equal to the development version PrimeGrid is using at the moment, so for those of you who got your hands on that one, you might want to upgrade. The new PRPclient 2.4.7 package is ready thanks to user runesk, and we're just waiting for the new llr in order to make it publicly available. :)
 2010-02-08, 21:25 #6 Jean Penné     May 2004 FRANCE 3×193 Posts LLR Version 3.8.0 is now available! Hi, The LLR Version 3.8.0 is now available on my personal site : http://jpenne.free.fr/index2.html To-day, this version is identical to the Development one, as I updated it for the last time (to-day also!) and will now be stable, so I suggest to use it now preferably. Best Regards, Jean
2010-02-08, 22:12   #7
runesk

Oct 2008
Trondheim, Norway

238 Posts

Quote:
 Originally Posted by Jean Penné Hi, The LLR Version 3.8.0 is now available on my personal site : http://jpenne.free.fr/index2.html
I'm about to include these in the prpclient packages, and noticed the macintel version gives a 404 error (http://jpenne.free.fr/llr3/llr380mac.zip)

.R

2010-02-09, 06:22   #8
Jean Penné

May 2004
FRANCE

3×193 Posts

Quote:
 Originally Posted by runesk I'm about to include these in the prpclient packages, and noticed the macintel version gives a 404 error (http://jpenne.free.fr/llr3/llr380mac.zip) .R
I shall update this page to notice this version is not yet available!
Regards,
Jean

 2010-03-03, 00:12 #9 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 11000011010012 Posts (Note: even though these remarks aren't particularly related to PSP, I couldn't find an "official" release-announcement thread for LLR 3.8 and it seems Jean monitors this thread, so I posted it here.) Hi Jean, I have two bugs to report in LLR 3.8. I've separated the bugs with a line between them to avoid confusion. First of all, when the program encounters a roundoff error and tries to resume from the latest save file on the next-higher FFT, it appears to not be incrementing the FFT--it just tries it again with the same one, which of course errors out again, starting the cycle over. This results in an infinite loop. Note that I haven't actually been able to reproduce this myself; I get what seems to be a different sort of bug. Here's the contents of the lresults.txt from the person who initially discovered this: Code: 100542584*3^326-1 is not prime. RES64: FDCBF11CBD949DB8. OLD64: 9CDDA336E292EDB7 Time : 5.832 ms. 100542584*3^327-1 is not prime. RES64: 8828751C67D74542. OLD64: 98795F553785CFC3 Time : 1.112 ms. 100542584*3^328-1 is not prime. RES64: AF0F967B018B1A05. OLD64: 0D2EC37104A14E0C Time : 23.712 ms. 100542584*3^329-1 is not prime. RES64: 0BC6192E5B9C413B. OLD64: 612B383CFC4DEEE0 Time : 1.098 ms. 100542584*3^330-1 is not prime. RES64: 858763DE10557C9C. OLD64: 4A20F1AFED6BF763 Time : 1.736 ms. 100542584*3^331-1 is not prime. RES64: F62BB139C363FC20. OLD64: 78D33CCDE4CD36B6 Time : 1.118 ms. 100542584*3^332-1 is not prime. RES64: 16D3F5810CDB888A. OLD64: CA5CD746C65A27AD Time : 1.086 ms. 100542584*3^333-1 is not prime. RES64: D161A7B4A11D97EA. OLD64: BCF6694353041CD4 Time : 1.102 ms. 100542584*3^334-1 is not prime. RES64: 8AC3F5B355AAD00E. OLD64: 7AC0378A50026F70 Time : 1.708 ms. 100542584*3^335-1 is not prime. RES64: 6736C9D7E97D4CCF. OLD64: C50160D8A97DE443 Time : 1.125 ms. 100542584*3^336-1 is not prime. RES64: B65E42722A31566F. OLD64: D131D14945A5FCD3 Time : 1.146 ms. 100542584*3^337-1 is not prime. RES64: CDFAB4C26501BE9F. OLD64: 7E7A59F7D971150C Time : 32.833 ms. 100542584*3^338-1 is not prime. RES64: 9CCAA4CC820D465F. OLD64: F52F47EE85C998E3 Time : 1.927 ms. 100542584*3^339-1 is not prime. RES64: 068CBF65D4E28A02. OLD64: 13A63E317EA79E03 Time : 1.445 ms. 100542584*3^340-1 is not prime. RES64: A2DAE029B63CEEF2. OLD64: FDDAC64E1F66C0DC Time : 2.059 ms. 100542584*3^341-1 is not prime. RES64: 615F2CD76A644608. OLD64: 63FBF7F9353CAE2E Time : 1.331 ms. 100542584*3^342-1 is not prime. RES64: 5996C0C773651BB4. OLD64: 8BFAEB081E8E7BAB Time : 1.789 ms. 100542584*3^343-1 is not prime. RES64: 4813E4310051A928. OLD64: D83BAC9300F4FB75 Time : 1.383 ms. 100542584*3^344-1 is not prime. RES64: 49FF3A27FFC4CA16. OLD64: 56E99CB7E6A6CB51 Time : 1.402 ms. 100542584*3^345-1 is not prime. RES64: ABC93293D1BC0131. OLD64: 6E1F627B2B3D4AC2 Time : 1.322 ms. Iter: 27/575, ERROR: ROUND OFF (0.5) > 0.40 Continuing from last save file. 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. 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. 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. 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. The number he encountered this error on should be 100542584*3^346-1 since he was testing a bunch of Riesel base 3 numbers in strict sequence. However, when I try to run this same number through a local copy of cllr 3.8, I get this: Code: $./cllr.exe -d -q"100542584*3^346-1" Base prime factor(s) taken : 3 It doesn't even seem to do anything, but rather puts me back at the command line. ----------------------------------------- The other bug, for dual-Sierpinski numbers (the form b^n+k), was apparently introduced in version 3.8 that prevents it from properly testing PRPs of that form. For example: Code: $ ./cllr.exe -d -q"2^21954+77899" Starting probable prime test of 2^21954+77899 Using zero-padded FFT length 2048, a = 3 2^21954+77899 is not prime. RES64: 6F462A3A469B3DAE. OLD64: 4DD27EAED3D088BC Time : 629.731 ms. And the same number in version 3.7.1c: Code: $./cllr371c.exe -d in.txt LLR tests only k*2^n+/-1 numbers, so, we will do a PRP test of 2^21954+77899 Starting probable prime test of 2^21954+77899 Using zero-padded FFT length 2048 2^21954+77899 is a probable prime. Time : 648.602 ms. Please credit George Woltman's PRP for this result! Also, for composites of this form the residuals are not consistent between 3.7.1c and 3.8.0: Code: 3.8.0:$ ./cllr.exe -d in.txt Starting probable prime test of 2^21955+77899 Using zero-padded FFT length 2048, a = 3 2^21955+77899 is not prime. RES64: 5EE049734D2C54B1. OLD64: 1CA0DC59E784FE10 Time : 637.313 ms. 3.7.1c: \$ ./cllr371c.exe -d in.txt LLR tests only k*2^n+/-1 numbers, so, we will do a PRP test of 2^21955+77899 Starting probable prime test of 2^21955+77899 Using zero-padded FFT length 2048 2^21955+77899 is not prime. RES64: B3DBC42D6C20A8D4. OLD64: 1B934C884460CA2E Time : 636.798 ms. I suspect a bug in 3.8.0 that throws off the residue; that would explain the issue with PRPs as well, since the residue is supposed to be 0 but instead comes out as something different, hence appearing as a composite. Thanks, Max
2010-03-03, 07:36   #10
Jean Penné

May 2004
FRANCE

24316 Posts

Quote:
 Originally Posted by mdettweiler (Note: even though these remarks aren't particularly related to PSP, I couldn't find an "official" release-announcement thread for LLR 3.8 and it seems Jean monitors this thread, so I posted it here.)
The "official" release announcement is in thread "Software" :

Also, in this thread, I informed the users that LLR 3.8.0 has a bug which affects only k*b^n+c numbers with |c| != 1; this bug is fixed in the development version that can be dowloaded at :

http://jpenne.free.fr/Development/

Then, the second bug you found disappears :

>cllr -d -a70 -q"2^21954+77899"
Starting probable prime test of 2^21954+77899
Using zero-padded FFT length 2048, a = 3
2^21954+77899 is base 3-Strong Fermat PRP! Time : 4.909 sec.
Starting Lucas sequence
Using zero-padded FFT length 2048, P = 4, Q = 2
2^21954+77899 is Lucas PRP, Starting Frobenius test sequence
Using zero-padded FFT length 2048, Q = 2
2^21954+77899 is Frobenius PRP! (P = 4, Q = 2, D = 8) Time : 13.831 sec.

>cllr -d -a70 -q"2^21955+77899"
Starting probable prime test of 2^21955+77899
Using zero-padded FFT length 2048, a = 3
2^21955+77899 is not prime. RES64: B3DBC42D6C20A8D4. OLD64: 1B934C884460CA2E Time : 4.955 sec.

However, the first problem remains in the development version...
gwnum has still problems with very small numbers, and I have to look again on my error recovery code!

Regards,
Jean

2010-03-03, 07:58   #11
mdettweiler
A Sunny Moo

Aug 2007
USA (GMT-5)

11000011010012 Posts

Quote:
 Originally Posted by Jean Penné The "official" release announcement is in thread "Software" : http://www.mersenneforum.org/showthread.php?t=13072
Ah, I see it now. I checked that forum earlier but somehow I skipped over that thread. A mod can feel free to move my post and all posts following from it to that thread.

Quote:
 Also, in this thread, I informed the users that LLR 3.8.0 has a bug which affects only k*b^n+c numbers with |c| != 1; this bug is fixed in the development version that can be dowloaded at : http://jpenne.free.fr/Development/ Then, the second bug you found disappears : >cllr -d -a70 -q"2^21954+77899" Starting probable prime test of 2^21954+77899 Using zero-padded FFT length 2048, a = 3 2^21954+77899 is base 3-Strong Fermat PRP! Time : 4.909 sec. Starting Lucas sequence Using zero-padded FFT length 2048, P = 4, Q = 2 2^21954+77899 is Lucas PRP, Starting Frobenius test sequence Using zero-padded FFT length 2048, Q = 2 2^21954+77899 is Frobenius PRP! (P = 4, Q = 2, D = 8) Time : 13.831 sec. >cllr -d -a70 -q"2^21955+77899" Starting probable prime test of 2^21955+77899 Using zero-padded FFT length 2048, a = 3 2^21955+77899 is not prime. RES64: B3DBC42D6C20A8D4. OLD64: 1B934C884460CA2E Time : 4.955 sec.
Oh, right! I forgot about the |c| != 1 bug; somehow I didn't connect the dots in my head that b^n+k would count as that. Thanks, that was a mistake on my part since I was already aware of that bug.

Quote:
 However, the first problem remains in the development version... gwnum has still problems with very small numbers, and I have to look again on my error recovery code!
Thanks!

 Similar Threads Thread Thread Starter Forum Replies Last Post Dubslow GPU Computing 1 2011-08-05 18:22 Carmichael Factoring 8 2007-04-10 11:30 OmbooHankvald Prime Sierpinski Project 2 2005-08-01 20:18 OmbooHankvald Math 6 2005-06-23 11:42 xtreme2k Lounge 59 2002-10-31 06:20

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

Sat Jun 12 19:50:07 UTC 2021 up 15 days, 17:37, 0 users, load averages: 1.73, 1.31, 1.29