Balancing the k's remaining for R66:

All k's remaining at n=11K: 101668

primes previously submitted for k<0.243M: 52

primes currently submitted for k=0.243M-17.578M for n=11K-25K: 5625 (after removing duplicates and k's already primed for n=10K-11K)

primes currently submitted for k>99.461M for n=11K-25K: 877 (after removing duplicates and k's already primed for n=10K-11K)

k's currently remaining for R66: 95114

Current test range, # of primes for n=11K-25K, and k's remaining:

k<0.243M to n=25K; 52 primes for n=11K-25K; 129 remain
k=0.243M-17.578M to n=25K; 5625 primes for n=11K-25K; 10678 remain
k=17.578M-99.461M to n=11K; nothing yet for n=11K-25K; 82692 remain
k>99.461M to n=25K; 877 primes for n=11K-25K; 1615 remain

Attached are the primes for k=0.243M-17.578M and k>99.461M for n=11K-25K with all duplicates removed. Also attached are all k's remaining for R66 at this moment.

[QUOTE=rogue;541437]The range was sieved (not by me) slightly above 25000, but I don't know the limit. It might have been 25050 or 25100, but since I didn't do the sieving, I don't know what the max n was. If there are primes above 25000, why can't you use them? If you want, I'll try to remove those n from the remaining tests I have.

As for the duplicates, that is possible. There were times that pfgw was stopped abnormally, but when restarted had an invalid ini file. It is likely that caused the problem as it didn't restart in the correct place. I have never been able to track down the cause of that issue to get it resolved. I'll check the future ranges for duplicates before I sent them.

I will grab the primes you mentioned to remove those k from testing, but it is likely that I already tested some of them. I'll endeavor to remove those k from future submissions.[/QUOTE]


OK thanks for any cleanup that you can do.

I could choose to use the primes for n>25K but not only do I not know the exact search depth I don't know if all or part of the ranges were searched to that depth. For a base this big I'll choose to keep it cleaner.

Why not use LLR instead of PFGW? That's what I use for base 3. LLR's StopOnPrime option never forgets k's found prime on restarts.

[QUOTE=gd_barnes;541439]OK thanks for any cleanup that you can do.

I could choose to use the primes for n>25K but not only do I not know the exact search depth I don't know if all or part of the ranges were searched to that depth. For a base this big I'll choose to keep it cleaner.

Why not use LLR instead of PFGW? That's what I use for base 3. LLR's StopOnPrime option never forgets k's found prime on restarts.[/QUOTE]

Since I maintain pfgw, I tend to use it over llr with the number_primes option. Most of the remaining ranges are being tested with PRPNet, but I had to make some updates to PRPNet to handle a large number of conjectures on a single server when using the onekperclient option. The PRPNet clients will use llr for this form. I have 32 ranges left, 26 of which will be tested using PRPNet. I can do one of those ranges in less than 10 days. Those ranges won't have duplicates, but I do have to eliminate the k with primes per the other post.

[QUOTE=gd_barnes;541439]Why not use LLR instead of PFGW? That's what I use for base 3. LLR's StopOnPrime option never forgets k's found prime on restarts.[/QUOTE]

It is my experience, especially since base 3 is very primeproductive, that at some point the advantages LLR has towards PFGW is somewhat partially or fully eliminated due to the constant reading and writing of a new .ini file for LLR. LLR writes a new .ini file for each new line it handles in the inputfile and PFGW appears to write once every minute. Things might have changed, but it might be worth investigating wich program actually does best for such small n test - even though PFGW tent to be 15% slower per test - because PFGW might actually do better compared to LLR, especially as the amount of primes grow, due to the smaller .ini file :smile:

[QUOTE=KEP;541480]It is my experience, especially since base 3 is very primeproductive, that at some point the advantages LLR has towards PFGW is somewhat partially or fully eliminated due to the constant reading and writing of a new .ini file for LLR. LLR writes a new .ini file for each new line it handles in the inputfile and PFGW appears to write once every minute. Things might have changed, but it might be worth investigating wich program actually does best for such small n test - even though PFGW tent to be 15% slower per test - because PFGW might actually do better compared to LLR, especially as the amount of primes grow, due to the smaller .ini file :smile:[/QUOTE]

That is correct. pfgw writes to the ini file once per minute.

KEP's point makes sense when the tests are really fast, but his "at some point" has it backward- at some exponent value, the LLR test takes more than a minute each, so for any n larger than that value LLR is writing to the ini file less than once a minute and thus less than PFGW.

I thought this was among the many reasons PFGW is often used for new-base work and small tests, while LLR is strongly favored for large-test work.

I have gone thru the list of primes and the list of candidates to be tested and have removed all n > 25000 and all k which have a prime per post 1631. Future submissions from me for this base should be clean. I tried to be careful so as to avoid making mistakes.

[QUOTE=VBCurtis;541492]KEP's point makes sense when the tests are really fast, but his "at some point" has it backward- at some exponent value, the LLR test takes more than a minute each, so for any n larger than that value LLR is writing to the ini file less than once a minute and thus less than PFGW.[/QUOTE]

I assumed that Gary was actually doing small base 3 tests.

You are correct, the value of the exponent does in fact matter. But for n<50K and maybe n<100K for base 3, I would think that PFGW is the fastest alternative, simply because the input/output read/write of the .ini file takes too long as the ini file grows due to the growing number of primed k's. But as always, just like with multithreading and everything else that is somewhat system dependant, test locally and figure out what actually is most optimal program to use. And yes, one of the reason PFGW is used for starting up bases is among other features, the reason that PFGW writes once a minute (Thanks Mark for clearing that) in stead of several times a second, when doing very small tests :smile:

I was doing small base 3 tests (n=25K-50K). I did not know there was much time difference between the two. Anyway I still prefer LLR because I am stopping the programs frequently to do other stuff and I don't want to have to worry about whether the program will "lose" the knowledge that previous primes were found.

[QUOTE=gd_barnes;541525]I was doing small base 3 tests (n=25K-50K). I did not know there was much time difference between the two. Anyway I still prefer LLR because I am stopping the programs frequently to do other stuff and I don't want to have to worry about whether the program will "lose" the knowledge that previous primes were found.[/QUOTE]

When using number_primes with pfgw, it will read pfgw.log and avoid candidates that could be filtered by those primes. At least that is the way it is supposed to work.

I use srsieve2 to reformat the output as ascending k then ascending n. It makes it a lot easier to work with the input file and it allows one to compute a better estimate as to when processing of the file will be completed.

Progress update
 

K4 S53 at 1.575M

Here is the next batch of R66 primes. All k thru 44451283 are tested to n=25000.

[QUOTE=rogue;544792]Here is the next batch of R66 primes. All k thru 44451283 are tested to n=25000.[/QUOTE]

Primes that were found for k=17.578M-44.4515M n=11K-25K: 9190
Primes in that group already found prime for n=10K-11K: 15
Unique k's found prime for k=17.578M-44.4515M n=11K-25K: 9175

R66 previously remaining at n=25K: 95114
Primes found for k=17.578M-44.4515M n=11K-25K: 9175
R66 k's now remaining: 85939

Attached are the 15 k's that were found prime for n=11K-25K that already had a prime for n=10K-11K. I'm hoping that will help you save some time in your remaining searches.

[QUOTE=gd_barnes;544855]Primes that were found for k=17.578M-44.4515M n=11K-25K: 9190
Primes in that group already found prime for n=10K-11K: 15
Unique k's found prime for k=17.578M-44.4515M n=11K-25K: 9175

R66 previously remaining at n=25K: 95114
Primes found for k=17.578M-44.4515M n=11K-25K: 9175
R66 k's now remaining: 85939

Attached are the 15 k's that were found prime for n=11K-25K that already had a prime for n=10K-11K. I'm hoping that will help you save some time in your remaining searches.[/QUOTE]

Hmm. I thought I had removed k with previously known primes. Which k already had primes? Maybe they were in a range that I didn't clean-up before finishing.

[QUOTE=rogue;544863]Hmm. I thought I had removed k with previously known primes. Which k already had primes? Maybe they were in a range that I didn't clean-up before finishing.[/QUOTE]

See the attachment to the previous post. They were in a fairly narrow k-range of k=36.5M-38.6M so you probably missed removing them in one file or something like that.

[QUOTE=gd_barnes;544867]See the attachment to the previous post. They were in a fairly narrow k-range of k=36.5M-38.6M so you probably missed removing them in one file or something like that.[/QUOTE]

You are correct. They were all in primes_14.log. None were in any of the other 9 files I submitted.

K4 S53 at 1.6M (RES file attached)
Extending reservation to 1M7

Reserving S53 to 305K

The "top 10 primes" for R55 has the prime 68*55^29173-1, however, 68*55^1-1 = 3739 is prime, thus this prime is not the [I]first[/I] prime for k=68

[QUOTE=sweety439;549882]The "top 10 primes" for R55 has the prime 68*55^29173-1, however, 68*55^1-1 = 3739 is prime, thus this prime is not the [I]first[/I] prime for k=68[/QUOTE]


Good catch. This revealed an error in this base. k=608 (not k=68) was only tested up to n=25K. No prime was found. From this point forward k=608 was misread as k=68 and so k=68, despite having several small primes including at n=1, was tested for n>25K with a prime quickly found at n=29173.

So this brings to light the fact that k=608 has only been tested to n=25K and has never had a prime found.

I have updated the pages accordingly including removing the larger prime for k=68 and will begin a search 608*55^n-1 for n>25K.

An odd state of affairs here:

After all of that messing around with sieving 608*55^n-1 for n=25K-100K (and preparing to sieve n=100K-300K) because it was found to erroneously only have been tested to n=25K:

608*55^25062-1 is prime!

Found by the 5th test in the sieve file!

So R55 is back to 5 k's remaining. :smile:

Reserving S88 to n=500k (250-500k) for BOINC

S 53
 

K4 S53 at 1.61M


S53 -200K-305K -res sent to Gary
Base released ( except K4 of course)

Here are a bunch of primes for R66. The k between 94245817 and 99461099 still need to be tested to n=25000. All k outside of that range have been tested to n=25000. I hope to complete finish it off in a few weeks. Since I started this on 10/19 of last year, I will be happy to have finished it. It would probably take less time to get S3 to n=50000 than the time it took me to do this (and no, that is not next on my list).

Gary, if you think that there are other gaps that I could have missed, please let me know and I'll investigate.

Reserving S91 to n=500k (200-500k) for BOINC

[QUOTE=rogue;553323]Here are a bunch of primes for R66. The k between 94245817 and 99461099 still need to be tested to n=25000. All k outside of that range have been tested to n=25000. I hope to complete finish it off in a few weeks. Since I started this on 10/19 of last year, I will be happy to have finished it. It would probably take less time to get S3 to n=50000 than the time it took me to do this (and no, that is not next on my list).

Gary, if you think that there are other gaps that I could have missed, please let me know and I'll investigate.[/QUOTE]
No gaps that I can see so all is good. There were 9 k's found prime that already had a prime.

Balancing:
k's previously remaining: 85939
subtract primes in file: -17587
add k's that already had primes: +9
k's currently remaining: 68361

primes for k's that already had primes:
81440638*66^24455-1
81587724*66^21701-1
81638180*66^14564-1
81790115*66^12386-1
83244685*66^23606-1
83284753*66^16709-1
83508219*66^12744-1
83790529*66^18610-1
83800758*66^14408-1

Their previous primes:
81440638*66^10679-1
81587724*66^10915-1
81638180*66^10923-1
81790115*66^10952-1
83244685*66^10974-1
83284753*66^10943-1
83508219*66^10955-1
83790529*66^10907-1
83800758*66^10907-1

The last of the primes. The search is now down to n=25000 and the range is released.

S88 tested to n=500k (250-500k)

2 primes found, 6 remain

Results emailed - Base released

Progress update
 

K4 S53 at 1.65M

R36 is, finally, complete to 400k (800k base-6). Testing continues.

S91 tested to n=500k (200-500k)

5 primes found, 12 remain

Results emailed - Base released

Progress update
 

K4 S53 at 1.67M

Progress update
 

K4 S53 at 1.7M -reserving to 1M8

Reserving S80 to n=500k (250-500k) for BOINC

S80 tested to n=500k (250-500k)

3 primes found, 12 remain

Results emailed - Base released

Reserving rest of S53 from 305K to 400K

S53 from 305K to 400K done
280*53^333574+1 is prime! (575177 decimal digits) Time : 512.134 sec. ( already reported)
RES sent to Gary , base released

Progress update
 

K4 S53 at 1.725M

reserve
 

reserve S100 all k's(433 922 2145) to 1.5M.

[QUOTE=hwt;575806]reserve S100 all k's(433 922 2145) to 1.5M.[/QUOTE]


Have you determined how long each test takes?

433*100^1000330+1 is composite (4931.7516s+0.0224s)
Sorry,I didn't have an estimate of the number before, now I reserve to 1.02M(810 nums)

Progress update
 

K4 S53 at 1.75M

Progress update
 

K4 S53 at 1.8M

Reserving S70 to n=800k (400-800k) for BOINC