Bases 33-100 reservations/statuses/primes

[mdettweiler]

Originally Posted by kar_bon

I've tested them first, found as PRP and then checked prime. No errors.

I think we're getting a little mixed up as to what we're talking about. I'm referring to the new primes which Gary found when doublechecking R51 from scratch--including composites. He found 18 additional primes that were not found the first time around. What you're referring to are the primes reported by 10metreh (which didn't include the 18 new primes Gary found)--those are all indeed prime as you found.

[kar_bon]

I mean those 18 'missed' primes in the range n=1295 - 1327.

They were not missed by any verison of PFGW due any error, they were missed by any error in script, copy/paste or anything else.

[mdettweiler]

Originally Posted by kar_bon

I mean those 18 'missed' primes in the range n=1295 - 1327.

They were not missed by any verison of PFGW due any error, they were missed by any error in script, copy/paste or anything else.

Ah, I get it now.

[gd_barnes]

Originally Posted by mdettweiler

Perhaps these were due to the PFGW 3.3.4 bug?

I ran my test with PFGW 3.3.4. I started the doublecheck long before the bug was announced and I wasn't going to change midstream.

Also the chances of that many problems are extremely remote. Also the base is very small, further reducing such chance. Also, the close-knit pattern of the primes missed is much more likely indiciative of a human error. It was extremely obvious that it was human error, even had I used PFGW 3.3.6. Whenever errors are found in software that causes possible bad residues, it's usually extremely difficult to find missing primes. They are there but only come out in extremely rare circumstances and certainly not in big blocks of 18 like this.

I predict that there are no missed primes as a result of the bug on this base.

If there is one thing that I've found and I may start requesting this from everyone, especially on large-conjectured bases: No manually edited files. They have to be the exact output from a program attached directly, even if it means attaching many files. It is manually edited files that have been cut-and-pasted or where primes have manually been typed or moved around where the most errors are. I've gotten many files that are obviously output from the starting bases script but with primes cut-and-pasted at the bottom of them that are n>2500. I would much prefer the starting-bases script primes in one file and the primes n>2500 in a separate file as attachments. I even get ones where the primes n>2500 have been pasted in k-value order inside the n<=2500 primes. There should be no such manual cut-and-pasting or moving around of primes. It's much too error prone.

[Mathew]

Gary,

I am still interested in R51. However, at the moment I do not have any free cores. Without doing something which seems prone to too many errors. Mainly my R61 reservation is spread across a quad. I could bring it back to 1 core but it looks to me there would be a lot of manual editing, and I do not like that as a solution.

When I do have some free cores, I will start working on this one (if not already reserved).

Originally Posted by gd_barnes

I've gotten many files that are obviously output from the starting bases script but with primes cut-and-pasted at the bottom of them that are n>2500

When I have run the new bases script, then continue to n=25K pfgw will put the primes in the same log file. The new primes will be on the bottom there is no copy and pasting. Am I misunderstanding what you have written here?

[gd_barnes]

Originally Posted by Mathew Steine

When I have run the new bases script, then continue to n=25K pfgw will put the primes in the same log file. The new primes will be on the bottom there is no copy and pasting. Am I misunderstanding what you have written here?

Only slightly. First, I'm not making that a specific requirement right now. More than anything, I want people to be aware that manually cut-and-pasting -OR- adding/removing to primes or from k's remaining files is quite error prone and to please be careful, especially when doing so from across multiple cores. Second, the pfgw.log (or pfgw-prime.log) file that you are referring to is perfectly OK. The key is that you have not cut-and-pasted anything to it. It is output directly from PFGW; it just happens to be from 2 distinct runs of PFGW.

All of that said, if you want to make it easier on me, include the pl_prime.txt file that includes primes for n<=2500 and then include the pfgw.log (or pfgw-prime.log) file that includes only primes that are n>2500. That can be easily accomplished by renaming the pfgw.log file (or simply deleting it since it is effectively a subset of the pl_prime.txt file) after running the new bases script but before continuing higher. I prefer to get each prime only once. I haven't complained because I know that there is no manual editing of your files so I know that they should be accurate and it's pretty easy to remove the smaller primes from it. That way is preferrable to manually edited files.


Gary

[mdettweiler]

S75 complete to n=100K, 2 primes previously reported; results for 40K-100K attached. Releasing.

[MyDogBuster]

Riesel 72 the last k, tested to n=350K. Continuing

[Mathew]

R61

No primes

K=9642 is at 88K the rest are at 80K

R39 is to n=18.5K

58 primes found

Attached are the primes and remaining k's for R39

[unconnected]

Reserving S88 to n=50K.

[Rincewind]

A short update for R36

found 5 new primes

85189*36^27026-1
113403*36^28614-1
99790*36^30389-1
81695*36^31030-1
53538*36^31526-1

Currently testing at n=31k