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...

Hi VJS! :smile:

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=opyrt;204137]Hi VJS! :smile:

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]

[QUOTE=T.Rex;204201]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.[/QUOTE]
:coffee:

Thanks alot, Joe! :tu:

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

LLR Version 3.8.0 is now available!
 

Hi,

The LLR Version 3.8.0 is now available on my personal site :

[url]http://jpenne.free.fr/index2.html[/url]

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

[quote=Jean Penné;204957]Hi,

The LLR Version 3.8.0 is now available on my personal site :

[URL]http://jpenne.free.fr/index2.html[/URL]

[/quote]

I'm about to include these in the prpclient packages, and noticed the macintel version gives a 404 error ([url]http://jpenne.free.fr/llr3/llr380mac.zip[/url])

.R

[QUOTE=runesk;204966]I'm about to include these in the prpclient packages, and noticed the macintel version gives a 404 error ([url]http://jpenne.free.fr/llr3/llr380mac.zip[/url])

.R[/QUOTE]

I shall update this page to notice this version is not yet available!
Regards,
Jean

(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. [/code]
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[/code]
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.[/code]
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![/code]
Also, for composites of this form the residuals are not consistent between 3.7.1c and 3.8.0:
[code][B]3.8.0:[/B]
$ ./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.
[B]3.7.1c[/B]:
$ ./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.[/code]
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 :smile:

[QUOTE=mdettweiler;207177](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.)
[/QUOTE]

The "official" release announcement is in thread "Software" :

[url]http://www.mersenneforum.org/showthread.php?t=13072[/url]

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 :

[url]http://jpenne.free.fr/Development/[/url]

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

[quote=Jean Penné;207207]The "official" release announcement is in thread "Software" :

[URL]http://www.mersenneforum.org/showthread.php?t=13072[/URL][/quote]
Ah, I see it now. I checked that forum earlier but somehow I skipped over that thread. :rolleyes: 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 :

[URL]http://jpenne.free.fr/Development/[/URL]

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.[/quote]
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. :smile: 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![/quote]
Thanks! :smile: