It was once thought that a false positive report "couldn't happen". So what went wrong?
So far I've come up with two possibilities.
1) The FFT data is zeroed AND does not go into the -2,2,2,2 loop. I don't know how the data gets zeroed, but I've seen it happen. It has happened a lot less often once code was added to reject any save file with all zero data. The not going into the -2,2,2,2 loop can happen with the corruption of a single local variable. I've just added code that makes sure this local variable is always in the range 0 <= variable < exponent.
2) This case results from the way my C compiler treats floating point NaN. NaN stands for not a number. If NaN is converted to an integer, the integer is zero. So if the FFT data is all NaNs, prime95 will report a prime. Prime95 check for NaNs every iteration, but if every FFT data value becomes NaN after the inverse FFT of the last LL iteration, then we get a false positive. Furthermore, corrupting a single value (the initial carry input to rounding and carry propogation code) could set every FFT data value to NaN. I've fixed the code to make sure there are no NaNs in the final is-it-a-prime check.
Which of the above is more likely? I don't know. It seems the first requires two or more pieces of memory corrupted, but it leads to a steady state. So the errors can occur at any point during the LL test. The second case requires only one failure, but at a very specific point in time.
_________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
