[QUOTE=rudy235;584122]i looked for it at the prime gap tables and it was not there. Did you report it?[/QUOTE]
That's on me, the primegap github site is updated manually ~monthly. I updated it today. 1572 now appears on [URL]https://primegaplistproject.github.io/lists/primegapshighwatermarks/[/URL] 
Have the new gaps of 1552 and 1572 been confirmed as maximal prime gaps yet? How close are you to confirming them?

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.

I've checked up to 2[SUP]64[/SUP] + 61*10[SUP]16[/SUP]. 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.

I thought you started at 2[SUP]64[/SUP] and worked continuously from there. How are you not sure that these are maximal prime gaps? Did you skip any primes?

[QUOTE]
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.[/QUOTE] ATH This is the status of the exhaustive search. (Unless someone else has covered the numbers after 2[SUP]64[/SUP]+1.03 x10[SUP]16[/SUP]) To check in a reliable way that no gap greater or equal to [SIZE="5"][b]1432 [/b][/SIZE] exists below 2[SUP]64[/SUP] +2.33x10[SUP]16[/SUP]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[SUP]64[/SUP]2[SUP]32[/SUP]. As things stand now the smallest gap that we don’t know with certainty to be a “first occurrence” is 1432. 
I checked continuously from 2[SUP]64[/SUP] 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 [url]https://mersenneforum.org/showpost.php?p=583288&postcount=20[/url]) 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 67 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[SUP]32[/SUP].
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. 
[QUOTE=CraigLo;586408]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 67 times longer to run. [/QUOTE]
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.46.6 SPRP tests at 2[SUP]64[/SUP] + 2*10[SUP]16[/SUP]. Why does 12 SPRP tests prove primality? 
[QUOTE=ATH;586415]
Why does 12 SPRP tests prove primality?[/QUOTE] 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 [U]is most probably[/U] a first occurrence and thus a Maximal Gap)[list][*]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[/LIST] I am assuming none of these numbers, with the exception of 1552, have been improved since November 2019 
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[SUP]23[/SUP].
[url]https://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test[/url] For 2[SUP]65[/SUP] this can likely be reduced to 7 or better but I don't think it has been proven beyond 2[SUP]64[/SUP]. [url]https://millerrabin.appspot.com/[/url] 
There is a list of base 2 pseudoprimes up to 2[SUP]64[/SUP].
[url]http://www.janfeitsma.nl/math/psp2/index[/url] When you guys were doing the search up to 2[SUP]64[/SUP] it would have been faster to do the Lucas test only if the number was a known 2PSP. Unfortunately the list only goes up to 2[SUP]64[/SUP]. Is there a fast way to generate the list of 2PSP. When checking for gaps we need to do one Lucas test for every 1400 numbers. To check from 2[SUP]64[/SUP] to 2[SUP]64[/SUP] + 2.33 * 10[SUP]16[/SUP] (Gap=1552) would require 1.66*10[SUP]13[/SUP] Lucas tests. Can the list of 2PSP 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 2PSPs. 
All times are UTC. The time now is 07:10. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.