Re: Mersenne: Double-checking (was Chronons)

1999-03-07 Thread Ken Kriesel

At 11:59 AM 1999/03/05 GMT, "Brian J Beesley" [EMAIL PROTECTED] wrote:
 (Ken wrote)
 Right.  The odds heavily favor both mismatched residues being nonzero.
 A zero residue at the last iteration is what indicates primality.

Depends on what you mean. If a Mersenne number that has been 
tested once really is prime, but the test "went wrong", then we 
have a wrong result i.e. calling the number composite when it isn't.

I mean that nearly all mersenne numbers are nonprime even if the exponents 
are prime, so of the numbers we bother to LLtest, when an error occurs, 
the odds are 99%+ that it does not conceal an actual Mersenne prime.
And in the unusal case of a nonprime Mersenne number being erroneously
identified as prime, it would be multiply-checked and so the error caught,
rather than being announced as a prime.

This is why double-checking is so important, if we want to find *all* 
the Mersenne primes for exponents up to a given limit.

I agree that double checking is important in an exhaustive search,
and that exhaustive search (rather than haphazard or opportunistic search)
is valuable.

There *might* be one or two lurking somewhere in the mass of 
exponents which have only been tested once.
 
 Also what causes the errors, bugs in the code? 
 
 What I've seen most often is that prime95 and its relatives provide
 early warning of unreliable hardware, whether cpu, RAM module, or
motherboard.

Usually caused by overheating - failed CPU fan, poor ventilation or 
excessively hot environment, overclocking, poor thermal contact 
between processor substrate and heatsink ... 

The sorts of things I've seen include, in systems with good cpu heat sinking,
multiple case fans, cpu fans properly installed and no overclocking:
mechanically ill-fitting case causing a system to be unreliable
unreliable single SIMM out of a set of 4
unreliable CPU chip
unreliable motherboard

whether these component-level problems were due to electrical stress
(power outages, spikes, brownouts, static), thermal stress (overheating 
or too-frequent power on/off), or latent defects in manufacture is unknown.


Ken

Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm



Mersenne: Double-checking (was Chronons)

1999-02-28 Thread George Woltman

Hi,

At 07:35 PM 2/26/99 -0800, Spike Jones wrote:
How about sweetening the pot for anyone who is doing double checking
that discovers a mistake in the first LL analysis?  How does this work?
The first LL test returns a residual, then the double checking
routine takes that residual and...  what?  How often is a result
overturned by double checking? 

From your point of view a double-check is just like a first time test.
You run a Lucas-Lehmer test and when done send in your 64-bit residue.
I compare that residue to the first run and if they match, the exponent
is declared double-checked.  If they don't match, a third test is run
to properly double-check the number.

Finding an error in the first LL test is not rare.  I've said about 1 in
200 are incorrect.  When the entire 1,400,000 - 2,000,000 range has 
been double-checked I'll perform some more rigorous analysis of the
reliability of first-time LL results.

Best regards,
George 


Unsubscribe  list info -- http://www.scruz.net/~luke/signup.htm