LLR Version 3.8.16 released

[Jean Penné]

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

[Jean Penné]

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

[rebirther]

Jean:
I hope George can also fix the other bug in gwnum with the false negative prime.

[Batalov]

I found a weird "glitch" in the latest LLR. (Pun intended, actually, this is what the Numberphile folks called, in part, the 10²ⁿ-10ⁿ-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:

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:

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

[Prime95]

Originally Posted by JimB

I see that cllr64 -d -oNextFFTifNearLimit=1 -q"10223*2^29588045+1"
does work properly.

Fixed in gwnum 28.8.

[Jean Penné]

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 10²ⁿ-10ⁿ-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:

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:

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