[QUOTE=Andi47;292089]
Hmmm... Maybe it would be an idea to save (and keep) interim residue (e.g.) every 5M iterations (and additionally 10k iterations before finishing) and then automatically report every interim residue to the server in case of a "success"?[/QUOTE](I think this has been discussed before.)

What would be the practical usefulness of the interim residues thus reported to the server?

What could the 10k-before-finish residue (not save file) actually tell us that couldn't be found out some easier way?

[QUOTE=cheesehead;292101]
What would be the practical usefulness of the interim residues thus reported to the server?[/QUOTE]


I would think that you could do a quick check from the last interim residue to see if a error occurred before or after that point.

[QUOTE=science_man_88;292105]I would think that you could do a quick check from the last interim residue to see if a error occurred before or after that point.[/QUOTE]There couldn't be a "quick check" from the last interim residue.

Because it's only the residue, not the [I]save file[/I][sup]*[/sup], one would have to rerun the LL from the beginning in order to get a comparison of residues.

- - -

[sup]*[/sup] I'm presuming here that "residue" refers to only the 16-byte low-order end of an iteration result. If, instead, Andi47 intended "residue" to mean "save file", then we go back to objections about storing extra multimegabyte files that were posed, without satisfactory answers, in previous discussions of this proposal.

[QUOTE=cheesehead;292109]There couldn't be a "quick check" from the last interim residue.

Because it's only the residue, not the [I]save file[/I][sup]*[/sup], one would have to rerun the LL from the beginning in order to get a comparison of residues.

- - -

[sup]*[/sup] I'm presuming here that "residue" refers to only the 16-byte low-order end of an iteration result. If, instead, Andi47 intended "residue" to mean "save file", then we go back to objections about storing extra multimegabyte files that were posed, without satisfactory answers, in previous discussions of this proposal.[/QUOTE]

Hmmm... In fact I intended to mean "savefile". Hence I am not running Prime95 since quite some time, I was not aware that this means multimegabytes of files. The usefulness which I am thinking of would be that it might be easier to track down errors in case of false positives. (Maybe also a few interim residues (which means much less data to store) could be helpful in this case.... How did George know that only the last iteration was zeroed out, and not one of the previous ones? Would zeroing out an iteration halfway through (and thus having zeros all the further iterations) produce a non-zero error code?)

[QUOTE=Andi47;292112]I was not aware that this means multimegabytes of files. [/QUOTE]
For the file size, that's simple; the test works mod N, where N is 2^50M. Therefore such a number will have log2(N) bits, or 50M bits. That's like 6-7 million bytes, or megabytes.

As for how the last iteration can be a false zero George, perhaps what you could do is on the last iteration of any test, keep a copy of the before-last-iter save file (a memcpy or something), do the last iteration on the copy, and if (and only if) it's a zero/prime residue, then redo the last iteration one or more times, perhaps with the next larger FFT. It is a bit time consuming, but since it's only one iteration it'll add a grand total of at most a few milliseconds to the test, hardly a loss at all. Of course, there is no way to see if this would actually catch whatever error is causing these false zeros without having a test case of some sort, but we are all agreed that if the zero-ing happened before the last iteration it would be caught, among other reasons, because the next iteration would be -2,2... .

[QUOTE=Dubslow;292125]As for how the last iteration can be a false zero George, perhaps what you could do is on the last iteration of any test, keep a copy of the before-last-iter save file (a memcpy or something), do the last iteration on the copy, and if (and only if) it's a zero/prime residue, then redo the last iteration one or more times, perhaps with the next larger FFT. [/QUOTE]

Actually this may be the start of a good idea.....

When a new prime is discovered, enter the maybe-we-have-good-news state. Reload the last save file and continue. If we again determine the number is prime, then report it to the server.

I'm not sure if this would have avoided the false positive in this case, but it certainly wouldn't have hurt.

Do you know which version Anonymous used? and which processor? Might be worth to try and redo it since he had no error codes it could be reproducable?

I would be willing to do it, though not very likely I have the same processor, got a pentium4 prescott, core2 conroe and corei7 sandy bridge.

[QUOTE=Prime95;292155]Actually this may be the start of a good idea.....

When a new prime is discovered, enter the maybe-we-have-good-news state. Reload the last save file and continue. If we again determine the number is prime, then report it to the server.

I'm not sure if this would have avoided the false positive in this case, but it certainly wouldn't have hurt.[/QUOTE]

Ahem... [url]http://www.mersenneforum.org/showthread.php?t=16074#8[/url]

[QUOTE=axn;292157]Ahem... [url]http://www.mersenneforum.org/showthread.php?t=16074#8[/url][/QUOTE]

Touché. I must have missed that (or not appreciated it) the first time around!

While you would be at it, you may want to add the output of a few last RES64 values to the results.txt. The usual question people ask is if the penultimate iteration value was + or -[TEX]\sqrt 2 (mod M) [\eq \pm 2^{(p+1)/2} ][/TEX] -- there will be an answer for free.

Ze math:
[SPOILER]The next to last iteration can be only one of two values, the square of each equals 2. It is easy to see that they are sqrt2=2[SUP](p+1)/2[/SUP] or Mp-sqrt2. Hint: square them and subtract 2; the result will be 0. Their RES64 will be 0000000000000000 or FFFFFFFFFFFFFFFF. The second next to last could be one of four values, etc.[/SPOILER]

[QUOTE=Batalov;292160]While you would be at it, you may want to add the output of a few last RES64 values to the results.txt. The usual question people ask is if the penultimate iteration value was + or -[TEX]\sqrt 2 (mod M) [\eq \pm 2^{(p+1)/2} ][/TEX] -- there will be an answer for free.[/QUOTE]

I like that too. (The printing RES part -- I don't really understand what you're saying with the math part.) BTW, what's your ETA? Should be around ~10-12 hrs?