Bases 33-100 reservations/statuses/primes

[VBCurtis]

I'll have a look at my results files and see what I neglected to send you. This is almost certainly a human error- that is, I expect I simply missed one of the directories where I did R66 work when I sent you the results & primes.
This is my finals week, but I expect to have time to track down the other primes Wed or Thur.
My apologies for the mistake!

[gd_barnes]

Sorry to hear all of that. With that many tests missing it looks like you will need to re-estimate the time required for the entire base. There could more n-ranges missing for n>11K. There is no way to know without sorting the entire file by n.

I did a small doublecheck here. Your file had 8 primes for n=10649, which seemed normal, but only 1 prime for n=10650, which seemed unusual. I figured something might be amiss for n=10650 since it is right on the edge of the testing n-range.

Therefore I ran a quick sieve and test for n=10649-10650. Results:

1. n=10649 is correct. I found the same 8 primes that you found.

2. n=10650 is missing 7 primes. I found 8 total primes including the very first one that you found. Here are the primes that I found:
12970862*66^10650-1 <--- You found only this one.
37957040*66^10650-1
42214622*66^10650-1
43678119*66^10650-1
57590812*66^10650-1
59428597*66^10650-1
71703670*66^10650-1
81877282*66^10650-1

Clearly the sieve file got cut off somewhere between k=12970862 and k=37957040 at n=10650.

For all of the other n-ranges that you ran, all n's on the edge of the testing ranges appeared to have a normal number of primes so I didn't feel a need to check those.

So you will need to rerun the following n-ranges:
1. 10001-10299
2. 10650-10799
3. 10839-11000

With only 39% of the n-range tested for n=10K-11K. It might be safer to start over.

[VBCurtis]

Originally Posted by gd_barnes

2. n=10650 is missing 7 primes. I found 8 total primes including the very first one that you found. Here are the primes that I found:
12970862*66^10650-1 <--- You found only this one.
37957040*66^10650-1
42214622*66^10650-1
43678119*66^10650-1
57590812*66^10650-1
59428597*66^10650-1
71703670*66^10650-1
81877282*66^10650-1

Clearly the sieve file got cut off somewhere between k=12970862 and k=37957040 at n=10650.

For all of the other n-ranges that you ran, all n's on the edge of the testing ranges appeared to have a normal number of primes so I didn't feel a need to check those.

So you will need to rerun the following n-ranges:
1. 10001-10299
2. 10650-10799
3. 10839-11000

With only 39% of the n-range tested for n=10K-11K. It might be safer to start over.

I certainly split the sieve file at 10,300, and neglected to send him the primes/results for 10000-10300. Like I said, I'll get to it in a day or two. 10650 is obviously another split; some of the 10650 candidates may have been in both files (I do that sometimes as a sanity check, as seeing the same results at the end of one file and the start of another indicates the first file fully finished).
I only worked up to 11000, so anything after that is Rogue's work and surely fine.
In hindsight, I wish i'd split the file by k rather than by n when I made multiple folders. That's clearly easier to organize.

[rogue]

Originally Posted by gd_barnes

Sorry to hear all of that. With that many tests missing it looks like you will need to re-estimate the time required for the entire base. There could more n-ranges missing for n>11K. There is no way to know without sorting the entire file by n

I don't expect any issues with my testing as I am fulling testing each k by ascending n, not by ascending n across all k. This is one of the nice features of srsieve2 (option -fP switch). I am not testing any k that had a prime for n < 11000. Since I am only testing n > 11000, it is more likely that I am searching k that have a prime for a smaller n.

I do agree that all remaining k will need to be retested between n=10000 and n=11000. If anything, any new primes in that range will save reduce the time I need to test the remaining k.

[gd_barnes]

Originally Posted by rogue

I don't expect any issues with my testing as I am fulling testing each k by ascending n, not by ascending n across all k. This is one of the nice features of srsieve2 (option -fP switch). I am not testing any k that had a prime for n < 11000. Since I am only testing n > 11000, it is more likely that I am searching k that have a prime for a smaller n.

I do agree that all remaining k will need to be retested between n=10000 and n=11000. If anything, any new primes in that range will save reduce the time I need to test the remaining k.

My point is if you're testing by k instead of n it won't be immediately obvious if there is missing n for each specific k.

Something that I should bring up about efficiency when using a PRPnet server. It is quite a bit less efficient to test by k-value instead of n-value. The reason being is if a prime is found there will be many other tests above the primed n for that k that are still being tested concurrently by the other cores. It could even be 10s or even > 100 additional tests depending on how many tests are being handed out at one time to each instance/core before those tests are all returned. (Of course when they are all returned then it jumps to the next k but it's frequently a lot of additional tests.)

When using a PRPnet server I personally retrieve 10-25 tests at a time for each instance for searches in the n=10K-25K range meaning that several 100 tests are being done at once. If Ian and I searched the range by k potentially 300-400 additional tests could be done for each primed k vs. at most 5-10 additional tests when searched by n-value.

For R66 you could end up testing a very large number of k/n pairs that are not necessary. Consider searching by n-value instead of k-value if using PRPnet. That advice stands whether testing 2 k's or 100,000 k's. Just my two cents.

[rogue]

Originally Posted by gd_barnes

My point is if you're testing by k instead of n it won't be immediately obvious if there is missing n for each specific k.

Something that I should bring up about efficiency when using a PRPnet server. It is quite a bit less efficient to test by k-value instead of n-value. The reason being is if a prime is found there will be many other tests above the primed n for that k that are still being tested concurrently by the other cores. It could even be 10s or even > 100 additional tests depending on how many tests are being handed out at one time to each instance/core before those tests are all returned. (Of course when they are all returned then it jumps to the next k but it's frequently a lot of additional tests.)

When using a PRPnet server I personally retrieve 10-25 tests at a time for each instance for searches in the n=10K-25K range meaning that several 100 tests are being done at once. If Ian and I searched the range by k potentially 300-400 additional tests could be done for each primed k vs. at most 5-10 additional tests when searched by n-value.

For R66 you could end up testing a very large number of k/n pairs that are not necessary. Consider searching by n-value instead of k-value if using PRPnet. That advice stands whether testing 2 k's or 100,000 k's. Just my two cents.

Because these tests are fairly quick, I am not using PRPNet. There is a setting in the PRPNet server to only allow one distinct client per k.

I'm not certain what you mean by "missing n for each specific k". Please elaborate.

[gd_barnes]

Originally Posted by rogue

Because these tests are fairly quick, I am not using PRPNet. There is a setting in the PRPNet server to only allow one distinct client per k.

I'm not certain what you mean by "missing n for each specific k". Please elaborate.

OK that would work well with PRPnet. I was not aware of that option. Perhaps it was added after the version of PRPnet that I use. I will have to check. I'm happy to hear that you're not using PRPnet in the way that I had imagined.

Since the n=10K-11K sieve file(s) had missing n then I was surmising that the n=11K-25K sieve file could also have missing n. I was pointing out that those missing n would not easily be noticed in the n=11K-25K file if it is sorted by k like what happened with n=10K-11K.

I don't know the status of how Curtis sent those files to you. As Curtis says he will check his files within a few days. I assume that you guys will get it figured out.

[VBCurtis]

Attached is the primes list from 10000 to 10299.

I'm a little disappointed to be blamed as if I never did the work here; when I emailed my results files to rogue, I asked him to let me know if anything was missing. I never heard back, until this forum exchange.

When I emailed my work, I sent results files and the sieve I used, as I felt those were of more use than just primes lists. Obviously, my results files were not complete, so I now attach primes lists while I figure out where the "missing" results are.

You both seem to want to redo all my work, as if I am MIA and not reading/responding to the thread. If you're going to redo the work anyway, I suppose I don't need to bother locating the rest of the files?

[gd_barnes]

Originally Posted by VBCurtis

Attached is the primes list from 10000 to 10299.

I'm a little disappointed to be blamed as if I never did the work here; when I emailed my results files to rogue, I asked him to let me know if anything was missing. I never heard back, until this forum exchange.

When I emailed my work, I sent results files and the sieve I used, as I felt those were of more use than just primes lists. Obviously, my results files were not complete, so I now attach primes lists while I figure out where the "missing" results are.

You both seem to want to redo all my work, as if I am MIA and not reading/responding to the thread. If you're going to redo the work anyway, I suppose I don't need to bother locating the rest of the files?

My apologies. It was not clear to me that you actually tested all of n=10K-11K but had just failed to send part of the primes/sieve files. I had thought that you had only provided Mark an incomplete sieve file and that he had done all of the testing for n=10K-11K using that incomplete file.

If you're confident you have all of the primes files for n=10K-11K then certainly repost them. No re-running would be needed.

My rough estimate says there should be 5300-5500 primes in that range.

Hopefully that clears things up.

[rogue]

Originally Posted by VBCurtis

Attached is the primes list from 10000 to 10299.

I'm a little disappointed to be blamed as if I never did the work here; when I emailed my results files to rogue, I asked him to let me know if anything was missing. I never heard back, until this forum exchange.

When I emailed my work, I sent results files and the sieve I used, as I felt those were of more use than just primes lists. Obviously, my results files were not complete, so I now attach primes lists while I figure out where the "missing" results are.

You both seem to want to redo all my work, as if I am MIA and not reading/responding to the thread. If you're going to redo the work anyway, I suppose I don't need to bother locating the rest of the files?

I had assumed that what you supplied to me was complete. I just did primality tests on the numbers.

I was only concerned about having to resieving all n between 10000 and 11000. I was not concerned about the ABCD file that you sent to me.

Apparently you already removed k with primes from the ABCD file that you sent, so everything it good on my end. Thank you!

[VBCurtis]

My last final is tonight, and then a day of grading, so I expect to have time Friday to organize all the results files and email them to both Gary and Rogue. The results text files are a couple hundred MB, so there will be some labor in zip-and-divide for email; something like 90MB zipped, I think.

I'll try to locate the primes-lists first, since those are easy to send and likely are just lying around like the 10000-10299 file was.