Bases 6-32 reservations/statuses/primes

[gd_barnes]

This time I have to agree with everything you said. Actually, it has been discussed previously in a thread here but I can't remember where. That is breaking CRUS down into something like:

Bases with 1-3 k's remaining

Bases with 4-10 k's remaining

Bases with > 10 k's remaining


I admit that most of my time has been spent managing NPLB for the last year or so but I'll be glad to help someone coordinate getting it done. Much follow up would be needed by people with reservations and then coordination of many different sieving efforts.

As you have alluded to, we have those main things that you are talking about that make CRUS interesting but we DON'T have are coordinated efforts for the bases with few k's where 1-2 huge primes would prove the base. There are many that are being activity searched but they are being done by individuals not as a team but in most cases, the individuals have done excellent jobs with them. To point one out specifically that is being done by one person but it in a coordinated fashion: Cruelty has sieved and is currently testing both Riesel and Sierp base 10 together. He had reserved one side and I suggested that he also do the other side because they could be sieved together and they were near the same search depth at the time. He jumped at the chance and has done an excellent job with both sides; taking them up from n=200K to 260K in just a few months...a lot of testing for 4 total k's at such a huge n-range. Many people were not aware that sr(x)sieve can sieve both sides of the same base at the same time. I did not know this myself until ~4-5 months ago. Other bases that individuals have done excellent jobs with over a long period of time are bases 9, 17, and 18; all of which have had monster ranges searched on them over more than a year. In that year, Rogue also found the base 11 prime at n=~300K that proved the conjecture as well as searched the final k of Sierp base 27 to n=400K; both of which were truly gargantuan efforts!

Currently our team efforts are concentrated on the bases with many k's remaining because those can be the most difficult to administer and balance k's remaining for individuals.


Gary

[gd_barnes]

Riesel base 22 is at n=183K; continuing on to n=200K. Nothing more to report.

[mdettweiler]

Sierpinski base 23 is complete to n=250K, no primes. Results attached for 200K-250K. Releasing this base.

Note: I'm guessing that it doesn't need any more sieving for quite a ways yet. A while back I let sr1sieve take a whack at it for about 5 or 6 hours, and it didn't find any factors at all. That translates to about 4 or 5 times the current PRP testing times I'm getting, so, assuming that that's a statistically accurate sample, the current sieve file should be good for a while.

What did make me a little wary about the current sieve depth, though, is that it's only at p=5T, yet NPLB is going to 30T for work far smaller than this. Of course, the last remaining k for this base is extremely low-weight, so that could have a lot to do with this seeming discrepancy.

[mdettweiler]

Reserving Sierp. base 12 up to n=300K.

[gd_barnes]

Riesel base 22 is complete to n=200K. Nothing more to report. One prime found since n=150K. Now unreserved.

It is now another base with one k remaining.

[gd_barnes]

Originally Posted by mdettweiler

Note: I'm guessing that it doesn't need any more sieving for quite a ways yet. A while back I let sr1sieve take a whack at it for about 5 or 6 hours, and it didn't find any factors at all. That translates to about 4 or 5 times the current PRP testing times I'm getting, so, assuming that that's a statistically accurate sample, the current sieve file should be good for a while.

I believe that is almost impossible for a file that goes all the way to n=1M. What we need to do is look at the expected # of factors vs. actual. If it's 10.2 to nothing, there's a problem. If it's 2.3 to nothing, then it's not statistically significant. (arbitrary figures) I can't remember if sr1sieve gives the expected # of factors. I think it may at the end, but only in the sr1sieve.log file. If not, sr2sieve can be run on just 1 k. Although inefficient, it will still give the correct expected # of factors immediately so it only needs to be run for a few seconds.

I suspect the sieve depth may be wrong. Many times when people use sr2sieve for sieving, they don't change that depth when they convert it to -G format. Personally, I always do. Otherwise it is misleading.

The correct sieve depth can be determined by trial and error. I'd probably try 25T to start with for a P-range with at least 3 expected factors. If none there, then go up to 50T. If there are some at 25T, then drop to 15T. Then go to 10T or 20T. In other words, keep splitting the difference until you hone in on the correct depth. Something within P=~100G of actual should be sufficient.

Comparing the sieve depth to the NPLB effort is a complete apples to oranges comparison. There is nothing even remotely similar about the two except (kind of) the n-range. Differences: 1 k vs. 700, base 2 vs. base 23, n=250K-1M vs. n=50K-1M, and sr1sieve vs. sr2sieve.

Can you post the remaining sieve file and I'll look into it? I like doing a little math sleuthing like that. :-)


Thanks,
Gary

[mdettweiler]

Originally Posted by gd_barnes

I believe that is almost impossible for a file that goes all the way to n=1M. What we need to do is look at the expected # of factors vs. actual. If it's 10.2 to nothing, there's a problem. If it's 2.3 to nothing, then it's not statistically significant. (arbitrary figures) I can't remember if sr1sieve gives the expected # of factors. I think it may at the end, but only in the sr1sieve.log file. If not, sr2sieve can be run on just 1 k. Although inefficient, it will still give the correct expected # of factors immediately so it only needs to be run for a few seconds.

I suspect the sieve depth may be wrong. Many times when people use sr2sieve for sieving, they don't change that depth when they convert it to -G format. Personally, I always do. Otherwise it is misleading.

The correct sieve depth can be determined by trial and error. I'd probably try 25T to start with for a P-range with at least 3 expected factors. If none there, then go up to 50T. If there are some at 25T, then drop to 15T. Then go to 10T or 20T. In other words, keep splitting the difference until you hone in on the correct depth. Something within P=~100G of actual should be sufficient.

Comparing the sieve depth to the NPLB effort is a complete apples to oranges comparison. There is nothing even remotely similar about the two except (kind of) the n-range. Differences: 1 k vs. 700, base 2 vs. base 23, n=250K-1M vs. n=50K-1M, and sr1sieve vs. sr2sieve.

Can you post the remaining sieve file and I'll look into it? I like doing a little math sleuthing like that. :-)


Thanks,
Gary

Hmm...interesting. I'd forgotten about the expected # of factors, as well as the possibility that someone may have forgotten to update the p-range in the file header. Do you know who originally sieved this file? Maybe we can ask them where they sieved it to.

The sieve depth in my copy of the file matches that on the one you've got on your web site. Thus, to get a sieve file like mine you'll need to take just k=68 (the file on your web site still contains k=8 for which I found a prime a while back), and remove everything up to n=250K. When I did trial sieving with it earlier I must have not bothered to record what depth I sieved to since no factors were found. In retrospect, I probably should have.

Max

[gd_barnes]

Originally Posted by mdettweiler

Hmm...interesting. I'd forgotten about the expected # of factors, as well as the possibility that someone may have forgotten to update the p-range in the file header. Do you know who originally sieved this file? Maybe we can ask them where they sieved it to.

The sieve depth in my copy of the file matches that on the one you've got on your web site. Thus, to get a sieve file like mine you'll need to take just k=68 (the file on your web site still contains k=8 for which I found a prime a while back), and remove everything up to n=250K. When I did trial sieving with it earlier I must have not bothered to record what depth I sieved to since no factors were found. In retrospect, I probably should have.

Max

It may have been Kenneth who sieved it but I can't be for sure without doing some research. Regardless in the next couple of days, I'll take the file I have posted, remove k=8 and n<250K, and give it a whirl to see what I come up with.

[gd_barnes]

I decided it's not worth my personal time to determine the sieve depth of the file. It could be correct although it is unlikely.

I sieved it for a little over an hour on a slow core and like you did found nothing. If the true sieve depth is P>8T, it could a full 1-2 CPU days to narrow it down, even to the nearest trillion, because the factors are so infrequent. That's no problem for me but I didn't want to take the personal time to mess with it.

As an FYI, from the shown sieve depth at P=~5.8T to 6T, the expected number of factors is 7.7. If you run that entire range and get no factors, which would have taken ~7.5 hours on my one slow core, it's a virtual guarantee that the sieve depth is wrong.

If you ran it for 5-6 hours on a fast core, it's likely you did an even larger range than the above, which proves the point even more.

I posted the updated file with n<250K and k=8 removed on the reservations page (with the slightly higher sieve depth that I took it to). If someone reserves it, they should use the expected # of factors (not the actual) to determine optimum sieve depth at their current range and may have to use some sleuthing to determine the correct starting depth.

Since my machine was 32-bit and would have taken 7.5 hours to get 7.7 factors, that's about 1 factor per hour. But 64-bit would have yielded an expected factor every half hour, which makes it clearly worth sieving further at P=~6T. Although if the true depth is well over double that (very doubtful), then it would not be.

If this were a lower n-range, I'd have some fun messing with it.


Gary

[Cruelty]

Base 10 (Riesel + Sierpinski) doublechecked till n=220000.

[gd_barnes]

Here's an effort that I've picked up after a 4-month hiatus due to a machine that went down in the middle of it:

Sierp base 31 is at n=11.5K; 46 primes found since n=11K; 1776 k's remaining.

This one will stay going steady on one fast core to n=18K. I'll then decide if I still want to take it to n=25K. If so, I'll probably put 2-3 cores on it.