Bases 501-1030 reservations/statuses/primes

[rogue]

Primes found:
2*650^2-1
3*650^1-1
5*650^2-1
6*650^6-1
7*650^1-1

k = 4 remains. AFAICT, there is a partial algebraic factorization, but it doesn't cover all n.


2*692^8-1
3*692^6-1
4*692^1-1
5*692^2-1
7*692^1041-1

k = 6 remains.

Both have been tested to n=25000. I am releasing these bases.

[mdettweiler]

Originally Posted by gd_barnes

Max, it would be a lot cleaner to get all of the results in one batch instead of separated by primed and unprimed k's. I try to keep everything somewhat consistent in my file storage. Also, on the primes. I just need only those...the primes. No "is prime" or "time: 0.0" on each line. Doing those two things would make it consistent with a pure PFGW run.

Oh, okay. The reason why I separate by primed and unprimed k's is because that way I can match up just the unprimed k's with the original sieve file, while leaving the primed one's since they're a lot harder to do that with (due to them being stopped midway). I do suppose, however, that I could recombine and resort the results after checking just the unprimed ones--that could work, though it would add another step to my already-complex process for doing conjecture results.

Regarding the various junk in the primes file: ah, that's because I copy those lines directly over from the LLR-formatted results file. I suppose it wouldn't be too hard to fix that.

[gd_barnes]

Willem,

If you have primes on more than ~20 k's to report, can you put them in the "code" and "/code" box or post a file of them so that the posts aren't quite so long? Easiest for so many primes is to attach the pl_primes file so that I know there are no typos. Thanks.

[gd_barnes]

S587 and S608 k=8 conjectures proven and added to the pages.

Once again, it took large primes to prove these:
6*587^24119+1
4*608^20706+1

[gd_barnes]

Originally Posted by mdettweiler

Oh, okay. The reason why I separate by primed and unprimed k's is because that way I can match up just the unprimed k's with the original sieve file, while leaving the primed one's since they're a lot harder to do that with (due to them being stopped midway). I do suppose, however, that I could recombine and resort the results after checking just the unprimed ones--that could work, though it would add another step to my already-complex process for doing conjecture results.

Regarding the various junk in the primes file: ah, that's because I copy those lines directly over from the LLR-formatted results file. I suppose it wouldn't be too hard to fix that.

IMHO, this matchup should not be necessary in the future when we're highly confident in PRPnet. All you'll really need is a conversion process. I feel we're getting just a little too complicated for our own good with it. Reference the 4 results that you got from Tim that weren't in the original sieve because he removed them after-the-fact after realizing they had algebraic factors. Just a simple conversion, one file (or perhaps 2 if a large n-range), none of the matchup and none of the primed/no-primed k's separation complication, is all that will really be needed.

I've gotten various PRPnet results from Mark and some others in various different formats before you started the matchup and conversion. Although I prefer them in the classical PFGW format, I don't mind too much if they're in different formats. I still have many old results in LLR and Phrot format and some in PRPnet format.

I never asked for everyone's original sieve file for matching results, regardless of how they searched their ranges. That would have taken forever. It's difficult enough just getting results. This project isn't like NPLB, which is much more exacting.

My 2 cents anyway.


Gary

[rogue]

Originally Posted by gd_barnes

S587 and S608 k=8 conjectures proven and added to the pages.

Once again, it took large primes to prove these:
6*587^24119+1
4*608^20706+1

Look at it this way. Since most of us test to n=25000 instead of a lower value (such as 10000 or 20000), this prevents these conjectures from showing up in the "Conjectures with one k" thread. It makes one wonder how many of those "single k remaining" conjectures will be proven by finding a prime for n<50000 or n<100000.

[gd_barnes]

Originally Posted by rogue

Look at it this way. Since most of us test to n=25000 instead of a lower value (such as 10000 or 20000), this prevents these conjectures from showing up in the "Conjectures with one k" thread. It makes one wonder how many of those "single k remaining" conjectures will be proven by finding a prime for n<50000 or n<100000.

Yes, I'm sure quite a few will fall by n=100K. Keep in mind, though, that the k's/bases remaining at n=25K are generally lower weight, sometimes much lower weight, than the ones remaining at n=5K. The percentage of k's/bases found prime for n=25K-100K will be quite a bit less than n=5K-25K. n=25K-100K would also probably take 50-75 times longer to search than n=5K-25K.

[mdettweiler]

Originally Posted by gd_barnes

IMHO, this matchup should not be necessary in the future when we're highly confident in PRPnet. All you'll really need is a conversion process. I feel we're getting just a little too complicated for our own good with it. Reference the 4 results that you got from Tim that weren't in the original sieve because he removed them after-the-fact after realizing they had algebraic factors. Just a simple conversion, one file (or perhaps 2 if a large n-range), none of the matchup and none of the primed/no-primed k's separation complication, is all that will really be needed.

I've gotten various PRPnet results from Mark and some others in various different formats before you started the matchup and conversion. Although I prefer them in the classical PFGW format, I don't mind too much if they're in different formats. I still have many old results in LLR and Phrot format and some in PRPnet format.

I never asked for everyone's original sieve file for matching results, regardless of how they searched their ranges. That would have taken forever. It's difficult enough just getting results. This project isn't like NPLB, which is much more exacting.

My 2 cents anyway.


Gary

Well, it's not so much a matter of confidence in the client/server application (LLRnet, PRPnet, etc.) as in making sure that there was no human error along the way. In almost all instances where I've found results missing from a range, it was due to a human slip-up, not a computer error, and sometimes this has pointed out significant problems in the process used by the person producing the results (Beyond's unstable machine that I caught in results processing comes to mind).

What will help a lot is when I finally get around to piecing together all my processing applications into one big program. The actual process is quite straightforward and rarely requires much non-automated interaction; the main hurdle to full automation is simply the matter of not having the time to code it up.

Also, at some point we'll hopefully have an NPLB-like stats DB set up for CRUS, which we can just dump all results into indiscriminately; the DB can handle sorting and categorizing the results without a problem, which would make it relatively easy to write code to check with the DB that certain conditions have been met (all tests below a prime on a given k have been tested, all results are present in a completed range, etc.) and then output the results in whatever format we want--LLR, PFGW, LLRnet, you name it.

In the meantime, though, I don't mind the extra work involved in making sure that everything's there. I agree that such precision is not needed for manual results, but for servers, there's many more variables involved and many more things that can go wrong--that's just the nature of their comparatively more complex setup. So therefore I'd rather spend an extra 5 minutes in processing than have, say, a whole range with conflicting duplicate results (a la Beyond's situation that I referenced earlier), or other such undesirable situations.

So, to sum up: in the future I'll be sure to combine non-primed and primed k's back into one results file at the end of processing to keep that consistent on your end. Never mind how much work it takes on my end to do that; just think of it as extra incentive for me to automate it further.

[kar_bon]

'My' R1019 has a CK=4 and the only remaining k=2 is at n=105600 so far (taking about 2200s for one test), so i thought i missed something such a prime at low n-value or a algebraic value.

Primes are (still) not predictable like: 'Oh, a low k-value... I will find a prime for n<25k!'

So for this only one small k and CK it's a tremendous work to do and from time to time, mostly newbies think it's easy to prove such thing.
I'm continuing this and it may take some months to reach 200k (my goal for now).

[MyDogBuster]

'My' R1019 has a CK=4 and the only remaining k=2 is at n=105600 so far (taking about 2200s for one test), so i thought i missed something such a prime at low n-value or a algebraic value.

Primes are (still) not predictable like: 'Oh, a low k-value... I will find a prime for n<25k!'

Predictable NOT. I just reported R376 with a CK = 144 and was proven with ALL the primes < n=2500. Go figure.

[rogue]

Originally Posted by gd_barnes

Yes, I'm sure quite a few will fall by n=100K. Keep in mind, though, that the k's/bases remaining at n=25K are generally lower weight, sometimes much lower weight, than the ones remaining at n=5K. The percentage of k's/bases found prime for n=25K-100K will be quite a bit less than n=5K-25K. n=25K-100K would also probably take 50-75 times longer to search than n=5K-25K.

Would it be worth someone's time to compute the weight for each k in the single k conjecture thread? that would give users an idea as to how easy/difficult it might be to prove the conjecture.