Archived sieve reservations and discussions

[Oddball]

4750G-5400G complete, about 228000 factors found.

Part 1 (n=485000-486700): http://www.sendspace.com/file/pfy0ts

Part 2 (n=486700-488400): http://www.sendspace.com/file/w0ojzv

Part 3 (n=488400-490000): http://www.sendspace.com/file/xv7v1p

Reserving 5800-6400G.

[gribozavr]

Oddball: I've downloaded and verified your file.

Also taking 120T-140T just to keep cores busy. My previous range should be finished in a few hours.

[mdettweiler]

Originally Posted by gribozavr

Oddball: I've downloaded and verified your file.

Also taking 120T-140T just to keep cores busy. My previous range should be finished in a few hours.

Could you possibly check the removal rate somewhere within the 120T-140T range? From what I could tell by a very rough estimate in my ranges near 30T, we're not that far from optimal depth for k<100K in the n=480K-485K range and I wouldn't be surprised if 140T is sufficient to start LLRing in earnest.

[gribozavr]

Finished 66T-90T.

At p=120T removal rate is around 1 k/sec.

[axn]

Originally Posted by mdettweiler

Could you possibly check the removal rate somewhere within the 120T-140T range? From what I could tell by a very rough estimate in my ranges near 30T, we're not that far from optimal depth for k<100K in the n=480K-485K range and I wouldn't be surprised if 140T is sufficient to start LLRing in earnest.

previous estimates suggested an optimal depth of 3P, so there's some way to go yet.

edit:- also, removing k's from sieve file (for llring) gives zero speedup of sieving. you're gonna wanna remove n at a time for llr.

[mdettweiler]

Originally Posted by axn

previous estimates suggested an optimal depth of 3P, so there's some way to go yet.

edit:- also, removing k's from sieve file (for llring) gives zero speedup of sieving. you're gonna wanna remove n at a time for llr.

Ah, I forgot about the 3P estimate. However, since we're only dealing with optimal depth for the k<100K portion of the file, i.e. 1% of it, our optimal depth would be 3P*.01=.03P=30T. Given the actual observed removal rates that would seem to be rather low, so my guess is that the original 3P estimate was therefore slightly lowballed.

I see that over in the LLR reservation thread for this range the testing is being arranged by n, so that would be in line with the optimal procedure. Well, at least for k<100K; once we're done with that and ready to sieve the remainder further I suppose removing the lower portion wouldn't help much as far as sieving speed goes. Given that, it would be a bit more optimal to continue sieving all the way to optimal for the k<10M; however, that would hold up LLRing for quite a while, so the tradeoff will need to be weighed accordingly.

[axn]

Originally Posted by mdettweiler

Ah, I forgot about the 3P estimate. However, since we're only dealing with optimal depth for the k<100K portion of the file, i.e. 1% of it, our optimal depth would be 3P*.01=.03P=30T. Given the actual observed removal rates that would seem to be rather low, so my guess is that the original 3P estimate was therefore slightly lowballed.

Not really. That's what I am trying to point out. Breaking off a chunk of k (across all n's) will not help with the sieving. Breaking of a chunk of n's (across all k's) will. So there is no point in treating k < 100K as a special case.
I understand that people think that k < 100K can be tested faster with LLR so somehow their optimal sieve depth should be lower, but that is not true. When the whole range is sieved to the collective optimal depth, you'd have sieved k < 100K for free. So breaking off chunks before reaching 3P is _never_ a good idea here.

Originally Posted by mdettweiler

however, that would hold up LLRing for quite a while, so the tradeoff will need to be weighed accordingly.

If focus is on starting LLR soon, the "correct" procedure would be to concentrate the sieving for fewer n's -- say the first 1000, and get that to optimal sieve depth (still should be around 3P -- sieve doesn't lose much efficiency from sieving 1000n instead of 5000n).

[Historian]

Reserving 6400-6550G.

Calculating the optimal sieve depth is quite tricky - TPS is looking for only one twin in a range, not all of the twins in a range. For example, if a twin is found at n=482391, all of the sieving done for n>482391 is useless, since those candidates will not be tested.

[mdettweiler]

Originally Posted by axn

Not really. That's what I am trying to point out. Breaking off a chunk of k (across all n's) will not help with the sieving. Breaking of a chunk of n's (across all k's) will. So there is no point in treating k < 100K as a special case.
I understand that people think that k < 100K can be tested faster with LLR so somehow their optimal sieve depth should be lower, but that is not true. When the whole range is sieved to the collective optimal depth, you'd have sieved k < 100K for free. So breaking off chunks before reaching 3P is _never_ a good idea here.



If focus is on starting LLR soon, the "correct" procedure would be to concentrate the sieving for fewer n's -- say the first 1000, and get that to optimal sieve depth (still should be around 3P -- sieve doesn't lose much efficiency from sieving 1000n instead of 5000n).

Ah, okay, I see what you mean. I'm still thinking in terms of a sieve where the primary variation is in n (a la NPLB, RPS, etc.) rather than in k as it is here.

In that case, then, I would suggest that we concentrate all our sieving resources on the n=480K-485K portion. Right now it's just me and gribozavr on that range, with everybody else focusing on 485K-490K; since the goal seems to be to able to start LLRing as soon as possible, I'd think the former range would be the place to be.

[Oddball]

The reservations and stats have been updated.

Gribozavr, could you tell us the number of candidates in both ranges and the number of factors found since the sieve file was posted? I'm just wondering how many of them are duplicates (two factors for the same candidate).

[axn]

Originally Posted by Historian

Calculating the optimal sieve depth is quite tricky - TPS is looking for only one twin in a range, not all of the twins in a range. For example, if a twin is found at n=482391, all of the sieving done for n>482391 is useless, since those candidates will not be tested.

I do not see it that way at all. This would be a true statement when the focus is on a single n (390000 or bust, for example ). But when you're doing a range of n, you need not stop when you find a twin. You can just keep going to ever higher n's -- and that would basically mean, just keep on testing.