[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.