New Maximal Gaps

[SethTro]

Originally Posted by rudy235

i looked for it at the prime gap tables and it was not there. Did you report it?

That's on me, the primegap github site is updated manually ~monthly. I updated it today. 1572 now appears on https://primegap-list-project.github...gh-watermarks/

[Bobby Jacobs]

Have the new gaps of 1552 and 1572 been confirmed as maximal prime gaps yet? How close are you to confirming them?

[CraigLo]

I don't think anyone is working on confirming them. My code can't be used for confirmation. I don't have much CPU resources to contribute and I'm not sure what code others have used. I might be able to help speed up some of the existing CPU code.

[CraigLo]

I've checked up to 2⁶⁴ + 61*10¹⁶. In addition to the 1552 and 1572 I found 7 gaps in the 1400s but the largest is still 1430 so no new first occurrences.

[Bobby Jacobs]

I thought you started at 2⁶⁴ and worked continuously from there. How are you not sure that these are maximal prime gaps? Did you skip any primes?

[rudy235]

I reached 264 + 1.05*1016 = 18,457,244,073,709,551,616 but I have not worked on it recently. The gap is at 264 + 2.33*1016 so I'm not even half way.

ATH


This is the status of the exhaustive search. (Unless someone else has covered the numbers after 2⁶⁴+1.03 x10¹⁶)

To check in a reliable way that no gap greater or equal to 1432 exists below 2⁶⁴ +2.33x10¹⁶where the gap of 1552 is found is a gruesome task as we no longer have the support of the code that allowed us to reach 2⁶⁴-2³².

As things stand now the smallest gap that we don’t know with certainty to be a “first occurrence” is 1432.

[CraigLo]

I checked continuously from 2⁶⁴ but I'm only doing 1 Fermat test so it is possible that a number is incorrectly called a prime. I think it is unlikely that this has lead to missing a large gap (very unlikely if the math in this post is correct https://mersenneforum.org/showpost.p...8&postcount=20) but it is still possible. The easiest way for me to fix this issue would be to use 12 SPRP tests which is sufficient to prove primality. Half the remaining numbers are prime after sieving so the code would take about 6-7 times longer to run. It's possible it would be faster to check with sieving only. It would require sieving up to primes a little above 2³².

This is also new GPU code so it is possible that there is some other error. I did find all the gaps above 1000 that ATH found so there is some confidence that it is working correctly.

[ATH]

Originally Posted by CraigLo

The easiest way for me to fix this issue would be to use 12 SPRP tests which is sufficient to prove primality. Half the remaining numbers are prime after sieving so the code would take about 6-7 times longer to run.

It would be faster with 1 SPRP + 1 Lucas than 12 SPRP. At least the CPU code with the GMP library 1 Lucas test is about equal to 6.4-6.6 SPRP tests at 2⁶⁴ + 2*10¹⁶.
Why does 12 SPRP tests prove primality?

[rudy235]

Originally Posted by ATH

Why does 12 SPRP tests prove primality?

I was wondering exactly the same thing. On the other hand, a number of the order of 10^19 can be proven prime easily by trial division or sieving.

Keeking track of the Numbers that STILL have not yet been established as a First Occurrence Gap. (The last one 1552 is most probably a first occurrence and thus a Maximal Gap)

• 1432
• 1444
• 1458
• 1472
• 1474
• 1478
• 1480
• 1484
• 1492
• 1496
• 1498
• 1500
• 1504
• 1508
• 1512
• 1514
• 1516
• 1518
• 1520
• 1522
• 1524
• 1528
• 1532
• 1534
• 1536
• 1538
• 1540
• 1542
• 1544
• 1546
• 1548
• 1552

I am assuming none of these numbers, with the exception of 1552, have been improved since November 2019

[CraigLo]

Bases of 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, and 37 have been proven a deterministic test up to 3.18 * 10²³.
https://en.wikipedia.org/wiki/Miller...primality_test

For 2⁶⁵ this can likely be reduced to 7 or better but I don't think it has been proven beyond 2⁶⁴.
https://miller-rabin.appspot.com/

[CraigLo]

There is a list of base 2 pseudoprimes up to 2⁶⁴.
http://www.janfeitsma.nl/math/psp2/index

When you guys were doing the search up to 2⁶⁴ it would have been faster to do the Lucas test only if the number was a known 2-PSP.

Unfortunately the list only goes up to 2⁶⁴. Is there a fast way to generate the list of 2-PSP. When checking for gaps we need to do one Lucas test for every 1400 numbers. To check from 2⁶⁴ to 2⁶⁴ + 2.33 * 10¹⁶ (Gap=1552) would require 1.66*10¹³ Lucas tests. Can the list of 2-PSP be computed faster than this? We wouldn't even need to rerun what has already been done. We could just check for large gaps around the 2-PSPs.