On Wednesday 25 October 2006 15:36, david eddy wrote: > > On Tuesday 24 October 2006 19:18, david eddy wrote: > > > what happens when a LL test is proved wrong? > > Brian Beesley wrote: > > Hmm ... the LL test is never wrong, it is a mathematical theorem! > > > > However computations performed in a computer can (and sometimes do) go > > wrong, for a number of reasons. > > The important reason a LL-test goes wrong is due to > using floating point FFT to perform exact integer arithmetic.
Certainly this is an important reason - and it's the one which we _can_ target by adjusting cut-off points etc. in the software. > > It is fortunate that double-checking introduces effective certainty > to the result, enabling us to claim to have "proved" that > M13,466,917 is the 39th Mersenne prime. There are still imponderables e.g. the security and the integrity of the database, the possibility of submitting "spoofed" results and getting them past the built-in checks in the server, etc. - I'm of the opinion that we're in reasonable shape but we cannot simply take this for granted. > > As I am currently doing a double check I am interested in how the > probability of an erroneous LL test varies as we go from the bottom > to the top of the range of exponents for a given FFT size. A quick scan of the bad.txt database file shows that there is a significant error rate even at the low end of the exponent range for many of the FFT run lengths. Note that run length cutoffs vary with program & processor version so a proper check would be difficult to impossible. I get the impression that a lot of the errors are "random" i.e. caused by overheating, overclocking, memory mangling by other applications and/or device drivers which don't check bounds properly, components which have gone out of specification due to ageing, even just possibly memory bits being flipped by cosmic ray hits. Note that, if you buy pre-built commercial PCs (as most people do), it is not unknown for manufacturers to cut production prices by using underspecified components i.e. you may be overclocking even if you haven't consciously configured your system that way. I have several examples of systems which were mildly overclocked, worked fine for a year or two (running continuously but always well below critical temperatures) and then started to generate errors. I'm not sure what the ageing process is, but it does definitely happen. I also have numerous examples of errors detected by mprime being correlated with utility (mains) power supply brownouts, spikes etc. For that reason I strongly reccomend systems running mprime / prime95 (or anything else which really matters to you) should be provided with uninterruptible power supplies. Unfortunately these cost money (not just capital - the batteries need replacing every few years) as well as resulting in an increase in total power consumption. > > The probability at the top of the range is presumably such that the cost > in time of an erroneous LL test balances the extra time needed for the > next FFT size, for which the chance of error is small. I think (and hope) the default setup is a bit more conservative than that. There's the unfortunate possibility of someone running a first LL test on an exponent and incorrectly finding it composite due to an avoidable error - we want this to be "reasonably improbable" even though double-checking would eventually find the mistake! Regards Brian Beesley _______________________________________________ Prime mailing list [email protected] http://hogranch.com/mailman/listinfo/prime
