Prime Gap Theory

[robert44444uk]

Originally Posted by mart_r

So here's my best solution after 15 hours on 2 cores:
In a range of [n+0; n+60060] there are 2950 numbers coprime to 1777# for n =.....

The statistics:

         remaining #s  effective merit
average:         4491  34.75
my first sieve:  3126  24.19
my new sieve:    2950  22.82  <---
1777#/210-30030: 2815  21.78

Which is better than I expected.

I've not yet run out of ideas, just need some more time. Maybe I can get even better results.

Gloom! My new algorithm could only produce a 3079/60060 at 1777#. 11 hours on 1 core, although I could get this down to 3 hours I reckon with a bit more sensible programming. 2950 looks a long way off.

[robert44444uk]

Originally Posted by robert44444uk

I have developed a new algorithm which got me to 1763 remaining for the 30030 range after only 1 hour of processing on one core.

My second go using the algorithm produced 1735, quite good compared to mart_r's best of 1725. Total time invested? 2 hours to date on one core.

[robert44444uk]

Hah...a couple of 1720's overnight, a small improvement on mart_r's best

[robert44444uk]

After a day of processing, I have managed to get to 1703, also a 1716 for 907# covering 30030, in addition to the two at 1720

Still seems a long way off 907#/210-15015 to +15015, which apparently only has 1633 uncovered.

[robert44444uk]

Two days of processing on 4 cores and the best I have managed is 1699, so 26 better than mart_r's best.

[robert44444uk]

I revamped my experimental algorithm to get to results faster and after 16 hours on 4 cores I managed a 1693, so again an improvement, but still miles off 1633.

[robert44444uk]

Originally Posted by robert44444uk

Gloom! My new algorithm could only produce a 3079/60060 at 1777#. 11 hours on 1 core, although I could get this down to 3 hours I reckon with a bit more sensible programming. 2950 looks a long way off.

I started looking at this again, after reducing my programme run time. I managed a 2920 overnight for 1777/60060, so 2950 was not quite such a long way off!

I have been running my 907/30030 now for a week, and I'm making small improvements - best is now 1685.

[danaj]

Luis Rodriguez writes "The merit with Log p as reference have null interest. The true merit is: gap / (Log p)^2." Nicely calls this the Cramér-Shanks-Granville ratio.

Thoughts on "null interest"? This certainly implies the largest gaps are useless, since they have extremely small values. Basically no gap currently found over 3000 has an interesting value (all below 0.32), and over 1500 only g=1530 and g=1550 (from Nyman 2014) stand out.

By this measure, searching for true maximal gaps or at least concentrating in the 18-25 digit range would be the only worthwhile activity. For a CSG of 0.9 a gap with 100 digit start would need a merit of 207. That seems exceedingly unlikely to find, given the history.

[CRGreathouse]

The nice thing about merit is that it's unbounded: by working with progressively larger numbers (which are harder) you can eventually get higher merit. The same is not believed to be true for the Cramér-Shanks-Granville ratio (or at least I know of no mathematician who believes this is unbounded).

Certainly I'd love to see a big CSG number but I don't think it's likely to happen -- too many numbers to check.

[Antonio]

Originally Posted by danaj

Luis Rodriguez writes "The merit with Log p as reference have null interest. The true merit is: gap / (Log p)^2." Nicely calls this the Cramér-Shanks-Granville ratio.

Thoughts on "null interest"?

As I see it, the Log(p) merit is a useful and compact first approximation for establishing the earliest occurrence of a prime gap.
This is the aim of Dr. Nicely's prime gap list is it not?
As such I do not see how it can be 'of null interest', it is much more useful than the (Log p)^2 measure for this purpose.
What is the (Log p)^2 merit useful for?

I suppose that, since the merit we are using is only an approximation, we should enumerate and compare p values when equal gaps of equal merit are found, in order to establish the actual first occurrence, rather than just ignoring them as we do at present. However, I assume that Dr. Nicely is only interested in gross improvements to his list until a first occurrence can be established.

[henryzz]

It would be nice to have an alternative merit function that includes an approximation of how hard it is to find. A 10 merit is much quicker to find for small numbers than very large ones even though there are more large ones.

One question that has been bugging me for a bit is why do we usually divide by a small primorial? When you get to larger numbers the size of the large primorial isn't an issue. Does it affect the distribution of gaps? One thing I noticed with large primorials is that the largest gaps after sieving are a little away from the central point.
What is the best way to chose which primorial to divide by?