mersenneforum.org LLR Version 3.8.16 released
 Register FAQ Search Today's Posts Mark Forums Read

2015-11-06, 11:43   #34
Jean Penné

May 2004
FRANCE

10738 Posts

Quote:
 Originally Posted by IBethune Hi Jean, Ideally we don't want to use -oNextFFTIfNearLimit since this will increase the FFT size for many candidates (and we have already seen several higher n completed OK). So the question is this - why does LLR 3.8.15 increment the FFT length from 2400K up to 2880K (and the test succeeds) but LLR 3.8.16 only goes from 2400K up to 2560K and aborts with round-off errors? Since this is quite a rare case (it seems), it might be better just to increase the number of times the FFT may be incremented before LLR exits to 5 (or maybe even make it a commandline/ini-file option)? - Iain
I am surprised by this exit... I will carefully look at this code!
Regards,
Jean

2015-11-06, 19:00   #35
Jean Penné

May 2004
FRANCE

571 Posts

Quote:
 Originally Posted by Jean Penné I am surprised by this exit... I will carefully look at this code! Regards, Jean
Sorry! I understand now what happens... In V3.8.15, the FFT length can be incremented without any limit, and restarting occurs... But this solution is bad, because it can be endless! (that really happened).
In V3.8.16, a roundoff error after taking the next FFT length causes an abort, which is also bad...
The solution is simple : I can test the number of fft increments, and will abort if it is too large (5 for example).
I will implement that in the next release...
Regards,
Jean

 2015-11-06, 19:23 #36 rebirther     Sep 2011 Germany 1010100111002 Posts Jean: I hope George can also fix the other bug in gwnum with the false negative prime.
 2015-12-07, 21:29 #37 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 52·373 Posts A bug (old? new?): 10^5236-10^2618-1 I found a weird "glitch" in the latest LLR. (Pun intended, actually, this is what the Numberphile folks called, in part, the 102n-10n-1 numbers). 10^5236-10^2618-1 is a prime but you wouldn't know it from the LLR's output! If one scans as usual the lresults.txt files for "|" or "[^t] prime", they will not find it. Instead, this is what is produced: Code: 10^5214-10^2607-1 is not prime. RES64: 36873FC14B1F7A51. OLD64: A395BF43E15E6EF0 Time : 731.109 ms. 10^5226-10^2613-1 is not prime. RES64: D1632ECDC01349A0. OLD64: 74298C694039DCDE Time : 734.097 ms. 10^5232-10^2616-1 is not prime. RES64: 4528B319791091AD. OLD64: CF7A194C6B31B505 Time : 734.850 ms. Giving up after 11 restarts... Time : 18.224 sec. 10^5244-10^2622-1 is not prime. RES64: C2E6D3A70522D18E. OLD64: 48B47AF50F6874A8 Time : 724.714 ms. 10^5246-10^2623-1 is not prime. RES64: 699CEEBDCA51AC52. OLD64: 3CD6CC395EF504F5 Time : 726.328 ms. ... Here is the input file for debugging: Code: ABC $a^$b-$a^$c-1 10 4008 2004 10 4014 2007 ... 10 5184 2592 10 5214 2607 10 5226 2613 10 5232 2616 10 5236 2618 10 5244 2622 10 5246 2623
2015-12-10, 02:50   #38
Prime95
P90 years forever!

Aug 2002
Yeehaw, FL

2·3·52·72 Posts

Quote:
 Originally Posted by JimB I see that cllr64 -d -oNextFFTifNearLimit=1 -q"10223*2^29588045+1" does work properly.
Fixed in gwnum 28.8.

2015-12-10, 07:31   #39
Jean Penné

May 2004
FRANCE

571 Posts

Quote:
 Originally Posted by Batalov I found a weird "glitch" in the latest LLR. (Pun intended, actually, this is what the Numberphile folks called, in part, the 102n-10n-1 numbers). 10^5236-10^2618-1 is a prime but you wouldn't know it from the LLR's output! If one scans as usual the lresults.txt files for "|" or "[^t] prime", they will not find it. Instead, this is what is produced: Code: 10^5214-10^2607-1 is not prime. RES64: 36873FC14B1F7A51. OLD64: A395BF43E15E6EF0 Time : 731.109 ms. 10^5226-10^2613-1 is not prime. RES64: D1632ECDC01349A0. OLD64: 74298C694039DCDE Time : 734.097 ms. 10^5232-10^2616-1 is not prime. RES64: 4528B319791091AD. OLD64: CF7A194C6B31B505 Time : 734.850 ms. Giving up after 11 restarts... Time : 18.224 sec. 10^5244-10^2622-1 is not prime. RES64: C2E6D3A70522D18E. OLD64: 48B47AF50F6874A8 Time : 724.714 ms. 10^5246-10^2623-1 is not prime. RES64: 699CEEBDCA51AC52. OLD64: 3CD6CC395EF504F5 Time : 726.328 ms. ... Here is the input file for debugging: Code: ABC $a^$b-$a^$c-1 10 4008 2004 10 4014 2007 ... 10 5184 2592 10 5214 2607 10 5226 2613 10 5232 2616 10 5236 2618 10 5244 2622 10 5246 2623
It is not really a bug... I will increase the default value of "maxrestarts" variable to 100 in next release, that, I hope is unlikely to be too small...
Regards,
Jean

 Similar Threads Thread Thread Starter Forum Replies Last Post Jean Penné Software 30 2018-08-13 20:00 Jean Penné Software 11 2017-02-23 08:52 Jean Penné Software 37 2014-01-29 16:32 Jean Penné Software 37 2013-10-31 08:45 opyrt Prime Sierpinski Project 11 2010-11-18 18:24

All times are UTC. The time now is 01:53.

Fri Feb 26 01:53:44 UTC 2021 up 84 days, 22:05, 0 users, load averages: 1.35, 1.39, 1.47