Prime Gap News

[Bobby Jacobs]

I hope you find the missing gaps.

[mart_r]

So now, as promised, some new large gaps, ready for a doublecheck:

1363608  90547#/9699690-366998
 900144  90583#/9699690-523646
 971716  90647#/223092870-359938
1293962  90679#/223092870-873966
1029000  90697#/510510-336914
1442154  90703#/510510-582572
1898630  90709#/9699690-1271684
1028856  90749#/510510-694658
1018282  90749#/9699690-576318
1054830  90787#/510510-630698
 948276  90803#/9699690-317680

I was placing a bet on finding a 2M+ gap, but no luck there. These "low grade" megagaps would have been easier to find with divisors 2310 or 30030.

Something I've been wanting to ask years ago: there are still a couple of gaps from Patrick DeGeest's project (largest/smallest PRPs with d digits, also called "border PRPs") that are not included in the GitHub lists. I don't know whether someone is in contact with him to ask for inclusion of those gaps, or to include them anyway from the openly accessible data (I could make a list if need be), or to let it be anyone's concern...

[SethTro]

Originally Posted by mart_r

So now, as promised, some new large gaps, ready for a doublecheck:

1363608  90547#/9699690-366998
 900144  90583#/9699690-523646
 971716  90647#/223092870-359938
1293962  90679#/223092870-873966
1029000  90697#/510510-336914
1442154  90703#/510510-582572
1898630  90709#/9699690-1271684
1028856  90749#/510510-694658
1018282  90749#/9699690-576318
1054830  90787#/510510-630698
 948276  90803#/9699690-317680

I was placing a bet on finding a 2M+ gap, but no luck there. These "low grade" megagaps would have been easier to find with divisors 2310 or 30030.

Something I've been wanting to ask years ago: there are still a couple of gaps from Patrick DeGeest's project (largest/smallest PRPs with d digits, also called "border PRPs") that are not included in the GitHub lists. I don't know whether someone is in contact with him to ask for inclusion of those gaps, or to include them anyway from the openly accessible data (I could make a list if need be), or to let it be anyone's concern...

I lightly tested these (~1 in 2000 numbers + endpoints) and they are now merged in
https://github.com/primegap-list-pro...6e77e8f82a7715

[mart_r]

Thanks!

I'll be looking for smaller gaps for the rest of the year.

[SethTro]

Megagaps proposal:

I was rereading drtrnicely-format-legacy and I believe that Dr Nicely's solution was to label the gap 'C??' for conventional, unknown is first, "but the interior integers of the gap have not been verified all composite to the satisfaction of Thomas R. Nicely".

I can easily change CloudyGo to verify the endpoints + some small percentage of the interior.

Any objections to allowing these records with less verification and C?? status?

[mart_r]

Sounds okay to me.

Is there an extra query available for all the yet not fully verified gaps?

[ATH]

When you find those megagaps do you sieve first before prp testing? If yes then please save those factors, so they can be verified easily afterwards.

[mart_r]

It's only a crummy sieve via Pari, about 20 minutes to less than 1G, without keeping factors.

But I definitely keep it in mind should I ever aim for a 10M gap.

[SethTro]

Originally Posted by mart_r

Sounds okay to me.

Is there an extra query available for all the yet not fully verified gaps?

I'm not sure what you mean by `extra query`, I'm working to accept these records via the normal flow (with some UI warning they will be recorded C??)

Originally Posted by ATH

When you find those megagaps do you sieve first before prp testing? If yes then please save those factors, so they can be verified easily afterwards.

It's easy for me to rerun the sieve on my side which is easier than accepting a giant list of offsets + small factor.

[ATH]

Well it depends on how far they were sieved. Known factors can be checked very quickly.

Sounds like the sieving is not really optimal, you should sieve until finding new factors takes longer than PRP testing the candidate.

[mart_r]

Originally Posted by SethTro

I'm not sure what you mean by `extra query`, I'm working to accept these records via the normal flow (with some UI warning they will be recorded C??)

I thought that one might want to have a quick check which gaps need verification.

Originally Posted by SethTro

It's easy for me to rerun the sieve on my side which is easier than accepting a giant list of offsets + small factor.

I was also worried about the several megabytes those lists would take up.
Giving only the list of numbers with factors larger than 1G (say) would be a reasonable compromise, I guess. Depends on the depth of the sieve.

Originally Posted by ATH

Sounds like the sieving is not really optimal, you should sieve until finding new factors takes longer than PRP testing the candidate.

Well, sieving takes about 20 minutes longer with a depth of 2G, I get 3.4% less candidates, and while every 8 hours a prime is found, that would save me 16 minutes there.
Sieving via Pari is not optimal, but since it's not really the bottleneck, I decided to leave it at that. Besides, it was not a big project like the gaps between prime twins and prime gaps in arithmetic progression...