Brian Beesley wrote: > On 3 Dec 2001, at 20:38, [EMAIL PROTECTED] wrote: [... snip ...] > > I think our record shows that a verified factor is still > > slightly (by a minute but nonzero margin) more reliable an > > indicator of compositeness than two matching nonzero LL > > residues. > > AFAIK our record does _not_ show any such thing.
Oh? It doesn't? If our record does _not_ show that a verified factor is more reliable an indicator than DC LLs, then what does it show as the (higher, according to this hypothesis) error rate for verified factors? Is the observed error rate in reported factors as great as the ~1-1.5% error rate in reported LL results? How often does double-checking a reported factor find that the reported factor was in error? > In _theory_ there is a very small chance that we _may_ have accepted > an incorrect residual even after double-checking. There is a small > chance in such a case that the residual should have been zero, i.e. > we missed a Mersenne prime. ... and my contention is that those small chances, for L-L results, exceed the corresponding probabilities in the case of a reported factor. There is a small chance that we may accept an incorrect factor even after double-checking it, but that chance is even smaller than the small chance that we may accept an incorrect double-checked L-L residual. > I've triple-checked thousands of small exponents - some of the > ones where the accepted residual was recorded to only 16 bits or > less, which makes the chance of an undetected error _much_ > greater (though still quite small) - so far no substantive errors in > the database have come to light. A very few (think fingers of one > hand) instances of incorrectly matched residuals have come to light - How does that compare to the observed rate of incorrect factors discovered after triple-checking _them_? > > Some error sources would be more likely to affect the longer LL > > test than the shorter factor verification.) > > Indeed - if errors occur at random intervals, results should get > less reliable as runs take progressively longer. ... and L-L verification runs take a lot longer than factor verification runs, so we can reasonably expect that this class of error will affect L-L verification runs (and thus lower such runs' reliability) a lot more than they do factor verification runs, all else being equal (such as use of the same hardware systems). > However there does seem to be a wide variation in the reliability > of systems. Some seem to have a lot of problems, some very few > (if any). So, while a factor verification run on a system that has a lot of problems may be less reliable than an L-L verification run on a system that has very few or no problems, if we were to compare L-L verification and factor verification runs on the same system or on systems of equal problem probability, we would expect to find that errors whose rates were proportional to time would affect the L-L verification runs more than the factor verification runs because of the significant difference in average run times between the two categories, making the L-L verification runs less reliable than the factor verification runs. Agreed? > I've detected four problems on my own systems so far; two of these > were caused by a failed cooling fan on a P100 system (unlike > current systems, the cooling was _almost_ sufficient even without > forced ventilation); one was caused by a configuration error - > running Glucas on an Alpha system I inadvertently allowed "fast" > arithmetic and turned off error checking, which was a really stupid > thing to do on a system with a 53-bit mantissa FPU - as this was a > QA run on a 33 million range exponent, I was lucky to lose only 3 > months work. The last one I never got to the bottom of, but I > strongly suspect that Prime95's workspace memory was clobbered > during a software installation on a Windows 98 system. How many of those problems caused errors during L-L verifications, and how many caused errors during factor verifications? However, you may not have spent anywhere near as much time doing factor verifications as you have doing L-L verifications, so it may not be valid to draw any conclusion about comparative error rates on your system. Richard B. Woods _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
