PRPnet 1st drive-R/S base 2 even-k/even-n/odd-n

[gd_barnes]

Max,

You've royally confused me. I quote you twice:

It was on N before. I'm not sure why it wasn't on A to begin with; since A sorts by decimal length within a file, it's effectively the same as N most of the time, so I usually always use A except where otherwise necessary.

I usually prefer to use sortoption=A instead of N because it allows me more direct control over what order things are handed out in; it's roughly similar to LLRnet's method of handing out pairs as they're encountered in the knpairs file.

You have contradicted yourself. You specifically said that sortoption A hands out in decimal size order and then you go on to imply that it hands out pairs as they are encountered.

So which is sortoption A? Entry (oldest to newest) sequence or decimal value sequence? If its decimal value sequence, N is slightly better. If it's entry sequence, then I agree with you that A is usually better because you have more control.

Edit: I just now checked Jeepford. A is sorted by "oldest candidate" or entry sequence. Now you can see why I got mixed up. The "length sequence" that you were originally talking about is sort sequence "L". Therefore I agree that A is best in most situations for our needs.


Gary

[rogue]

Originally Posted by gd_barnes

You have contradicted yourself. You specifically said that sortoption A hands out in decimal size order and then you go on to imply that it hands out pairs as they are encountered.

So which is sortoption A? Entry (oldest to newest) sequence or decimal value sequence? If its decimal value sequence, N is slightly better. If it's entry sequence, then I agree with you that A is usually better because you have more control.

When using sortoption A (oldest first), decimal length is used as a tie-breaker. Since the server is loaded using ABC files and since the ABC files have the shortest candidates (presuming the file wasn't edited by hand), this allows one to clear out older bases before newer bases and to clear out the older bases by decimal length.

With PRPNet 4.0.0, which is nearing a release as I write this, you will have more control over sorting. It will allow you to specify multiple sort options (always ascending) instead of one. That will eliminate some of the confusion caused by sortoption A and L.

[mdettweiler]

I have now processed port 1300's completed results for S26, n=250K-300K. No primes were found; the results are attached here. The base is now released.

[gd_barnes]

Hum. It seems that Mathew has found a R31 top-5000 prime!

Leave it to a heavy weight base not in the twenties to finally score one. The bases in the twenties have been dormant for an eternety including the 10 k's for both sides of base 28, which have been completely dormant for n=105K-190K and have had only one prime for n=66K-190K.

[Mathew]

Originally Posted by MyDogBuster

If we're looking for stuff to do, I'd like to get all the bases < 250 up to at least n=100K, excluding the high ck ones with loads of k's left. Put the cutoff point at something like 20k's remaining. Sieve them, load them and let 'er rip.

Any preference Mathew?

MyDogBuster, I like the idea.
Gary, is this a possibility?

[gd_barnes]

Originally Posted by Mathew Steine

MyDogBuster, I like the idea.
Gary, is this a possibility?

This drive was more intended for high-n searches. My original thought was one or both sides of base 16 but we really need to push R26 to n=500K and/or R31 to n=200K or 250K to bring them more in line with their neighbors that have similar #'s of k's remaining. R26 is fully sieved to optimal depth to n=500K. R31 would need sieving for n=150K-250K.

Also, Mark had suggested sieving all bases < 250 with one k remaining to see how many we can prove. We would probably do that for n=100K-250K.

I think we are going to need to take a poll because we have 3 distinct thoughts about what to do next for a team drive. I'm thinking we should keep this mini-drive intact and continue with high-n searches but we could have a 2nd drive going based on what Ian or Mark suggested.

A 4th possibility is to bring lowish bases with "kind of" a large # of k's remaining (perhaps 25-100 k's) to n=50K or 100K such as base 24. I think you had suggested that before.


Gary

[MyDogBuster]

This drive was more intended for high-n searches. My original thought was one or both sides of base 16 but we really need to push R26 to n=500K and/or R31 to n=200K or 250K to bring them more in line with their neighbors that have similar #'s of k's remaining. R26 is fully sieved to optimal depth to n=500K. R31 would need sieving for n=150K-250K.

Also, Mark had suggested sieving all bases < 250 with one k remaining to see how many we can prove. We would probably do that for n=100K-250K.

I think we are going to need to take a poll because we have 3 distinct thoughts about what to do next for a team drive. I'm thinking we should keep this mini-drive intact and continue with high-n searches but we could have a 2nd drive going based on what Ian or Mark suggested.

A 4th possibility is to bring lowish bases with "kind of" a large # of k's remaining (perhaps 25-100 k's) to n=50K or 100K such as base 24. I think you had suggested that before.

I would be in favor of any drive that is working on getting bases to n=100K. I already have 5 cores (not including the 5 I have on R31) doing high-n searches and that is plenty for me. So I guess 1 drive for the high-n searches and 1 for the < n=100K searches. Everyone's covered.

It's also sad that that CUDA sieve doesn't handle bases other than 2. We could use a faster sieve for this stuff.

[gd_barnes]

Would you guys be OK with extending Riesel base 31 to n=200K or 250K in this drive? As a higher-weight base, it has a good chance to attrition like R6 and get down to just 2-3 k's remaining at n=250K. I just started a sieve for n=150K-250K and could be done before the server here dries.

I'd like to leave this drive/server for various high-n searches on low bases, which would generally include those shown in the recommended thread. We can take a poll on the other 3 possibilities talked about earlier, which I'll set up on Mon. or Tues. if that sounds OK with you. We'll then start a sieving drive for it and set up another PRPnet drive/server for it.


Gary

[MyDogBuster]

Would you guys be OK with extending Riesel base 31 to n=200K or 250K in this drive?

Like I said earlier, 5 cores doing high n tests is enough for me. I'll find something else for the 5 cores on R31 to do.

[mdettweiler]

Originally Posted by gd_barnes

Would you guys be OK with extending Riesel base 31 to n=200K or 250K in this drive? As a higher-weight base, it has a good chance to attrition like R6 and get down to just 2-3 k's remaining at n=250K. I just started a sieve for n=150K-250K and could be done before the server here dries.

I'd like to leave this drive/server for various high-n searches on low bases, which would generally include those shown in the recommended thread. We can take a poll on the other 3 possibilities talked about earlier, which I'll set up on Mon. or Tues. if that sounds OK with you. We'll then start a sieving drive for it and set up another PRPnet drive/server for it.


Gary

Since we're planning to set up another server for the lower stuff anyway (the exact load being determined by the outcome of the poll), and will thus be keeping port 1300 on high-n stuff, we may as well keep cranking away with R31 since it's so ripe for more primes. (Besides, the numeric coincidence of R31/1300 is just too good to pass up. )

Actually, what might be a good idea is to set up two additional servers, for a total of 3. Namely:
port 1100 for 1-k bases <250, n>=100K (Mark's idea)
port 1200 for bases <250 with low(ish) CK, n>=25K (Ian's idea)
port 1300 for high-n, close-to-proof conjectures (like R31)

This would give us some nice variety, at the risk of spreading ourselves a little thin.

[gd_barnes]

Originally Posted by mdettweiler

Since we're planning to set up another server for the lower stuff anyway (the exact load being determined by the outcome of the poll), and will thus be keeping port 1300 on high-n stuff, we may as well keep cranking away with R31 since it's so ripe for more primes. (Besides, the numeric coincidence of R31/1300 is just too good to pass up. )

Actually, what might be a good idea is to set up two additional servers, for a total of 3. Namely:
port 1100 for 1-k bases <250, n>=100K (Mark's idea)
port 1200 for bases <250 with low(ish) CK, n>=25K (Ian's idea)
port 1300 for high-n, close-to-proof conjectures (like R31)

This would give us some nice variety, at the risk of spreading ourselves a little thin.

Not a bad idea but whew; a LOT to administer and yes, it would spread us thin; not only on resources but on admins too! We have so many drives already. I simply do not want to adminster any more.

There's really a 50-50 split on what the decision for all of this should come down to:
1. What people want to do.
2. What the admins have time to administer.

Ian, since you're now an admin, would you be willing to set up and run a sieving drive for your idea of bases <=250 with ~2k-20k remaining to n=100K?

Max, would you be willing to admin Mark's idea by getting a sieving drive going for it?

I will continue administering this drive (although asking Max to load the server from time to time) and sieve necessary high n bases like I'm doing right now on R31. BTW, n=150K-250K for R31 should be done sieving in ~3 days. I'm estimating Thurs. or early Fri. on 5 cores of my I7 running to the optimum depth in the P=~12T area. I hope that will beat the drying of port 1300.

Both of you would need to commit to keeping the additional drives going. There will be optimal sieve depth calculations involved, which will be very important to get correct on the high n's involved in Mark's idea.

Are you guys up for it? If so, we don't need to take a poll.


Gary