Serge,

For any new bases that you've started, I'm going to need primes and results for n>2500 or n>1000. I typically double-check new bases up to n=1000 or n=2500 but to go higher takes a little too much of my CPU (and personal) time. This also avoids people sending or posting huge primes or results files at low n-values for bases with large conjectures, which can be almost impossible in some cases.

In other words, since math is so exacting, for a true proof, I can't just take people's word for it that certain k's are remaining at a certain testing limit. I need all of the primes.


Thanks,
Gary

Thanks for the excellent and large contributions everyone. I was out of town for a week and will work towards getting the web pages updated over the next few days.


Gary

Riesel & Sierp Base 53
 

Reserving Base 53 Riesel (94k's) and Sierp (28k's) from n=40K-100K

Sieving and PRP'ing them together:cry: :cry:

Sierp Base 80
 

Sierp Base 80 complete n=25K-100K

4 primes found

893*80^28705+1
233*80^36917+1
1024*80^46306+1
787*80^48156+1

Results emailed

Boy did this thing die after n=48K:censored:

Sierp base 35 is complete to n=10K; 824 k's remain. Now unreserved.

Highest primes and k's remaining shown on the pages.

[quote=rogue;196938]There are 196 remaining k at n=10000. Here are the k:
[code]
73*58^n+1
178*58^n+1
222*58^n+1
(etc.)
[/code]

I have attached the primes for n < 10000. Now back to Riesel base 58...[/quote]


Mark,

There are several problems with your list of primes and k's remaining:

k=73 has a prime at n=132.
k=1102 still remains.*
k=7192 still remains.*
k=14152 still remains.*
k=35805 still remains.**


* - These are multiples of the base where k+1 is prime so they need to be tested. Attaching a results file would help me determine what happened.

** - Upon a double check of the above 4 k's to n=2500, I found a prime for k=35805 at n=16. This was not included in your primes file.

I did a primality proof on all of your primes and everything checked out. I haven't double-checked the base up to n=2500 yet. I'll do that in a little while. I came up with the above differences by comparing the initial k's that needed primes with your primes list. Here is the balancing:

k's in your list: 196 k's
+ k's still remaining not in your remaining list: 4
- k's with a prime in your primes list: 1
- k's with a prime that I found: 1

Total: 196+4-1-1=198 k's remaining.

One more thing: You included multiple primes for many k's. It's very easy to set the stop on prime command in PFGW. Please use that when running a new base. It will make it easier for me (and you) to balance k's remaining and save you (a lot) of CPU time. Also, I only list primes in the top 10 that are the smallest for each k. Otherwise we could go on searching each k indefinitely and get larger and larger primes. In this case, it does change the top 10. k=2953, which shows a prime at n=9410 "appears" to be 7th highest but since it also has a prime at n=7576, it's not.

With this many problems, in order to list it on the pages, I'll either need you to attach a results file or redo the range. If rerunning, please attach a results file for n>2500. Thanks.


Gary

[QUOTE=gd_barnes;197568]There are several problems with your list of primes and k's remaining:

k=73 has a prime at n=132.
k=1102 still remains.*
k=7192 still remains.*
k=14152 still remains.*
k=35805 still remains.**

* - These are multiples of the base where k+1 is prime so they need to be tested. Attaching a results file would help me determine what happened.

** - Upon a double check of the above 4 k's to n=2500, I found a prime for k=35805 at n=16. This was not included in your primes file.

I did a primality proof on all of your primes and everything checked out. I haven't double-checked the base up to n=2500 yet. I'll do that in a little while. I came up with the above differences by comparing the initial k's that needed primes with your primes list. Here is the balancing:

k's in your list: 196 k's
+ k's still remaining not in your remaining list: 4
- k's with a prime in your primes list: 1
- k's with a prime that I found: 1

Total: 196+4-1-1=198 k's remaining.

One more thing: You included multiple primes for many k's. It's very easy to set the stop on prime command in PFGW. Please use that when running a new base. It will make it easier for me (and you) to balance k's remaining and save you (a lot) of CPU time. Also, I only list primes in the top 10 that are the smallest for each k. Otherwise we could go on searching each k indefinitely and get larger and larger primes. In this case, it does change the top 10. k=2953, which shows a prime at n=9410 "appears" to be 7th highest but since it also has a prime at n=7576, it's not.

With this many problems, in order to list it on the pages, I'll either need you to attach a results file or redo the range. If rerunning, please attach a results file for n>2500.[/QUOTE]

I don't understand why you didn't trust that the file I attached contained primes. The file name should have immediately implied that I performed a primality test on those numbers.

The file I sent includes the prime 73*58^132+1.

As for 35805*58^16+1, it failed the primality test without -a1, but passed with -a1. PFGW did not detect any errors in gwnum. I will need to talk to George about that.

As for 1102, 7192, and 14152, I neglected to verify that when k%58==0 that (k/58)*58^n+1 was prime for n > 1. I removed those k after I completed testing to n=10000, thus they didn't have primes for n<10000.

I had never used the number_primes option and wasn't aware of it until just now. It is a relatively obscure feature. As for it being "easy", that is a subjective statement.

I don't intend to rerun anything at this time because I really want to get the Riesel side to n=50,000, which will probably take me until February. I was just getting my feet wet. If you really want to rerun to n=2500, that is your choice.

I strongly urge you to start a new thread and sticky it to help anyone else who wants to work on a new base so that they can provide you with results that will stand up to your scrutiny. Your requirements and all over the forum. Some are stated, others are implied or require people to dig further to find answers. You need to be more explicit. Pointing people to a single script that could work for most (if not all) bases (either Sierpinski or Riesel) would be very helpful. I only found out after I started that there were other scripts that could have been used to save me a lot of time.

[quote=rogue;197590]I don't understand why you didn't trust that the file I attached contained primes. The file name should have immediately implied that I performed a primality test on those numbers.

The file I sent includes the prime 73*58^132+1.

As for 35805*58^16+1, it failed the primality test without -a1, but passed with -a1. PFGW did not detect any errors in gwnum. I will need to talk to George about that.

As for 1102, 7192, and 14152, I neglected to verify that when k%58==0 that (k/58)*58^n+1 was prime for n > 1. I removed those k after I completed testing to n=10000, thus they didn't have primes for n<10000.

I had never used the number_primes option and wasn't aware of it until just now. It is a relatively obscure feature. As for it being "easy", that is a subjective statement.

I don't intend to rerun anything at this time because I really want to get the Riesel side to n=50,000, which will probably take me until February. I was just getting my feet wet. If you really want to rerun to n=2500, that is your choice.

I strongly urge you to start a new thread and sticky it to help anyone else who wants to work on a new base so that they can provide you with results that will stand up to your scrutiny. Your requirements and all over the forum. Some are stated, others are implied or require people to dig further to find answers. You need to be more explicit. Pointing people to a single script that could work for most (if not all) bases (either Sierpinski or Riesel) would be very helpful. I only found out after I started that there were other scripts that could have been used to save me a lot of time.[/quote]

That's what I tried to imply on the k=73 prime. Your file contains the prime. The problem is that you had the k remaining.

I'm confused at to why you removed 1102, 7192, and 14152 from your list of k's remaining. They are still remaining because k+1 is prime. Other multiples of the base where k+1 is composite could be removed, which you correctly did.

You didn't have the k=35805 prime in your file.

Mark, you've done extensive changes to PFGW. The stop-on-prime option is all over the threads here. IMHO, it's anything but obscure. I'm sorry if I implied that it "should have been known". I figured you knew about it and were using different software.

I've now double checked everything to n=2500 and everything looks good to that point. Removing your n>2500 primes leaves 198 k's remaining, which is what I had calculated.

Here is what I need on new bases:

1. Primes n>1000 (or n>2500).

2. k's remaining at the current testing limit.

3. Results for n>1000 (or n>2500).


Here is what I think would help and is what I do to "balance" each new base:

1. Start from an original list of all k's that must be searched. Include ALL MOB in this.

2. Create a separate list of all k's where primes are found.

3. Cross reference the 2 lists and see what remains.

4. From what remains in #3, remove all GFN's and all MOB where k+1 (or k-1 for Riesel) are prime.

If you do this balancing, you'll see the differences that I found.

I'm sorry but the mathematical proof of these things requires that I check everything in detail. When you include k's that should be removed and exclude k's that should still be there, I get very leary very fast. That's why I suggested a complete rerun. I'll back off that now since my double check was able to balance to the 198 k's remaining.

I'm now double checking Riesel base 58 up to n=2.5K. I'll let you know if I see any differences. Usually I do that right away on any new base but on the larger ones, I'll sometimes let it slide for an extended period.


Gary

[QUOTE=gd_barnes;197624]That's what I tried to imply on the k=73 prime. Your file contains the prime. The problem is that you had the k remaining.

I'm confused at to why you removed 1102, 7192, and 14152 from your list of k's remaining. They are still remaining because k+1 is prime. Other multiples of the base where k+1 is composite could be removed, which you correctly did.

You didn't have the k=35805 prime in your file.

Mark, you've done extensive changes to PFGW. The stop-on-prime option is all over the threads here. IMHO, it's anything but obscure. I'm sorry if I implied that it "should have been known". I figured you knew about it and were using different software.[/QUOTE]

I see regarding k=73. I'm not certain how that happened because I used the output from the script (i.e. k without primes) as input to srsieve.

As for the other three k, we are saying the same thing, but in different ways. If I had looked at the original output file and saw that n equaled 1 for k/58, then I would not have removed them. I had neglected to make that check.

As I stated, 35805*58^16+1 was PRP, but failed the primality test, thus it wasn't found in the file I sent to you (the file that PFGW writes to upon finding a prime). I didn't rerun the primality test because I've never seen a primality test fail without triggering an error condition in PFGW, which is what happened here. In other words I didn't compare the inputs and outputs from the primality test to discover the discrepancy. George is looking into it because the problem appears to be in gwnum. I presume that you used PFGW 1.2 to do a primality test or used the -a1 switch with PFGW 3.x. How did you prove primality for that number?

I see what you mean on number_primes. I had not read your post in Software/instructions/questions, but had read in some other thread how to do a base, specifically one that had a PFGW script which split the k with a prime from those without a prime into separate files. I used one output file as input to srsieve, thus eliminating the need to generate that file by hand.

Results for base 42 for n=25-30k
 

[QUOTE=Mathew Steine;195973]Hello

I would like to reserve Riesel base 42 to n=30K for all k's.[/QUOTE]

I have finished the test
primes
7698*42^26751-1
12039*42^27032-1
7614*42^27539-1
7614*42^29019-1 (double)

k's to remove: 3
extra primes: 1
other: when sieving sr2sieve stated that 2304 is algebraic not really sure what this means.

Attached are the results. Hopefully I did not miss anything.

[quote=rogue;197626]I see regarding k=73. I'm not certain how that happened because I used the output from the script (i.e. k without primes) as input to srsieve.

As for the other three k, we are saying the same thing, but in different ways. If I had looked at the original output file and saw that n equaled 1 for k/58, then I would not have removed them. I had neglected to make that check.

As I stated, 35805*58^16+1 was PRP, but failed the primality test, thus it wasn't found in the file I sent to you (the file that PFGW writes to upon finding a prime). I didn't rerun the primality test because I've never seen a primality test fail without triggering an error condition in PFGW, which is what happened here. In other words I didn't compare the inputs and outputs from the primality test to discover the discrepancy. George is looking into it because the problem appears to be in gwnum. I presume that you used PFGW 1.2 to do a primality test or used the -a1 switch with PFGW 3.x. How did you prove primality for that number?

[/quote]

Great. It sounds like we're on the same page now.

No, I'm using the newest PFGW 3.2.3 and no I didn't try it with the -a1 switch because I wasn't sure if that would work either. Fortunately I'm always curious what the factors are for a composite PRP and found it to be prime with Alpertron's applet.

Just like for you, it found 35805*58^16+1 as PRP and then found it to be composite when I used the -t switch. I tested for only PRP's up to n=2500 and then ran a separate test on all of them with the -t switch. That was the only one that failed. Typically I expect small PRP's to be composite about 1 in 10K to 100K times so it didn't surprise me initially.

I too have never experenced PFGW saying a true prime was composite. Perhaps the new GWNUM libraries did something. How were you able to isolate it to that? If so, I wonder if a similar bug exists in LLR or Prime95?


Gary