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

[robert44444uk]

It is important to pick quite a large range of k to sieve, and sieve to a suitable depth, I suggest k=0.5*2^n. The automated script will stop on success. LLRing takes the most time

[roger]

Are the scripts referred to cLLR? Or cNewPGen? I don't see an attached file, but are the codes kar_bon posted what I'm looking for?

Thanks!

BTW: at the moment, I'm using NewPGen to sieve for 0<k<20M as 10M just doesn't seem to be enough. And yes, the LLRing is taking a lot longer than the sieving.

[kar_bon]

cllr (LLR console application) can be found here: http://jpenne.free.fr/llr3/cllr371c.zip
cnewpgen (NewPGen console version) can be found here: http://jpenne.free.fr/NewPGen/
the scripts are all you need: two WIN-batch files. that's all.
copy the 2 code-sections in the named files, put these with cllr and cnewpgen i the same folder and start the first with your range (and 2nd with some other parameters for nmax and pmax).
these few lines of code is all you need!!! simple!
and much time!!!!!

[robert44444uk]

Got a bit of a chat going with Bob Silverman and others about the mathematics, found here:

http://www.mersenneforum.org/showthr...815#post129815

[gd_barnes]

Originally Posted by robert44444uk

Got a bit of a chat going with Bob Silverman and others about the mathematics, found here:

http://www.mersenneforum.org/showthr...815#post129815

BRILLIANT ANALYSIS on the reason to search less k over a range of n instead of a fixed-n for a twin prime search!

Before getting to that post where you used the median first k for your analysis, I was about to post in there that I thought the median would be a much better measure than the mean. When I saw that you concluded it and then did the statistical analysis to MATHEMATICALLY PROVE that it makes more sense to search a much smaller range of k over a range of n instead of doing a fixed-n search, I felt vindicated because I had originally stated it in this thread (weeks after suggesting it to the leader of TPS) and it seemed clear to me in my 'ALL twin prime search' that it is a much more effective way to search for large twins. Of course my reason was different: The time saved in LLRing lower k's well more than makes up for the sieving time saved on a twin prime search on a fixed-n. So now we have TWO reasons!

On a related side note; I haven't see this mentioned in any thread about twin prime searching: It is NOT proven that there is NOT a highest twin prime. Of course it seems almost certain that there is not a highest twin, but we can't say for sure. There is a possibility, however infinitesimal it may be, that TPS is searching above the highest possible twin. It's funny to even think that might be a possibility.

BTW, I got word that PrimeGrid is going to attempt a Twin and Sophie Germain prime search for a fixed n=666666. Sounds crazy to me. What do you think of that? Now we'll get a bunch of n=666666 primes on top-5000. (yuck!) But this confused me. I thought TPS was going to do a fixed-n twin search on n=500K. Have you heard about either of these efforts?


Gary

[roger]

What are the changes in searching for these twins then?

Are we doing a range of some millions around where the twin is expected to be found, then search below if one is found to be sure?

Are we still searching by the n-value, like in NewPGen?

roger

[robert44444uk]

I think it is true to say that it is not mathematically proven, despite Gary's kind works, but I have extended comparison at 0.24*n^2 and it still holds.

I have also shown that searching around the expected value does not provide any greater chance of finding a prime, see post #53, by searching around the level of this median value.

What the median formula provides, however are some reasoned bounds around testing levels to arrive at close to 100% chance of finding a twin, this calculation provides a significant reduction over the 100G searched in the TPS 333333 search down to about 43G, using the first tenth of a percentile over a range of 1,000 n.

TPS was lucky with the 190000 search level, finding the twin in the 2G range, whereas 0.24*n^2=8.6G.

It might me worth experimenting a bit with this, but at a lower n, to make sure we are happy with the approach, after all we have all of the tools we need right now, except a distributed approach.

We could test this at say n=30000, according to the approach, we could check n from 29975 to 30025, which is 50 n, and check therefore up to the second percentile of 0.24*30000^2 -> k=4320000, we should obtain one twin.

At the same time check all of the first instance k for this range to see its median is close to the forecast of 216M. If we look at variance in a graph of median versus the formula, then the median was >200% for the formula only in four instances (3925,3939,3940,3941), and was never <50%.

I think that an interesting observation is that there has not been any really rogue n value, whereby you might find no twins, the asterisked champions are at relatively low values.

[robert44444uk]

Ugh, my last post was horribly written, it was posted between power cuts (which are very frequent here) and it was too late to edit after the power came back. Apologies for that.

Checking this particular k=29975-30025 range is interesting as we already know from Gary's work that there is no twin up to k=1M in the range. The range of k to be sieved is 800% of median, as we are also looking to actually find the first k for each n in the range. i.e from k=1M to k=1.6G.

As far as checking for twin+SG, I think 666666 is not very logical at all. To begin with checking takes time, by checking SG & twin you are eliminating some k which are either SG or twin, i.e. those which are twin but for which SG partner has no small factors and vice versa.

Much more sensible is to check not too far above the current record of n=195000, say n=200000 using the approach we are discussing. We would find a record much faster than TPS or PrimeGrid, all they will do is find top 5000 primes, which is not so exciting after the first few. No one talks about Mr X and his 25674165667*2^333333-1 find, ranked 4345th biggest prime ever (made that up), but a new twin record and you are in the books for ever.

Will probably post 4000-5000 today

[kar_bon]

to Robert:
do you use the scripts i gave? how they work? any problems?
what are the current parameters (nmax and pmax for cnewpgen) you use?
how long do the scripts run? timings?
i'll try to firgure out how i can enhance them for a k when no twin is found.
and to continue a work when canceled.
karsten

[robert44444uk]

Karsten, script works fine, I just have no computing power. I tend to vary the scripts based on where I am , but I am setting the upper k limit for cnewpgen at 10*0.24^n^2 or thereabouts. Checking lots of k adds no time, and therefore I don't have to worry about stoponsuccess not kicking in, it always does. pmax tends to be not too high..5G at n=5000.

The only problem is that I am using del commands on each n, and sometimes the del kicks in before the write to alltwins.log. But that happens only one time in a couple of hundred, so I need a small delay command, but I can't remember what that is. Long time since I used dos.

[roger]

Karsten:

I've got the scripts working now (they work great so far!), and haven't had any problems.

The parameters I'm using right now are: kmax=20,000,000; pmax=25,000,000,000 which leaves around 15,000 candidates. The sieving takes around 4.1 minutes per n-value. Each k takes between 150 and 350 ms (depending on the k-value).

The stop on success option will help lower the time it will take, as well as running two instances, but it will still take a while...

EDIT: Robert, do you mean kmax=10*0.24 * n^2?