- **Riesel Prime Search**
(*https://www.mersenneforum.org/forumdisplay.php?f=59*)

- - **Double checking**
(*https://www.mersenneforum.org/showthread.php?t=9047*)

Double checkingKosmaj,
Can you confirm what k's and ranges have been double-checked on our site? Yesterday, I did a relatively quick sieve and LLR for all k < 1K for n < 25K and did spot checks on about 50 k's and found no errors. I seem to recall reading that there was some effort at some point to check all k < 300 for n < 100K, but that may have been for Proth's and I'm not sure if it was extended up to k=1K. I don't want to turn this into a triple-check effort! :smile: For the most part, I feel confident that the k < 300 site is error-free for known ranges searched. The main thing that I'm looking for in this is to verify almost every prime that was originally posted on the Prime Search site for 300 < k < 1K. Since I've found so many issues when comparing it to the top-5000 site, I'm thinking I'll find issues with primes not in the top-5000. Eventually, I'd like to double-check as much as is humanly possible on our site and will use this new thread to post my progress and what ranges and k's that I have double-checked. Initially, I hope to check up to n=50K but ultimately would like to double-check up to as high as n = 200K...perhaps when computers get a lot faster or I get access to several more machines! :smile: Gary |

This is a short reply to your question. I'll try to elaborate later.
1) All k<300 were double checked by David Broadhurst in 2004 to n=100k. 2) As the next step, for n>100k, it will be nice to double check all ranges (intervals) not marked as tested on [URL="http://www.prothsearch.net/riesel2.html"]Keller's page[/URL] (open the [URL="http://www.prothsearch.net/rranges2.html"]searched interval[/URL]s link). 3) Thomas Ritschel and I began double cheking such intervals of all k's tested in the 4th Drive and we completed all of them except the following: k=109, n=100-350k (k=109 is low-weight) k=203, 100-260k k=205, 100-250k k=215, 110-250k k=217, 100-260k k=257, 130-260k We haven't reported our completed ranges to Keller yet, but we found no missing primes. 4) I'll publish a similar list of k's from the 5th Drive soon, but you can begin your double checking with 6 k's above. Others are welcome to join, but for double-checking please your most stable machine preferably with no over-clocking (or with very conservative OC settings), and with no history of LLR errors of any kind. It will be nice to report your results to W. Keller using your full name. 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 :smile: |

Kosmaj,
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. [quote=Kosmaj;112766] 2) As the next step, for n>100k, it will be nice to double check all ranges (intervals) not marked as tested on [URL="http://www.prothsearch.net/riesel2.html"]Keller's page[/URL] (open the [URL="http://www.prothsearch.net/rranges2.html"]searched interval[/URL]s link). [/quote] 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. [quote=Kosmaj;112766] 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 :smile: [/quote] 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! :smile: Gary |

[QUOTE=gd_barnes;112768]Kosmaj,
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. [/QUOTE] Intervals reported there as tested by people outside of "15k" and RPS were double-checked by us, and in some cases (k>250) by people from "Prime Search". Those reported by us were not double-checked AFAIK. For example, I tested k=77 from k=20k to 1.3M and from 100k it was not double-checked. |

[quote=Kosmaj;112769]Intervals reported there as tested by people outside of "15k" and RPS were double-checked by us, and in some cases (k>250) by people from "Prime Search". Those reported by us were not double-checked AFAIK. For example, I tested k=77 from k=20k to 1.3M and from 100k it was not double-checked.[/quote]
OK, good. Do we have results files from anyone? If not, for certain 'trusted' testers, I'd think it wouldn't be necessary to double-check them. For instance, if you confirmed that your testing was done on a stable non-overclocked machine, I'd say it be a waste of time to double-check it. What are your thoughts on that? And I'm arrogant enough to say that any double-checking by anyone else of my testing would be a waste of time. :grin: :cool: (I just have to not make any errors when posting them to the threads here!) :rolleyes: Mainly it's just that I have stable machines that are not overclocked and I keep my house at no more than 78 degrees F even while I'm away, just for this reason. Thanks for help and info. Gary |

As far as I'm concerned, I am doing most of my tests on overclocked machines, however I am performing regular stability checks on each of these CPUs (once a month 18-24 hours stability test). Additionally after any BSOD, new aplication installed or even simple computer restart I run 2-6 hours torture test and only afterwards continue with LLR. That way I've discovered some time ago that one of MS patches to WinXP caused a lot of BSODs on my system, and eventually I had to reinstall Windows XP.
Separate case is concerned with hardware malfunction: after one of the computer restarts, my C2Q showed some instability under Windows - it turned out that memory died. I re-did 2 weeks of work there and compared all residues. Also when running LLR I slightly overlap ranges to be tested on different machines and afterwards check if the residues match. Bottom line: so far I have not came across any non-matching residue. If someone wishes to double check any of my work I can provide all residues. |

Some double-checking done for 300 < k < 450I'm not going to list them yet until I'm more complete with this effort, but just to show everyone the magnitude of the problem that we have with Prime Search, I've tested the primes on our site that were copied over from Prime Search for 'ONLY' the range of 300 < k < 450 up to 'ONLY' n = 25K. :smile: Obviously this is a very small portion of the effort so far. In addition to this, I tested two k's in the range that had unusually large gaps between their primes up to n = 100K.
In doing this, I have already found 6 missing primes! :surprised 4 were in the range of 16K < n < 25K and 2 more were for 75K < n < 100K on one of the two k's that had an unusually large gap in its primes. I now have a complete list of primes up to n = 25K for all k < 1000 and am in the process of checking it vs. our site now. I'm also LLRing up to n = 50K for further verification later on. I'm pretty sure that 300 < k < 1000 will be our most error-prone range of k so I'm checking it first. Kosmaj, I'm just now starting a sieve on the 6 k's < 300 for the ranges of n that you suggested in your prior post. Gary |

Problems for k=250-1001 to n=25K and some othersI have completed double-checking the entire range of 250 < k <= 1001 for n <= 25K as well as some other misc. double-checks. I found the following problems for k=250-1001.
Missing primes: 315*2^21970-1 321*2^18053-1 325*2^24707-1 373*2^19027-1 673*2^19447-1 859*2^16437-1 859*2^23759-1 Incorrect primes: 431*2^1543-1 should be 431*2^1542-1 651*2^24035-1 should be 651*2^24025-1 Composite that needs to be removed: 945*2^21062-1 (has a factor of 1,106,129) I also noticed 6 k's that had unusually large gaps between their primes for their specific weight. They are k=307, 341, 509, 543, 599, and 737. I tested k=307 and 341 up to n=100K. In doing this, I found 2 more missing primes. Missing primes: 341*2^72814-1 341*2^86418-1 I have also double-checked 14 of the 16 k's that I currently have reserved up to n=150K for primes that were previously found by others. (I didn't double-check any of my own work on my reserved k's.) I found two problems on one of the k's. Missing prime: 16995*2^79110-1 Incorrect prime: 16995*2^81429-1 should be 16995*2^81439-1 When I found missing and incorrect primes, I double-checked my own work, which means that the above primes are now effectively triple-checked! Analysis: There were no missing primes and only one error on primes from the Prime Search site below n=16K but many problems from n=16K to 25K. I saw that the range of n=0 to 16K was never set up as a reserved range on the site. Therefore, I suspect that the primes were previously calculated elsewhere -or- were calculated ahead of time before the site was ever set up and then were copied over there -or- were calculated there but were double or even triple-checked. To be that extremely accurate below n=16K and highly inaccurate from n=16K to 25K is very unusual. What makes it more unusual is that there may be 100 times or more as many primes from n=1 to 16K as there are from 16K to 25K. Status on upcoming double-check work in the next post... Gary |

Upcoming double-check work and add'l. effort doneFirst some additional effort that I didn't mention from my last post. I also effectively triple-checked k=1 to 100 up to n=10K since I tested all k's <= 1001 and checking it took very little time. Of course I found no errors because it had already been double-checked.
Here is my upcoming double-check work in the order that I plan to work on it: 1. Kosmaj, I have completed sieving the entire ranges for all 6 k's that you suggested for k=109, 203, 205, 215, 217, and 257. The sieve was up to the optimum point of P=300G using sr2sieve, which left 32458 candidates to test. I have one core that I can dedicate to LLRing the entire thing starting on Monday or Tuesday. Estimated completion time is about 3 weeks. 2. I am currently LLRing the entire range of k=1 to 1001 from n=25K to 50K. Sieving is done but I've only had one core to dedicate to LLRing it (due to 4 cores on my high-weight LLR) and it is about 20% complete. At the rate that it is going, I'm guessing about 2 weeks to finish the LLR. Then I'll be able to double-check to that level. Since the density of problems from n=16K to 25K was large for Prime Search, I'm guessing a similar rate of problems in this range. 3. Test and check the other 4 k's with unusually large prime gaps for 300 < k < 1001 up to n=100K (that are not already done). That is k=509, 543, 599, and 737. To be done after #2 is complete. Later on, extend the range to n=150K for all 6 k's and then 200K depending on the size of the prime gaps on the individual k's. 4. Test and check primes found by others on 2 of my k's that I haven't already done. That is k=111546435 from n=120K to 200K and k=686701125 from n=60K to 173.3K. With only 2 k's, this is a smaller effort than any of the above so I'll put my very slow borrowed machine on it after it's done doing sieving on twin primes from n=15K to 20K. 5. Lowest priority after all of the above. Triple-check k < 300 up to n=50K since that is being included in all of my sieve and LLR efforts. If Kosmaj prefers, I can attempt to test and check n=100K to 125K for k < 300 but sieve and LLR time at that level is very intensive. It'll probably have to wait until after I'm done with my high-weight k testing from n=200K to 400K. Gary |

Update on double-check workThe LLR for n=25K to 50K has completed the range of k=300 to 750 so far. I went ahead and double-checked the primes found so far in that range vs. the Prime Search primes on our site. I found the following problems:
Missing primes: 367*2^39177-1 407*2^31826-1 497*2^33266-1 619*2^32539-1 619*2^40693-1 675*2^48779-1 Incorrect prime: 665*2^40408-1 should be 665*2^40498-1 Kosmaj, the LLR for k=109, 203, 205, 215, 217, and 257 that you suggested needing double-checked has completed the range of n=100K to 165K for all k's. The below primes were confirmed. No additional primes have been found so far. Estimated time to completion is now a little over 2 weeks on one dedicated core. Confirmed primes: 203 105890 203 115350 205 128019 257 133980 109 141227 217 148089 Interesting info.: Error rate for k=300 to 1001: n=0 to 10K; 1 error out of 7066 primes = 0.01% n=10K to 25K; 9 out of 940 = 0.96% n=25K to 50K so far; 7 out of 451 = 1.55% So the error rate in that range of k continues to increase as the value of n increases. Gary |

[QUOTE=gd_barnes;113362]
Kosmaj, the LLR for k=109, 203, 205, 215, 217, and 257 that you suggested needing double-checked has completed the range of n=100K to 165K for all k's.[/QUOTE] Gary, thanks for running these double checks. Good to hear that so far there are no missing primes! |

All times are UTC. The time now is 11:16. |

Powered by vBulletin® Version 3.8.11

Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.