Thread: Double checking
View Single Post
Old 2007-08-21, 03:32   #3
gd_barnes's Avatar
May 2007
Kansas; USA

293D16 Posts


OK, thanks for the info. I know you said you'd follow up with some more details later so if you can please answer this one, it would help.

Originally Posted by Kosmaj View Post
2) As the next step, for n>100k, it will be nice to double check all ranges (intervals) not marked as tested on Keller's page (open the searched intervals link).
OK, I understand what you are saying but have all the ranges that are shown there as tested been double-checked? In other words, are these ranges that have been double-checked or have they only been tested once? If they've only been tested once, we need to double-check the entire ranges of all of the k's. There's no indication that I saw that these are double-checked ranges.

Originally Posted by Kosmaj View Post
5) I cannot say anything about accuracy of "Prime Search" results for k's in the 300-1000 range, and I don't intend to do or coordinate any double search there. k<300 are more than enough for me and my current resources
300 < k < 1000 is where most of the errors will be. I'll be spending a large majority of my time in checking that range because I think there are many missing primes for 16K < n < 50K and that range of n is much faster to search.

In the mean time, I'll start doing a sieve for the ranges that you stated above using speedy sr2sieve. If I don't have the CPU time to LLR it all, at least I'll post some well sieved files here for people to search.

I never overclock any of my machines and to the best of my knowledge, LLR has never reported an erroneous prime on any of them. I'm much in favor of quality over quantity and size. The biggest problem that I've had is with NewPGen and sr2sieve removing primes when P > k*2^n-1 if I'm testing low n, which annoys me greatly. I get around that by using srsieve for any search for n < 10K or by just inserting n's back in the sieve for values of 1 thru 25 before LLRing. Personally, I can't understand why such a small problem can't be fixed by the programmers. I'm a programmer myself, just not a C++, assembler, or web programmer, and I know that the problem can be eliminated with most of the speed left intact. I know the instructions in those programs say that they don't work at those low values of n, but my question right back is why not? It's easy enough to have a separate routine in a program at low values of n. Obviously srsieve does. I know it's much slower, but any program can be written to run one routine for a short period of time and then change to a faster routine for its duration. Or even better...instead of a separate routine, why not a quick 'if' statement in the programs that check to see if P = k*2^n-1? If that condition is true, then n is prime and don't remove it from the sieve. Srsieve even goes so far as to display it as prime on the screen while leaving it in there. I just can't imagine more than a 1% speed hit to have that check in there. I guess I just don't get it. Is it too much to ask for a program that is fast and works virtually 100% of the time? OK, my rant is done now!


Last fiddled with by gd_barnes on 2007-08-21 at 03:54
gd_barnes is online now   Reply With Quote