[quote=rogue;205833]I discovered that I made some errors in the bases that I had reported in the past week.

I went back through my logs and found these primes:

8*803^1243+1

95*516^726+1
120*516^647+1
121*516^531+1

I double-checked my work for Sierpinski and Riesel bases 322, 328, 516, and 803. These are the only discrepancies. I re-ran the script then looked at the primes I submitted verses the contents of pl_remain.txt.

I will rerun the remaining k for those conjectures up to 25000 to ensure that I didn't make any further mistakes. I'm not expecting anything to show up, but one never knows...

This is what I get for breaking up the work across multiple computers. :censored:[/quote]

One thing you might consider is just running the starting bases script up to n=2500 on one core and then sieving and testing n=2500 to n=25K in whatever manner and across whatever # of cores you deem necessary. That's what I do. If you do that, you can use the starting bases primes as a starting point for adding larger primes to it and you'll avoid missing small primes (n<2500) that are on multiple cores.

Even for conjectures as large as k=100,000, it rarely takes more than a couple of days and most of the time it takes less than a day. In other words, it shouldn't be necessary to split searching for such small primes across multiple cores or machines. IMHO, there are so many small primes on most bases that it's a lot safer to run all k's at once on one core up to n=2500.

One thing that I don't do most of the time anymore since we got the new bases script up to par is check all k's that will ultimately need a prime vs. primes submitted by people to see if the k's remaining balance. Eventually I do that, usually when the base is proven or it gets down to 1 k remaining but not right away anymore. It used to be that I checked everyone on a new base up to n=2500. But with the new bases script and the multitude of new bases being run, I don't do that most of the time anymore. It takes enough time to keep the pages up to date.


Gary

[QUOTE=gd_barnes;205861]One thing that I don't do most of the time anymore since we got the new bases script up to par is check all k's that will ultimately need a prime vs. primes submitted by people to see if the k's remaining balance. Eventually I do that, usually when the base is proven or it gets down to 1 k remaining but not right away anymore. It used to be that I checked everyone on a new base up to n=2500. But with the new bases script and the multitude of new bases being run, I don't do that most of the time anymore. It takes enough time to keep the pages up to date.[/QUOTE]

That is similar to what I did. I ran the script to n=100. I then merged the list of k from pl_remain.txt with the primes that I submitted. Excluding k=1, the "holes" in the list would represent the k that need a prime. I then sieve from n=100 to n=10000 (since I already did the range from 10000 to 25000 for those k). For the primes I listed earlier, I searched up to n=25000 for them when I didn't have to. There are no cases where I found a k that I hadn't searched from n=10000 to n=25000.

[quote=rogue;205868]That is similar to what I did. I ran the script to n=100. I then merged the list of k from pl_remain.txt with the primes that I submitted. Excluding k=1, the "holes" in the list would represent the k that need a prime. I then sieve from n=100 to n=10000 (since I already did the range from 10000 to 25000 for those k). For the primes I listed earlier, I searched up to n=25000 for them when I didn't have to. There are no cases where I found a k that I hadn't searched from n=10000 to n=25000.[/quote]

No, what I mean is: When you very first reserve a base, consider running the starting bases script to n=2500 before sieving remaining k's. Running to only n=100 leaves way too much room for error. There are still too many k's remaining and small primes to be found. IMHO, the script should always at least be used for a search to n=1000 with the possible exception of some large huge-conjectured bases (base 63 might be an example).

I promise it won't take much longer and your administrative hassle will be much less.

Heck, I've gotten to where if I know there is only going to be ~1 to 10 k's remaining on a base by n=2500, I'll run the starting bases script to n=5K or 10K without sieving. The more k's that you have to sieve, the more you have to manually account for stuff and the easier it is to forget primes hanging on a "rogue" machine somewhere (pun intended, lol). The starting bases script automates the accounting for all of the k's (with the exception of k's that have partial algebraic factors to make a full covering set) and so avoids such problems.

Sierpinski base 780: conjectured k 243, 2 k's remaining, tested to n=5K.
k=1 is a GFN; trivial factors and primes attached. Remaining:
43*780^n+1
230*780^n+1
Not reserved.

[QUOTE=gd_barnes;205875]No, what I mean is: When you very first reserve a base, consider running the starting bases script to n=2500 before sieving remaining k's. Running to only n=100 leaves way too much room for error. There are still too many k's remaining and small primes to be found. IMHO, the script should always at least be used for a search to n=1000 with the possible exception of some large huge-conjectured bases (base 63 might be an example).

I promise it won't take much longer and your administrative hassle will be much less.

Heck, I've gotten to where if I know there is only going to be ~1 to 10 k's remaining on a base by n=2500, I'll run the starting bases script to n=5K or 10K without sieving. The more k's that you have to sieve, the more you have to manually account for stuff and the easier it is to forget primes hanging on a "rogue" machine somewhere (pun intended, lol). The starting bases script automates the accounting for all of the k's (with the exception of k's that have partial algebraic factors to make a full covering set) and so avoids such problems.[/QUOTE]

I see. I typically stop low because I found that starting sieving earlier save a lot of execution time. As you pointed out, the administrative hassle can be costly, as it was to me.

I have completed my retest of the k from the aforementioned conjectures (up to n = 10000). I didn't miss any other primes. :tu:

Sierpinski base 520
 

I have completed my testing of this base to n = 25000 and am releasing it. The primes are attached.

k=1 and k=520 are GFNs, which have not been tested.

k=369 and k=373 remain.

The other k have trivial factors.

[quote=rogue;205897]I see. I typically stop low because I found that starting sieving earlier save a lot of execution time. As you pointed out, the administrative hassle can be costly, as it was to me.

I have completed my retest of the k from the aforementioned conjectures (up to n = 10000). I didn't miss any other primes. :tu:[/quote]

Hum. Strange. I think most of our long time searchers have found that searching to n=500 or 1000 when starting a base before sieving is the most efficient for CPU time spent. Of course it would vary somewhat depending on the size and weight of the base.

Do you set factoring to 100% with the -f switch when running the new bases script? If not, that would explain things. Without trial factoring, you can't go too far before sieving is more CPU efficient.

Along those lines, I've found for extremely high weight bases with huge contectures such as bases 3/7/15, it makes sense to only trial factor to ~30% with the -f30 switch. Searching to n=500 or 1000 generally still holds.

[QUOTE=gd_barnes;205942]Do you set factoring to 100% with the -f switch when running the new bases script? If not, that would explain things. Without trial factoring, you can't go too far before sieving is more CPU efficient.[/QUOTE]

No, I have used -f with a script. I hadn't really even thought about it. If and when I tackle another difficult base (such as 928), I will use it.

Riesel base 923
 

Primes found:

2*923^2-1
4*923^1-1
6*923^114-1

The conjecture is proven.

Riesel Base 881
 

Primes found:

2*881^132-1
4*881^3-1

k=6 has trivial factors. The conjecture is proven.

Riesel base 860
 

Primes found:

2*860^62-1
3*860^1-1
4*860^3-1
5*860^12-1
6*860^4-1
7*860^5-1

k=1 has trivial factors. This conjecture is proven.