3 sieving questions

[Moo_the_cow]

3 sieving questions:

1.) When the tests for n<4 mil are all assigned to the users,
will a factor for 3 mil - 4mil be still beneficial (assuming it
isn't a duplicate)

2.) If the answer to question 1 is no, is it possible to have a
significant speed increase by changing the SoB.dat file to
include only candidates for 4 mil< n < 20 mil?

3.) Is anyone planning to sieve candidates for n >20 mil?

[MAD-ness]

Not that I am in a hurry for the project to end or anything, but I sure hope that we eliminate all the k values before we get to the point where n=20 million is being assigned by the server for proth testing.

Perhaps one of the guys who is more familiar with the statistics and the math involved could give you a really rough estimation of when the project might reach n=20 million across all of the k values, but I would be shocked if it wasn't a matter of years, at the least. Long enough that moores law becomes a real factor, not to mention other long term issues.

[OberonBob]

I am no expert, but here is the info as far as I can tell.

1. no

2. yes, in fact, I expect to continue to see updates to the SoB.dat file as more factors are found, and proth tests completed. just not very often.

3. yes, when the time comes, but it going to be a while.

hope that helps.

--
OberonBob
Team ORU

[smh]

I'm not an expert either but i think the answers are a bit different.

1) Yes, the best proof of a number being composite is to have a factor. Checking if a number devides the original candidate is a matter of seconds. Running a second proth test to make sure the first one produced a correct result (matching residues) takes hours or even days. OTOH, if we don't plan to double check every little speed up in sieving helps of course.

2) It does speed up the search a little, but not by a large amount. To sieve a range which is 4 times as large, only takes twice the amount of time. Thats the reason why we sieve a rather large range. In the end it's much faster than sieve every 1M block seperately

3) By the time we get around 18 or 19M we should start thinking about it. Candidates with a large N take much longer to test, so sieving needs to be done much deeper. But it doesn't really make sence to already start sieving higher ranges now. It will take years before we reach there, and we expect to remove a few K's before that time, so those K's won't have to be sieved. Removing 1 K will speed up the sieving more then removing 1M from the sieve file.

I've got one other question:

Can the SoB client double check it's own results? I mean, will it shift data like the GIMPS client does?