Smallest prime of the form a^2^m + b^2^m, m>=14

[Batalov]

Perhaps, so. I was concerned that there may be some giant_mod bug or a carry count bug similar to one a few years ago.

Anyway, found one ... at a(15) = 220221 (!!)

[Dr Sardonicus]

Originally Posted by Batalov

Perhaps, so. I was concerned that there may be some giant_mod bug or a carry count bug similar to one a few years ago.

Anyway, found one ... at a(15) = 220221 (!!)

Congratulations!

How many candidates for a(15) were sieved out?

BTW, it's another "interesting anomaly" that

a(4) = a(3)^2 and a(14) = a(13)^2.

[axn]

Originally Posted by Batalov

Perhaps, so. I was concerned that there may be some giant_mod bug or a carry count bug similar to one a few years ago.

Anyway, found one ... at a(15) = 220221 (!!)

Hmmm... Unfortunately, we can't really rule out s/w issues with regular double check. BTW, does LLR, P95 & PFGW produce comparable residues on these type of numbers?. Perhaps a Gerbicz Error Check implementation for non base-2 PRP could be made. It will be much slower (50%?) but atleast could be used to spot check.

[Batalov]

Here is my eval of what usually happens in all three tools.
This is a special form. In LLR there is an input ABC template ABC ($a*$b^$c$d)/$e; in P95, PRP=1,b,n,1,"2", and PFGW understands the ABC form as well as recognizes the special form at parse stage.

All three tools have adapted over time to do the following on it:

• the main exponentiation loop is done over mod (b^n+1) (not general mod! therefore, fast!)
• the last residue is folded mod (b^n+1)/e and compared to 1 (this is done using giants)

I am tempted to modify the source for this special case e=2, because giant mod is not needed, just compare two values (1 or (b^n+1)/2+1 -these should look just fine in limbs of b how they are likely internally stored) -- (or multiply by 2 and compare to 2). ...Thus avoiding giants.

Another test that I did in limited range: use -a1, -a2 in pfgw (or similar in other tools); this is not a little bit, but a lot slower, because the special arrangement of exactly 32K b-limbs is destroyed.

Let's see what happens. I'll tinker with this on the weekends.

[JeppeSN]

Originally Posted by JeppeSN

To appear as A301738 (until it is approved, see History to see the proposed versions). /JeppeSN

Now approved.

I will contribute the new sequence quite soon.

Serge Batalov, good work on A275530.

/JeppeSN

[Batalov]

Originally Posted by Batalov

Perhaps, so. I was concerned that there may be some giant_mod bug or a carry count bug similar to one a few years ago.

Anyway, found one ... at a(15) = 220221 (!!)

Found a(16), too

[axn]

Originally Posted by Batalov

Found a(16), too

How are you sieving these suckers?

[Batalov]

These are too small to sieve, -- PFGW's ~45-bit pre-factoring looks fine to me.
It would be a different story for m=17, but I am taking a break for now.

[Dr Sardonicus]

Originally Posted by Dr Sardonicus

Congratulations!
BTW, it's another "interesting anomaly" that

a(4) = a(3)^2 and a(14) = a(13)^2.

!sdrawkcab ti tog I ,tibbangaD

I should have said, a(13) = a(14)^2 and a(3) = a(4)^2

[Batalov]

And A275530(17) is now found!

(11559^131072+1)/2 is a 532535-digit PRP.

Now it is time to revisit the a(15) with a different FFT size throughout.

[paulunderwood]

Originally Posted by Batalov

And A275530(17) is now found!

(11559^131072+1)/2 is a 532535-digit PRP.

Now it is time to revisit the a(15) with a different FFT size throughout.

Congrats Serge. Here is my Lucas test of it:

time ./pfgw64 -k -f0 -od -q"(11559^131072+1)/2" | ../../coding/gwnum/lucasPRP - 1 11559 131072 1
                             
Lucas testing on x^2 - 4*x + 1 ...
Is Lucas PRP!

real	20m21.514s
user	48m14.480s
sys	3m17.668s