At #1. Yes RieselSieve did remove the primed k from the sieve file, when they felt like they had the time to do so. However what is a bit more critical is the fact that RS did not remove any k/n pairs from the sieve file with a n<2,947,000 (which were the sure doublecheck maximum), also I don't think that several 1000T of p's and the factors that they produced has been removed either. Because we have to remember that at some point RS sieved well above 100T each day and then produced more than 1000 (most often around 2500) factors a day.

At #2. Well it might give some flaming and frustration among the hardcore supporters of RS, however there are fewer active users, supporting RS than there is active users on CRUS.

Regarding #2, I would strongly suggest that we in stead of setting up our own server, actually made a deal with Rytis if someone can convince him that the k's does no longer belong to RS, and gets the help of the PG users. Many users would actually like the fact that a WU only takes ~6-7 hours. Plus we would see that the first pass n-value aswell the second pass value will remain the same, since there is instant doublechecking, and then as we nears the n=20M we will for certain know which k's remain and then be able to start a new sieve, without having to worry about having missed a k. It's just my suggestion, but I really don't think that it should be ruled out as a possibility, since everyone here can agree that only 3 k's at most can be declared as being assigned to the RS project at the current state :smile:

Regards

Kenneth

[QUOTE]Regarding #2, I would strongly suggest that we in stead of setting up our own server, actually made a deal with Rytis if someone can convince him that the k's does no longer belong to RS, and gets the help of the PG users. Many users would actually like the fact that a WU only takes ~6-7 hours. Plus we would see that the first pass n-value aswell the second pass value will remain the same, since there is instant doublechecking, and then as we nears the n=20M we will for certain know which k's remain and then be able to start a new sieve, without having to worry about having missed a k. It's just my suggestion, but I really don't think that it should be ruled out as a possibility, since everyone here can agree that only 3 k's at most can be declared as being assigned to the RS project at the current state :smile:
[/QUOTE]

Personally I would stay away from Boinc (and PG). Most Boincers overclock their machines (obviously). The chances of them missing a prime were/are pretty high. If it were me, I'd start any new LLR effort as low a possible on the n scale. I'd also leave the k's that a prime are found for in the candidates file. That would fulfill the NPLB philosophy and also the CRUS philosophy. Why not do both?

Just my thoughts.

I would think one would be concerned about the integrity of the file. If you do not know the condition/contents of the file, both tested and untested, it's pretty hard to use that item for justification for or against any conjecture is it not?

[quote=Brucifer;170132]I would think one would be concerned about the integrity of the file. If you do not know the condition/contents of the file, both tested and untested, it's pretty hard to use that item for justification for or against any conjecture is it not?[/quote]
Well, at the very least, the most recent publicly released copy of the sieve file should be fully intact and trustworthy. The only thing that's somewhat up in the air is exactly where RieselSieve stopped testing (and it varies from k to k, to boot).

Just a thought. We can re-create the original input file before any sieving was done. Was there ever any published listing of found factors? Any chance Bryan or Lee would send us just the found factors?

@MyDogBuster:

First of all, good luck on getting Bryan or Lee to send you anything. The only reason I ever got the sieve file was because an other member just as eager to get the project started again, was willing to mail it to me.

Secondly, using BOINC is not that dangerous, since there is (if we choose to have it) when we use PG automatical doublechecks, that way the faulty computers will not cause us to miss any prime up to n=20M, so I think it would be a fair way to speed up the progress. Also, I'm just for fun and testing beginning to sieve all 64 k's remaining from n 20M-250M, since any larger ranges caused a malloc error :smile:

If I choose to continue sieving this high-n range, I will of course remove any eventually primed k aswell keep sieving untill a public sieve is nescessary :smile:

Regards

Kenneth

Guys, I'm confident that the file is very good. It has all of the k's that are needed, starts from n=~100 and goes to n=20M. KEP converted it to "regular" ABCD format before sending it to me.

As for BOINC, this is the ideal situation to utilize it. The tests are extremely long compared to what most of us are used to here. For a test at n=4M, it is likely to take 8-10 hours. How many of you want to complete 2-3 tests per day with each test likely having a 1 in 40000-60000 chance of being prime? Compare that to what we are used to at NPLB: 10-15 min tests with a 1 in 5000-7000 chance of prime.

Let me put it to you this way: A prime at n=4M will take 512 times as long to find as a prime at n=500K assuming same sieve depth. Since the RS file is obviously sieved far further, it's probably more like 450-500 times as long. (lol) Calculation: The tests will take 64 times as long and the chance of prime is 1/8th as much. 64*8=512. I used n=4M because the calculations are easier. As KEP has previously suggested, we'd likely start at n=3M so maybe the primes would only take 200 times as long to find with tests taking "only" 6-7 hours. (wee!) Regardless, this effort is not for the faint of heart!

That said, I don't think we'd be able to talk Rytis into taking over the effort at PrimeGrid but I'm all in favor of giving it a shot. But someone else has to follow up with him.

As for starting it under the "CRUS" umbrella, I'm fine with that. Here is what we need:
1. A hardy LLRnet server.
2. A good stats page like we have at NPLB.
3. A good P.R. guy to handle any political fall out.
4. A lot of crunchers who don't mind extremely long tests.


Gary

I have sent the Riesel base 2 sieve file to Ian, Bruce, and Max by Email.

Edit: Oops, for those of you read my last post before I edited it, I removed the part about not needing to sieve the file. I reread KEP's post and realized that he is talking about sieving n=20M-250M. KEP, you of course realize that it will probably take the better part of most of our lives just to test the current file up to n=20M? Sieving n=20M-250M now is a huge waste of CPU time. Consider waiting until about 10-15 years from now when computers are likely to be a "little bit" faster than now. lol You really need to think a little bit before starting on these monsterous tasks.

It appears according to the sieve stats at dc.rieselsieve.com, that the last returned range from BOINC was at p=5850000000000000 with a gap from p=5850000000000000 to p=7100020000000000. That alone, that there is gaps in the sieve range, aswell as the disorganized way and the irresponsible way that RS has handeled things since their mysterious "disappering", should be more than enough to convince a stable project like PG to join us and support our claim to take over all these k's remaining. Also I suggest that since Max is the one who has been pointed out as able to handle the political fallouts, that he actually also creates a joint notification that those of us who wants to can sign, and that one can then be handeled to Rytis to show that it is not just the project manager or some of his "ridicure" followers who is concerned about the way things is dealt with at RS :smile:

Regards

KEP

@ Garys last post: Good job, hope they can use it :smile:

Also does anyone happen to know what optimal sievedepth for k*2^250000000-1 is? My guess is that it is well more than 100,000 T p's, but does anyone has any ideas?

Kenneth,

No one knows and I doubt anyone cares what the optimum sieve depth is for n=250M. Like I said in the last post, it is a complete waste of today's resources. We won't reach n=20M for as many as 20 years or more, even allowing for extreme computer speed and participation increases on Riesel base 2. It's possible we may not reach it in most of our lives. Please trust me on this, you are completely wasting your time. It would be like looking for a prime on k=1 for Sierp base 252 that you tried for a while. Since it's a GFN, you're unlikely to find one in your lifetime.

Also take a look at SOB. They are at n=14M and they only have 6 k's remaining vs. 64 k's for Riesel base 2. SOB is a very well run project like GIMPS. To match their coordination and resources will be a large undertaking, likely requiring what PrimeGrid could bring to the effort.

Why don't you focus on base 63 and your many other bases < 1024? Base 63 alone will take several CPU years to get to n=25K.

Max informed me that he thought RS had sieved the file fully to P=20P (i.e. 20,000T) but I think you are saying that they only fully sieved to P=5.85P. I would think it would be much higher than that.

If you want to try sieving for a while, a much better use of your CPU time would be to test and see if there are any factors in the Riesel base 2 file from P=5.85P-6P; i.e. a 150T range. If you find none by P=5.9P, then likely it has been sieved higher. Try experimenting with that at different depths and make sure you attempt a sufficient range before concluding there are no factors at that depth. (The estimated # of factors as given by sr2sieve should probably be 5 or higher; 10 would be even better.)


Gary

@ gary: I do still focus on the Sierp base 63, however I tried for fun to sieve to 1 G on the remaining 64 k's for the range n=20M-250M, it took about 3 hours and left ~78Million candidates. However I decided to stop, since I find it much more usefull to see if their actually comes a BOINC interface focusing on the Riesel base 2 conjecture, also I thought that I would be best to wait for all 66 remaining k's to be tested to n=20M, or close to, before starting sieving another range, even though it has to take quite a lot of sieving before it is even remotely sieved to the least efficient point.

Regarding the sieve depth, I doubt that they actually reached 20P, however my conclusion were based on the last completed BOINC sieve range, found in the sieve statistics. It stated that the upper p=5.85P, but I might follow your suggestion and do some testing at various sieve depths. I'm thinking 10G's sieve ranges at least or maybe more :) Also I has 1 concern about determining the sieve depth in this manner, mostly because none of us is aware at what sieve point the RS folks removed found factors at last. So according to sieve file, it might be even lower the sieve depth than 5.85P.

Regards

KEP