One other thought: istn't is possible for a malicious user to deliberatly report a false positive?

Of course i don't say this was the case here but should we not consider this possibility for the future?

Re: so what happens now since M40 was bogus?
 

[quote="wfgarnett3"]So what happens next now that we have found that M40 was not prime?[/quote]
There [b]wasn't any[/b] M40. Yet. :)

(M40 would designate the 40th known Mersenne prime, and for a while we thought we'd found it, but now we know that we haven't yet found the 40th Mersenne prime.)

I know this is highly unlikely but is it possible that there was some random error and the zero just happened as a consequence?

[quote="garo"]I know this is highly unlikely but is it possible that there was some random error and the zero just happened as a consequence?[/quote]

I have an article from IBM Systems Journal, talking about softerrors caused by cosmic radiation. They did tests in airplanes and underground, plus looked at the effect of what happens to the hardware when hit by a particle, in regards to the cone shaped damage to the media. Let me see if I can find it:

[url=http://domino.research.ibm.com/tchjr/journalindex.nsf/a3807c5b4823c53f85256561006324be/922f6bbd8495db1485256bfa0067fc4e?OpenDocument]Link to Article Summary[/url]

The universe has a funny sense of humor. Bottom line, if you can test for this error condition some or all the time on the cheap, then you might as well do it.

The fact that you were able to prove that it was a false positive with the same software/hardware base against different code and hardware confirms that it's not the software. Entropy wins. :)

Without the save files, is it even possible to recreate this? I think the idea of saving the last save file when a possible prime is found is a great idea. How about the option of saving more of them, like 5 instead of 2, or is it a overkill because of the independent verification of all possibles?

http://arstechnica.infopop.net/OpenTopic/page?q=Y&a=tpc&s=50009562&f=77909774&m=9090973925&p=1

(* In small apologetic voice *) Okay, trif, I am truly humbled by the effect my faux pas has had. Never again will I bracket an unsound claim of correctness of a personal assertion between dancing bananas -- it just ain't nacheral.

[quote="garo"]I know this is highly unlikely but is it possible that there was some random error and the zero just happened as a consequence?[/quote]

And even more unlikely, was the right exponent double checked? It's easy to make a typo when you're so exited ;)

[b]George:[/b]

May I for one please thank you heartily for your approach to openness in this whole little debacle, as well as for the project as a whole. As you said, not all DC projects have this aspect, and even though it has turned out not to be M40 this time, I really enjoyed the frisson of excitement when the returned result in question was spotted and the subsequent rollercoaster ride and suspense through the checking processes.

Thanks again for your responsive involvement with us, the users.

There is a thread called "M40, what went wrong?" but I would have named it "M40, what went right?" because the level of communication and involvement offered to us is plain exciting! Plus, we are taking the lessons learned from this and using them to fix the problem...

It ain't a mistake unless it happens twice... When it happens once it is a learning experience... :)

With most every other project I have ever worked with I have felt like a mushroom... Kept in the dark and fed crap! :shock: :D

Not so with GIMPS!

Re: M40, what went wrong?
 

[quote="Prime95"]Every iteration prime95 sums all the input FFT values and all the output FFT values. If sum_input^2 != sum_outputs, then you get a SUM(INPUTS) != SUM(OUTPUTS) error. The output sum is also checked for NaN or infinity. If the sum is one of these values, then you get an ILLEGAL SUMOUT error. If carry-propogation & round-off generates NaNs, then that should be picked up on the next LL iteration.[/quote]

Yes, but does the sum(outputs) get done on the FFT outputs PRIOR to rounding and carry propagation? Then, if some multiplier used in the carry step got zeroed, it could zero all the FFT ouptuts without triggering either the above checksum error or a roundoff error, couldn't it?

Re: M40, what went wrong?
 

[quote="ewmayer"]Yes, but does the sum(outputs) get done on the FFT outputs PRIOR to rounding and carry propagation? Then, if some multiplier used in the carry step got zeroed, it could zero all the FFT ouptuts without triggering either the above checksum error or a roundoff error, couldn't it?[/quote]

Yes, it is checked prior to rounding and carry propagation. For the carry step to zero all the FFT data, then ALL the multipliers would have to be zeroed. Actually, as you know, there really are two multipliers to greatly reduce memory consumption. So you'd need to zero only 512 values to zero the entire FFT array.

I'll add a quick check for zeroed FFT data after the rounding and carry propagation step.