Operation Megabit Twin

[Dougal]

much of a speed increase with the new sieve file?

[The Carnivore]

Originally Posted by Oddball

how long does it take to LLR a candidate

At k=120T, I'm getting a time of 1.92 ms/iteration on one core of a 2.4GHz Core 2 Duo machine. The whole test would take 1920 seconds (32 minutes).

[amphoria]

Originally Posted by Dougal

much of a speed increase with the new sieve file?

I haven't yet started using the new sieve file myself. I intend to swap over once I have completed my current reservation. However, my current sieve file does have all factors removed apart from p=140-240T. My gut feeling is that increasing p has a greater effect than removing factors. At p=540T I am sieving ~3.5T per day on a single 2.4 GHz Core 2 core.

[Blackwood]

I am getting a factor removed every 3 secs so still a long way to go.

At p=540T I am sieving ~3.5T per day on a single 2.4 GHz Core 2 core.

Originally Posted by The Carnivore

At k=120T, I'm getting a time of 1.92 ms/iteration on one core of a 2.4GHz Core 2 Duo machine. The whole test would take 1920 seconds (32 minutes).

This would seem to indicate an optimal sieve depth of >100P.

Also, this may not be the right place to ask, but does anyone know why Primegrid picked such a low sieve depth for their n=666666 SGS search? According to this thread:
http://www.primegrid.com/forum_thread.php?id=1450
it looks like they've only sieved those candidates to p=200T.

[Dougal]

350-500T

reserving 550-750T

[axn]

Originally Posted by Blackwood

Also, this may not be the right place to ask, but does anyone know why Primegrid picked such a low sieve depth for their n=666666 SGS search? According to this thread:
http://www.primegrid.com/forum_thread.php?id=1450
it looks like they've only sieved those candidates to p=200T.

Hmmm.. Interesting. If that is accurate, they're probably off by a factor of 20 or so from the optimal sieve depth. But that'll probably only cost about 5-7% of additional search effort. [Keep in mind that when you do a combined sieving, as you sieve deeper, the number of pairs that you're likely to find _drops_ thus reducing your chance of success].

[Oddball]

Originally Posted by Blackwood

This would seem to indicate an optimal sieve depth of >100P.

Also, this may not be the right place to ask, but does anyone know why Primegrid picked such a low sieve depth for their n=666666 SGS search? According to this thread:
http://www.primegrid.com/forum_thread.php?id=1450
it looks like they've only sieved those candidates to p=200T.

I'm guessing it's because their objectives are different. TPS looks for twins with sophies as a secondary goal, while Primegrid's SGS looks for sophies with twins as a secondary goal. The TPS method has a higher chance of finding single primes and twins, the Primegrid method has a higher chance of finding sophies, and the TPS method has a slightly higher chance of finding a significant pair (twin or sophie). Here's a comparison for n=1000000:

Sieve to p=100G for sophies and up to p=100P for twins (TPS's Operation Megabit Twin):
Odds that a random k/n pair will be prime: 1 in 9950
Odds that a random k/n pair will yield a twin: 1 in 99 million
Odds that a random k/n pair will yield a sophie: 1 in 76.5 million
Odds that a random k/n pair will yield a twin or sophie: 1 in 43 million

Sieve to p=200T for twins and sophies (Primegrid)
Odds that a random k/n pair will be prime: 1 in 11830
Odds that a random k/n pair will yield a twin: 1 in 140 million
Odds that a random k/n pair will yield a sophie: 1 in 70 million
Odds that a random k/n pair will yield a twin or sophie: 1 in 47 million

[amphoria]

500-550T complete (factors available at the archive).

Taking 750-800T.

[amphoria]

I came to the conclusion yesterday that the script I was using to remove the factors had a flaw. gribozavr kindly sent me his scripts and I have reprocessed all factor files from p=45T. The only damage I found was that 95,319 k's were mistakenly removed from the p=350T sieve file that I uploaded recently. Earlier sieve files that I uploaded are not affected. I have uploaded a new sieve file @ p=550T to the archive. If you have downloaded the earlier file please download this one. I have already contacted Dougal and intend to sieve the 95,319 missing k's for the affected ranges to ensure that we did not miss any factors.

Dave

[firejuggler]

trying my hand at 800-801T

[Dougal]

Originally Posted by amphoria

I came to the conclusion yesterday that the script I was using to remove the factors had a flaw. gribozavr kindly sent me his scripts and I have reprocessed all factor files from p=45T. The only damage I found was that 95,319 k's were mistakenly removed from the p=350T sieve file that I uploaded recently. Earlier sieve files that I uploaded are not affected. I have uploaded a new sieve file @ p=550T to the archive. If you have downloaded the earlier file please download this one. I have already contacted Dougal and intend to sieve the 95,319 missing k's for the affected ranges to ensure that we did not miss any factors.

Dave

i am actually still using the file from 140T,so i should be safe enough?