LLR Version 4.0.3 released.
 

Hi All,

You can find the new Version 4.0.3 now on my personal site :

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

The 32bit and 64bit Windows compressed binaries are available as usual.
The Linux 64bit binary is also released here.
The 64bit Mac and 32bit Linux binaries are not yet uploaded here due to technical difficulties...

I uploaded also the complete source in a compressed file.

What is new in this version :

I added two new ABC formats, principally to help PRP searchers.
- k*b^n+c format with k, b, c fixed, for example : ABC 22*17^n+13
- (k*b^n+c)/d format with k, b, c, d fixed, for example : ABC (1*16^n+619)/5
- In Proth or LLR tests, even values of k yield a false result...
These bugs are now fixed.

Please, inform me if you encountered any problem while using this new version.
Best Regards,
Jean

MAC OS binary available now.
 

Hi,

I uploaded to-day the binary for MacIntel / MAC OS X 64bit.
Best Regards,

Jean

[QUOTE=Jean Penné;615874] I added two new ABC formats, principally to help PRP searchers.
- k*b^n+c format with k, b, c fixed, for example : ABC 22*17^n+13
- (k*b^n+c)/d format with k, b, c, d fixed, for example : ABC (1*16^n+619)/5
- In Proth or LLR tests, even values of k yield a false result...
These bugs are now fixed.[/QUOTE]

Well, your examples ... you seems to saw [URL="https://github.com/xayahrainie4793/quasi-mepn-data"]my data for minimal primes[/URL]!!!

22*17^n+13 is the family 15{0}D in base 17, which has the first (probable) prime 15(0^24325)D (= 22*17^24326+13), which is the 10404th "base 17 minimal prime", see [URL="https://github.com/xayahrainie4793/quasi-mepn-data/blob/main/kernel17"]https://github.com/xayahrainie4793/quasi-mepn-data/blob/main/kernel17[/URL]

(1*16^n+619)/5 is the family {3}AF in base 16, which has the first (probable) prime (3^116137)AF (= (1*16^116139+619)/5), which is the 2347th "base 16 minimal prime", see [URL="https://github.com/xayahrainie4793/quasi-mepn-data/blob/main/kernel16"]https://github.com/xayahrainie4793/quasi-mepn-data/blob/main/kernel16[/URL]

You can also see [URL="https://docs.google.com/document/d/e/2PACX-1vQct6Hx-IkJd5-iIuDuOKkKdw2teGmmHW-P75MPaxqBXB37u0odFBml5rx0PoLa0odTyuW67N_vn96J/pub"]my article[/URL] for more information.

[QUOTE=sweety439;616220]Well, your examples ... you seems to saw [URL="https://github.com/xayahrainie4793/quasi-mepn-data"]my data for minimal primes[/URL]!!!

22*17^n+13 is the family 15{0}D in base 17, which has the first (probable) prime 15(0^24325)D (= 22*17^24326+13), which is the 10404th "base 17 minimal prime", see [URL="https://github.com/xayahrainie4793/quasi-mepn-data/blob/main/kernel17"]https://github.com/xayahrainie4793/quasi-mepn-data/blob/main/kernel17[/URL]

(1*16^n+619)/5 is the family {3}AF in base 16, which has the first (probable) prime (3^116137)AF (= (1*16^116139+619)/5), which is the 2347th "base 16 minimal prime", see [URL="https://github.com/xayahrainie4793/quasi-mepn-data/blob/main/kernel16"]https://github.com/xayahrainie4793/quasi-mepn-data/blob/main/kernel16[/URL]

You can also see [URL="https://docs.google.com/document/d/e/2PACX-1vQct6Hx-IkJd5-iIuDuOKkKdw2teGmmHW-P75MPaxqBXB37u0odFBml5rx0PoLa0odTyuW67N_vn96J/pub"]my article[/URL] for more information.[/QUOTE]

I am sorry, but in fact, I knew nothing about your work, until receiving your post.
But, around a month ago, I received an e-mail from a professor at Bruxelles.
He ask me questions to know if LLR program could help him while searching for first PRP in series of chains of characters interpreted in base b positional numeration and being the concatenation three chains s1, s and s2
s1 and s2 are small chains and s is the repetition of n characters c, with c a base b digit, so 0 <= c <= b-1 and n may be large.
Indeed, his domain of interest is near yours, and the examples he gave to me are present in your data.
I hope this explanation will be satisfactory for you and I thank you for the information you sent to me about your work, because I am now interested to know more about it.

Best Regards,
Jean
,

A warning for LLR users testing k*b^n+/-1 numbers.
 

Hello to all,

If you are testing k*b^n-1 or k*b^n+1 numbers using an LLR version at least 4.0.0, please take care to set the option -oUseCharCode=1
This is because I added the mask 0x100 to allow the test of 2k.b^n-3 after a positive result, if wanted by the user.
Unfortunately, this mask is always set by srsieve program in the NewPGen header, causing an unwanted second test which, if is it negative, (which is almost always the case) prevents the first positive result to be registered in the .res file...
This mask will be changed in next LLR release.

Sorry for this drawback and Best Regards,

Jean

[QUOTE=Jean Penné;615874]Hi All,

You can find the new Version 4.0.3 now on my personal site :

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

I have found this release to be far faster than any before. I don't use it often now. Still, I am pleased with it. :smile:

I ran into an interesting problem with llr 4.0.3.

It was consistently choosing:

[code]
Base factorized as : 2*19
Base prime factor(s) taken : 19
Starting N-1 prime test of 197361*38^197361+1
Using zero-padded FMA3 FFT length 128K, Pass1=512, Pass2=256, clm=2, a = 3
[/code]

for base 38 Cullens such as 197361*38^197361+1, but when it switched bases it consistently choose a different FFT

[code]
Current FFT beeing too near the limit, next FFT length is forced...
Starting Proth prime test of 158389*40^158389+1
Using generic reduction FMA3 FFT length 100K, Pass1=320, Pass2=320, clm=4, a = 3
[/code]

for base 40 Cullens like this: 158389*40^158389+1.

On another computer running llr 3.8.23 base 40 is still selecting the zero-padded FFT.

The reason I bring this up is that the zero-padded FFT was completing tests in about 550 seconds, but the generic FFT is taking 4x as long even though the base 38 numbers are larger than the base 40 numbers being tested.

I wonder if there is a problem in the FFT selection logic. This is on a 10-core Intel Core i9 iMac released in 2020.

Could it be converting it to base 2 with a very large k(which would need a generic FFT)?

[QUOTE=henryzz;629923]Could it be converting it to base 2 with a very large k(which would need a generic FFT)?[/QUOTE]

Given that it's running a Proth test, that's likely

a small (useful) patch to LLR 4.0.3
 

[QUOTE=Jean Penné;615874]Hi All,

You can find the new Version 4.0.3 now on my personal site :

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

Please, inform me if you encountered any problem while using this new version.
Best Regards,
Jean[/QUOTE]
@Jean -

I have added a rough hack that deals with the special case of Phi(3,-b^n) input for N-1 test in Llr.c
Short summary:
I. N = Phi(3, -b^n) = b[SUP]2n[/SUP] - b[SUP]n[/SUP] + 1, so I use the existing pattern (ABC $a^$b-$a^$c+1) to enter such candidates
[C]ABC $a^$b-$a^$c+1
40301 16384 8192
93500 65536 32768
96873 131072 65536[/C]

II. Currently these are treated as a general number so although they are parallelized, the result is very slow. We can internally identify this condition as "[C]if (format == ABCDN && n == ndiff[/C])"

III. Observe that b[SUP]3n[/SUP] + 1 = (b[SUP]2n[/SUP] - b[SUP]n[/SUP] + 1)(b[SUP]n[/SUP] + 1), so I can use this fast DWT modulus, with one final mod(N). This is very similar to the Gaussian-Mersenne and Gaussian-Eisenstein code branches. The patch [U]is attached[/U] but I simply plugged a couple of places - Jean, because you know the intricacies of your source much better, would you please do a proper treatment of the place where I added "[C]if (0 &&...)[/C]"

IV. the results of typical unit testing are attached too (three cases).

[I]P.S. This is of course useful for N-1 proving of the new 11,8XX,XXX-decimal-digit cyclotomic monster in mere 14 hours on 24 threads, not in ~10 days on 32 threads (with default LLR, generic zero-padded FFT of huge size, e,g, 4608K). [/I]

[QUOTE=Batalov;631559]@Jean -

I have added a rough hack that deals with the special case of Phi(3,-b^n) input for N-1 test in Llr.c
Short summary:
I. N = Phi(3, -b^n) = b[SUP]2n[/SUP] - b[SUP]n[/SUP] + 1, so I use the existing pattern (ABC $a^$b-$a^$c+1) to enter such candidates
[C]ABC $a^$b-$a^$c+1
40301 16384 8192
93500 65536 32768
96873 131072 65536[/C]

II. Currently these are treated as a general number so although they are parallelized, the result is very slow. We can internally identify this condition as "[C]if (format == ABCDN && n == ndiff[/C])"

III. Observe that b[SUP]3n[/SUP] + 1 = (b[SUP]2n[/SUP] - b[SUP]n[/SUP] + 1)(b[SUP]n[/SUP] + 1), so I can use this fast DWT modulus, with one final mod(N). This is very similar to the Gaussian-Mersenne and Gaussian-Eisenstein code branches. The patch [U]is attached[/U] but I simply plugged a couple of places - Jean, because you know the intricacies of your source much better, would you please do a proper treatment of the place where I added "[C]if (0 &&...)[/C]"

IV. the results of typical unit testing are attached too (three cases).

[I]P.S. This is of course useful for N-1 proving of the new 11,8XX,XXX-decimal-digit cyclotomic monster in mere 14 hours on 24 threads, not in ~10 days on 32 threads (with default LLR, generic zero-padded FFT of huge size, e,g, 4608K). [/I][/QUOTE]
Hi Serge,

I applied your patch yesterday and tested it on your three samples. It works and seems even to be faster on Linux Ubuntu 64 bits with an FMA3 FFT!
I did not apply your "if(0 &&...) adding, but only set the default for NextFFTifNear option to FALSE instead of TRUE.
Many congrats for your work on LLR, for your last success, and Best Regards,
Jean

@Jean --
Ah, before I forgot.
This may need to be implemented (I usually now run it externally with Pari/GP); you may already have a [C]legendre()[/C] or [C]kronecker()[/C] implementation in LLR code.

This has to do with choice of 'a' value. Anand 'axn' Nair suggested a minimal quick check.
This is pseudo-code:
[CODE]while (kronecker(a,N) >= 0) { // then do not use this 'a'
// chose next 'a'
}[/CODE]
This is why I skipped values 3, 5 for the latest long-running test, and skipped immediately to 7, 11, 13 (I provided them in llr.ini).
Because there were only two p*q factors in the base b (semiprime), all three of these worked in a single pass each. This is not going to be always the case. Restarts will still be needed, especially when base has many factors (see unit test with 93500 = 2^2*5^3*11*17 )