Start a private n?

[Svenie25]

Hello folks.

Let´s say, I want to start a private search for a twin prime at n=666777. What do I have all to do?

At first, I will only use my C2D.
Now, this is what I´m thinking about, what to do.

1. Start newpgen, choose "twin", b=2, n=666777, kmin=1, kmax=1000000(?)
2. Start sieving short. Then split the file, start 2 instances of newpgen and let them sieve until both files are finished.
3. Now merge the files for later use.
4. Put the two sieved files in a folder for llr and start it
5. Wait for lots of primes
6. After finishing the tests, split the merge sievefile and start again 2.

Is this correct or any changes?
Thanks a lot!

[KEP]

Well Svenie, the base and the n values sounds great, however I may caution you that you will most likely not find a twin for k=1M, in fact once you've completed sieving or just sieved a bit, the 1-(maybe)5 primes that you would most likely have seen in your k=1M range if you just ran a regular k with fixed n search, will most likely also has been sieved away due to a low factor on the +1 side. So my suggestion is to see how much of a k-range that your memory can support and then aim for at least k=1,000,000,000,000 (or more) if you wanna be sure that you actually has a chance of finding just something But again you can be doing something else like this:

1. Find optimal sievedepth (time per test at k=1M and n=666777)
2. Tell NewPGen to stop sieving the k=2-1,000,000 range when optimal sieve time is reach per candidate
3. Tell NewPGen to start sieving a new range with n being default higher

Doing step 3 will, if you increase the n value by 1 each time optimal sieve depth is reached, mean that you eventually will find a twin k for k<=1M. Also since an increase by 1 in the n value means that you can sieve 50000 n's or so (maybe less, not quite sure) without having to be concerned about undersieving a range

Hope this made sence and maybe you should contact Gary Barnes for the k-ranges he is collecting and the tested n limits

Regards

KEP

[em99010pepe]

PrimeGrid is already doing that or it is already done.

[kar_bon]

Another hint to get an idea of how high the k-value can be,
see http://www.rieselprime.de/Related/FirstKTwin.htm:

there're all first k-values for a special twin n-value upto about n=10000 and some higher values.

[gd_barnes]

To find a twin prime at n=666677 will likely take several 100 CPU years if not 1000 CPU years or more. This huge DC project didn't find one at n=333333 in a nearly 2 year effort with probably 100s of cores running it. You'll find a few Riesel primes but even those will take quite a while on just 2 cores.

If you are running 2 cores, I would suggest going after a top-15 twin just above n=100000. I found one and it took me 6 CPU months adjusting for today's faster cores than what I ran at the time (actual was 10 CPU months on a 1.6-Ghz machine but I calculated that I was slightly lucky to find one that fast). To find a twin at even n=200000 would take slightly over 16 times longer; 4 times as long for each Riesel test, 1/2 as much chance of each Riesel being prime, 1/2 as much chance of each Sierp being prime, plus a little added time for the few larger Sierp tests that would have to be run.

Each doubling of the n-value on a twin prime search should take slightly over 16 times as long. In other words, the time that it takes should vary with the 4th power of the exponent. (It's the cube of the exponent for regular primality tests.)

Large twin prime searches are not for the faint of heart, just like huge single primality tests.

Edit: Assuming that 6 CPU months is a reasonably accurate time for finding a twin at n=100000, finding a twin at n=666677 would take:
(666677/100000)^4*6= 11853 CPU months or 988 CPU years. Therefore, if you have 10 quads running 24x7 at current computer speeds, it would still take you 25 calendar years to find a twin so large. That's why the current twin prime record is still "only" n=195000!


Gary

[gd_barnes]

Originally Posted by em99010pepe

PrimeGrid is already doing that or it is already done.

PrimeGrid is doing n=666666, not n=666777.

Originally Posted by kar_bon

Another hint to get an idea of how high the k-value can be,
see http://www.rieselprime.de/Related/FirstKTwin.htm:

there're all first k-values for a special twin n-value upto about n=10000 and some higher values.

This link does not work.

[TimSorbet]

Originally Posted by gd_barnes

This link does not work.

Nope it doesn't, but this does: http://www.rieselprime.de/Related/FirstKTwin.htm (the same URL minus the : at the end; the forum software decided to link the : as part of the URL, which made the link break.

[kar_bon]

yep, next time i put a space between!

[Svenie25]

Thanks a lot for the answers, guys.

I think, I will it do this way:

1. Start NewPGen on one core, kmin=2 kmax=1000000
2. Sieve until optimal deepe is reached.
3. Take the sievefile to llr and test it.
4. Start the next sieve kmin=1000000 kmax=2000000
5. Sieve until optimal deepe is reched.
6. Take the new file to llr when the first file is finished and test it.

And so on. I think, this is the best way. Hopefully it doesn´t take so many years.

One question is left: When I´m testing with LLR and it found that -1 is prime, does it test automatic, if +1 is prime, too?

[kar_bon]

yes, it will.

if you choose the twin search/sieve in newpgen the testfile become at first line something like

13324156225920:T:1:2:3

which means T=Twin search to base 2.

so if LLR finds a twin for the '-' side it will test the '+' side too.

the result-file looks like

467343*2^1000-1 is prime!  Time : 5.346 ms.
467343*2^1000+1 is prime!  Time: 9.844 ms.

and the prime-file like

3000000018:T:1:2:3
467343 1000

which means, you fouind a twin for n=1000 and k=467343!

BTW:
you can put the line

StopOnSuccess=1

in the llr.ini and LLR will stop testing if a twin was found!

[biwema]

I think it is not a good idea.
The Speed of NewPGen does not depend on the size of the k range.
sieving k= 3-1000001 takes about the same time as 3 - 100000001.

When sieving N=333333, we sieved a range of 100000000000 at the same time to have a probability of success of 90% (until now testing seems to be a bit unlucky)

When you just sieve for yourself, I recommend sieving a range of 1000000000. Then you can sieve much further than chunks of 1 million and so improve the overall speed (fewer candidates).

Another option is to reserve a presieved manual range of N=333333 (at around 99800 M). The chance of success is much higher there.

Good luck.

Originally Posted by Svenie25

Thanks a lot for the answers, guys.

I think, I will it do this way:

1. Start NewPGen on one core, kmin=2 kmax=1000000
2. Sieve until optimal deepe is reached.
3. Take the sievefile to llr and test it.
4. Start the next sieve kmin=1000000 kmax=2000000
5. Sieve until optimal deepe is reched.
6. Take the new file to llr when the first file is finished and test it.

And so on. I think, this is the best way. Hopefully it doesn´t take so many years.

One question is left: When I´m testing with LLR and it found that -1 is prime, does it test automatic, if +1 is prime, too?