Bases 33-100 reservations/statuses/primes

[vmod]

S100 finished to n=100K, no primes.

5 k's remaining, results attached, base released.

[gd_barnes]

S72 is complete to n=100K; 1 prime found for n=40K-100K; only k=493 remains; base released.

[10metreh]

I'm doing a little preliminary testing on R51. I'm not sure where I'll take it to eventually, but it won't be very far considering its high CK of 8632534.

[MyDogBuster]

I'm doing a little preliminary testing on R51. I'm not sure where I'll take it to eventually, but it won't be very far considering its high CK of 8632534.

Just to give you a point of reference, I'm doing S51 with a ck of 5183582.
I started it the day after Xmas last year and I'm about 33% done at n=9k.
I'm trying to finish it by Xmas this year.

[10metreh]

I'm not going to take it as far as 25K (unless someone suddenly releases a program that is 50 times faster than PFGW ).

But I have a 100% noob question: is it possible for PFGW to remove a k from a sieved file when it finds a prime for that k?

[mdettweiler]

Originally Posted by 10metreh

But I have a 100% noob question: is it possible for PFGW to remove a k from a sieved file when it finds a prime for that k?

Yes, there is. What you need to do is first make sure your sieve file is in ABC format. Often files will come in NewPGen format and their first lines look kind of like this (example taken from a sieve file I'm currently working on):
2300000000000:P:1:187:257
The 23... number is the sieve depth, "P" says that it's a +1 base (a -1 base would be "M"), 1 is not applicable to this use of the program, 187 is the base, and 257 also says that it's a +1 base in a different way (258 would be for -1 bases). The rest of the lines that follow are the numbers in "k n" format. (A more detailed explanation can be found in the newpgenformats.txt file that comes with PFGW.)

You need to change that to ABC format, which for the above example looks like this:
ABC $a*187^$b+1

ABC is a pretty simple format--you just specify the general form of the numbers you're testing, and replace variables with constructs like "$a", "$b", etc. as necessary. In this example, the header specifies the rest of the file to be read just like a NewPGen file--in "k n" format. This is handy since the easiest way to convert to ABC format from NewPGen is usually just to switch out the header as shown.

Once the file is in ABC format, you need to add an "ABC comment" to the first line, like this:

ABC $a*187^$b+1 // {number_primes,$a,1}

That tells PFGW to skip all further tests in the sieve file with a given $a value when a prime is found for that $a. Note that this does not hold when the program is restarted; there's a number of workarounds that people use around here, but I won't go into those here as it would make this already-long post that much longer. I'm sure others can come up with some suggestions quite quickly if needed.

[10metreh]

Originally Posted by mdettweiler

That tells PFGW to skip all further tests in the sieve file with a given $a value when a prime is found for that $a. Note that this does not hold when the program is restarted; there's a number of workarounds that people use around here, but I won't go into those here as it would make this already-long post that much longer. I'm sure others can come up with some suggestions quite quickly if needed.

Would srfile be one of the workarounds?

[mdettweiler]

Originally Posted by 10metreh

Would srfile be one of the workarounds?

Yes, I suppose it could be part of one. You could use srfile to remove the primed k's, then delete all pairs from the sieve file up to the first one left that's still untested, then delete pfgw.ini (to ensure that it starts at the beginning of the "new" file) and restart PFGW. It will then pick up where you left off before, but without testing the primed k's.

Perhaps a simpler solution, though, is to use Mini-Geek's remove-ks.pl script, the latest version of which can be found here. It can take a sieve file and PFGW's pfgw.log (or pfgw-prime.log) as input directly and remove all primed k's with one fell swoop, rather than each one individually as with srfile. Other than that, though, the rest of the abovedescribed process would be the same.

[rogue]

Originally Posted by mdettweiler

Yes, I suppose it could be part of one. You could use srfile to remove the primed k's, then delete all pairs from the sieve file up to the first one left that's still untested, then delete pfgw.ini (to ensure that it starts at the beginning of the "new" file) and restart PFGW. It will then pick up where you left off before, but without testing the primed k's.

Perhaps a simpler solution, though, is to use Mini-Geek's remove-ks.pl script, the latest version of which can be found here. It can take a sieve file and PFGW's pfgw.log (or pfgw-prime.log) as input directly and remove all primed k's with one fell swoop, rather than each one individually as with srfile. Other than that, though, the rest of the abovedescribed process would be the same.

I have a mod to srfile that can take the pfgw.log file with the -d switch and remove the k's. I have yet to pass that on to Geoff.

[gd_barnes]

Originally Posted by 10metreh

I'm doing a little preliminary testing on R51. I'm not sure where I'll take it to eventually, but it won't be very far considering its high CK of 8632534.

10metreh,

This is a tremendous effort, even to bring it up to n=10K, which is the minimum level that I've set for showing k's remaining on the pages, lest I spend a lot of admin time removing k's remaining in the future as bases progress. I'll be glad to accept any work that you end up doing on it and simply show the # of k's remaining at that level (in a manner similar to our S63 team effort) if that level is n<10K. I just wanted you to be aware of that.

I would guess that the effort to bring S51 to n=10K is at least half of the amount of effort to bring S63 with a conjectured k of 37M+ to n=10K, which we have as a team effort right now. The conjecture for S63 is > 4 times as high as S51 but being a 2^q-1 base, it is a heavier-weight base than most of them. We estimate that it will have ~57,000 k's remaining at n=10K.

One more thing: To complicate matters, since this is the Riesel side, this base will have partial algebraic factors to make a full covering set that will elimiante k's that are perfect squares where k=m^2 and m==(5 or 8 mod 13) as well as k's that are 51^q times those. As large as the conjecture is, this amounts to the elimination of 211 k's. You can see a general synopsis of them on the main Riesel web page now. The Sierp side will not have that issue.

Just to get an idea: How do you plan to attack this one?


Gary

[10metreh]

I am planning not to take it as far as 10K - that's too much for my resources. That's what the word "little" was there for. I don't know where I'll take it to, but the point was to actually get it started (split infinitive, but who cares?). And yes, I've taken the algebraic factors into account. It's annoying, but R51 was the lowest remaining untested conjecture by base.
I'll probably stop wherever I get by mid to end of August.

You can see a general synopsis of them on the main Riesel web page now

I presume this means that the pattern for R51 is similar to that for other bases. R51 itself isn't there yet.