List of most small twins of form k*2^n+/-1

[robert44444uk]

Originally Posted by MooooMoo

If you want TPS to abandon our fixed-n search after finding a prime for n=333333, you'll need to:

1.) Suggest the range of k and n that you think makes sense.
2.) Provide a program that can search the whole range of k and n at once. NewPGen won't work because either the k or the n value has to be fixed.


That was the original plan, but I'm willing to change it even after doing some sieving on n=500K.

MooooMoo I hope the work we are doing here will be persuasive, it is not our purpose to "want" you to abandon.

My choice, to be further analysed was posted on 29th March in this thread, but before this approach could be adopted, then I would want (if I was you) some comfort that this bottom slicing approach would work, and I suggested a test at the 30000 level, in the same post. If we are able to find an twin in the very narrow bounds of k suggested, it might give you confidence in the approach.

In terms of distributed effort, I don't know if there are sieves out there that can attack 1000 n at a time, over a fixed range of k. So the approach might be to sieve with a program that provides the maximum range of n, set up a series of parallel sieves, then start to prp the results.

This is still in its infancy as an approach, and our objective is to provide a sound footing for any attack on the twin prime record.

[roger]

I'm working on finding the 90th or 95th percentile of where these twins fall on the graph. That should reduce the range of k's to search somewhat, or at least be of passing interest.

Will post the results in a few hours I think

[robert44444uk]

Originally Posted by roger

I'm working on finding the 90th or 95th percentile of where these twins fall on the graph. That should reduce the range of k's to search somewhat, or at least be of passing interest.

Will post the results in a few hours I think

Roger

You may wish to look at message #12 on
http://www.mersenneforum.org/showthr...510#post130510
where I had analysed blocks of 100 by decile.

[roger]

Post #12 seems to be written by MooooMoo...

[robert44444uk]

Originally Posted by roger

Post #12 seems to be written by MooooMoo...

Sorry

Try this link

http://www.mersenneforum.org/showthread.php?t=10063

[gd_barnes]

Originally Posted by MooooMoo

If you want TPS to abandon our fixed-n search after finding a prime for n=333333, you'll need to:

1.) Suggest the range of k and n that you think makes sense.
2.) Provide a program that can search the whole range of k and n at once. NewPGen won't work because either the k or the n value has to be fixed.


That was the original plan, but I'm willing to change it even after doing some sieving on n=500K.

First, I don't suggest waiting for n=333333 to find a twin. The chances of you finding a twin are no greater now than when you started regardless of what has already been tested. Interest will wane once the last n=333333 prime has dropped off of top-5000. I've seen it already waning. Essentially the same sized prime gets boring after a while.

Suggestions:

1.) n=350K-450K

2.) k=3 to 2M (odd values only); that's a starting value of three, not three million.

3.) Sieving: NewPGen with the increment counter set on. In a distributed effort, have people reserve n-value ranges instead of P-values for sieving. Determine ahead of time what the optimum sieve depth is and have everyone sieve to the same depth; increasing moderately as you go up by n-value.

Number of possible candidates: 100K * 1M = 100G.

Number of candidates from your n=333333 search assuming a top k-value of 100G: 50G

The above is exactly what I'm doing to create the 'all twin pages' that I've done so far to n=~36K. (I've temporarily stopped the effort for about the last 5-6 weeks but have sieved up to n=50K. Will start again in ~1-2 weeks.) Sieving 1 n-value at a time is far more effective than it looks at a glance. Low k-values LLR MUCH MUCH faster. IMHO, fixed-n searches should not be done in the future unless there is an improvement to LLRing high k-values.

Despite this, if you still decide to do a fixed-n search, do EVEN AND ODD k's. That's what I did to find my 2 top-5 prime quadruplets; one which is for n=3800 and the other for n=3802. I sieved all n=3800 but one of the k's was divisible by 4 so it was reduced and n increased by 2. Once again, it's about efficiency. You may as well get twice the k-values within the same range. I can't think of a reason to limit it to odd k-values if you're doing a fixed-n search.

The above quad search wasn't very efficient because I sieved something like k=3 to 5T!! I was still ignorant. I should have taken what I'm suggesting above and sieved across 1000n up to about k=5G. 10-digit k's would have been bad enough in that search but 13-digit k's that I ended up testing in the actual search are ridiculous when LLRing.

NOW...all of this said, if you can convince people to search with no reward of top-5000 primes, I agree with what some others have suggested here: Do n=200K instead. Or to be consistent with what I suggested above, do n=200K-300K with an appropriate k-range that gives you ~90% chance of finding a twin.


Gary

[Kosmaj]

I'll be willing to help TPS at n=333,333 once the dust settles, and all reported primes drop from the Top-5000 list. Moo-moo, can you remind us how far have you sieved, I assume at least to 1000T?

[MooMoo2]

Originally Posted by gd_barnes

First, I don't suggest waiting for n=333333 to find a twin. The chances of you finding a twin are no greater now than when you started regardless of what has already been tested. Interest will wane once the last n=333333 prime has dropped off of top-5000. I've seen it already waning. Essentially the same sized prime gets boring after a while.

TPS/PG will be staying on n=333,333 as long as there are still some of those primes on the top 5000 list. I'll only consider switching to a broad n-range once all of the n=333,333 primes have dropped off the list.

But it isn't likely that we'll be moving away from n=333,333 immediately after the last n=333,333 prime has dropped off. We've sieved a huge range for that n (1-100G), and I don't want to let most of it go to waste.

Suggestions:

1.) n=350K-450K

2.) k=3 to 2M (odd values only); that's a starting value of three, not three million.

In a previous poll: http://www.mersenneforum.org/showthread.php?t=69743

most people said that they wanted to search n's between n=460K and n=520K after finding a twin for n=333333. Therefore, I'll probably pick the range n=430K-530K and a k range from 3 to 3M, to account for the higher n-range.

3.) Sieving: NewPGen with the increment counter set on. In a distributed effort, have people reserve n-value ranges instead of P-values for sieving. Determine ahead of time what the optimum sieve depth is and have everyone sieve to the same depth; increasing moderately as you go up by n-value.

Could you give us a quick guide on how to use NewPGen's increment counter? I'll see what a good sieve depth is after trying out some values.

[MooMoo2]

Originally Posted by Kosmaj

Moo-moo, can you remind us how far have you sieved, I assume at least to 1000T?

We've sieved a total of 4752T. All ranges below 4000T have been sieved, but there are some gaps between 4000T to 5500T.

[robert44444uk]

I did some calculations:

Based on 1000 ranges of n, (2001-3000, 3001-4000, 4001-5000) we find the lowest k at about 0.12% of median, with range 0.04% to 0.26%. Looking at centiles, the average of the first 10 centiles for the three ranges is 1.69% of median

If the extrapolation holds, then in the range 200000-201000, we might expect the lowest k to be around 16320000, using 0.17% as 1/10th of the centile, and the formula for the median 0.24*n^2.

It seems to me that sieving time is not going to be any more length wise than the sieving that the 333333 TPS is carrying out. In fact sieving should be quicker as NewPgen works more efficiently over reasonable range of k - too large and it get indigestion. As the correct sieving depth is defined in terms of t[1]+t[2] = t[3], where t[1] is sieving time, t[2] is the time to LLR remaining candidates, t[3] is the minimum sum of t[1] and t[2]. I think t[3] is at the minimum when the sieve elimination rate equals the LLR time for a given k. The smaller the range of k being sieved, the quicker the elimination rate will reach the LLR time.

I strongly advise a test at lower than 200000 to check if this approach is worthwhile. The test should be at greater than the range Gary is currently checking, say n range 40000-41000, testing up to k=670000, to see if this produces at least one twin. The alternative test could be at nrange=67000-68000. which would be archivable, testing to 1860000. I really advise this approach (baby steps and modest target). A candidate in the 450000 range takes that much longer to test, and the chance of a twin is only 55% of that at the 333333 level. And the chance of a twin at the 333333 level is 36% of one at the 200000 level.

Average stats for the three ranges:

Centile  % of median
0.1 0.12%
1 1.64%
2 3.10%
3 4.85%
4 6.75%
5 8.71%
6 10.30%
7 11.92%
8 14.08%
9 15.43%
10 16.98%
15 25.53%
20 34.23%
35 42.38%
30 51.95%
35 62.11%
40 73.32%
45 86.51%
50 100.00%
55 115.25%
60 135.30%
65 153.89%
70 176.71%
75 203.47%
80 237.09%
85 276.27%
90 343.21%
95 445.61%
100 1140.46%

[robert44444uk]

Graph of median over ranges of 50n vs 0.24*n^2. If median is =formula, it shows as 100%. n up to 5480. I think this is quite instructive