The only entries checked by GW above 15M are

16811549,GW,P4-1600,WZ1,23A0B8EE222146CA,7971791,00000000
20385697,GW,Opteron,WZ1,A9556E8F991E7E42,16700667,00000000

16811549 had three checks:

16811549,blanke,laptop,WZ1,23A0B8EE222146CA,3933317,00000000
16811549,GW,P4-1600,WZ1,23A0B8EE222146CA,7971791,00000000
16811549,gbvalor,,G29,23A0B8EE222146CA,0,

20385697 had only two:

20385697,ewmayer,,E2,A9556E8F991E7E42,,
20385697,GW,Opteron,WZ1,A9556E8F991E7E42,16700667,00000000

George's mail to the mersenne list on 11.6.2003 (DMY) said

[QUOTE]My verification run of M#40 just completed....not prime. Now we wait for
Guillermo Ballester Valor's run to complete in the next few days. Our runs
matched at 13 million iterations.
[/QUOTE]

So it's 16811549. There. It's been said now.

TTn, if you really believe George is keeping primes secret, my recommendation would be to roll your own software and go check. Good luck. (Honestly... :no:)

Alex

[QUOTE]akruppa
TTn, if you really believe George is keeping primes secret, my recommendation would be to roll your own software and go check. Good luck. (Honestly... )[/QUOTE]

That's not a problem, and is precisely why I am asking for the exponent( Honestly :no: )
Where/when did you get these results?


Besides, this would mean George was indeed lying, about the upper 18 million range.

[QUOTE=TTn]Besides, this would mean George was indeed lying, about the upper 18 million range.[/QUOTE]
I'd say the whole thing was just not important enough to remember the exact exponent or range.
Maybe you should think a while about your attitude.

[QUOTE=TTn]
Besides, this would mean George was indeed lying, about the upper 18 million range.[/QUOTE]

I don't think he was lying, he was just not recalling it correctly. And since he actually thinks it's a waste of time to do a quadri-check on the number since there are already 3 matching non-zero residues (even using different soft-/hardware) he didn't took time to look it up.

Btw Xyzzy how is your run progressing :bounce: ?

[QUOTE]I'd say the whole thing was just not important enough to remember the exact exponent or range.[/QUOTE]

That's week! There are only 20, of the million ranges with a half dozen, positive results.
It was a pretty important error, and it is still not known if he has [I]completely[/I] fixed the problem. The error rate seems to be pretty high.

[QUOTE=TTn]It was a pretty important error, and it is still not known if he has [I]completely[/I] fixed the problem. The error rate seems to pretty high.[/QUOTE]

As I recall correctly it was probably just a hardware glitch, which was causing some cyclic sort behavior of the residues, which in the end resulted in a zero residue. After the event there was code added to Prime95 to check for cycling residues. Also new versions keep the last save file if they end up with a zero-residue so it's possible to rerun the last few thousands iterartions. Since the calculations are (almost) impossible to make in the reverse direction it's (almost) impossible to create a fake save file. The other error was from a user using not Prime95 but mlucas on a non supported architecture.

So 2 error both with different software and both have taken measures to prevent similar errors in the future doesn't seem a high error rate to me. A false positive will be quickly identified be a doublecheck, using different software and hardware. A false negative will be eventually identified by the normal double check, since it's statistical almost impossible to have two different errornous runs resulting in the same non-zero residue.

Of course if you are thinking there are still primes hidden in the already searched space you are completely free to search for them using own methods (software) if you like to and I wish you good hunting although I doubt if you find any.

You see this that's the wording that bugs me, " probably a hardware glitch, causing some cyclic sort behavior of the residues" " the end resulted in a zero residue."

Could various hardware glitches also cause, an incorrect residue? Unknown.
If not hardware, then what was causing this behavior?



[QUOTE]After the event there was code added to Prime95 to check for cycling residues. Also new versions keep the last save file if they end up with a zero-residue so it's possible to rerun the last few thousands iterartions. [/QUOTE]

Iv'e seen this code, It doesn't address the main problem,(software to hardware interface) but does seem to work around it. Not saying I can do better yet...

[QUOTE]Since the calculations are (almost) impossible to make in the reverse direction it's (almost) impossible to create a fake save file. [/QUOTE]

Almost huh.

[QUOTE=TTn]
Almost huh.[/QUOTE]
To benefit from a "faked" positive result you will need to subvert either all the programs, so that you can guarantee the verification of your chosen test, or subvert the people that are running the verification runs. Neither is very likely.

As for missing potential Mersenne Primes you and anyone else is free to run any test you like :smile:

PM

I am now past 9M matching with Xyzzy.

UltraWarp engines :nuke: are holding and running strong...

[QUOTE=TTn]BTW
I didn't appreciate searching through all those numbers for nothing, with the find text function. I also double checked with an executable I made.[/QUOTE]


LOL Thank God that there even is a "Find Text" function :P

I have one last question on the topic.
Do you mean zero residue as in the Lucas test?
As I found zero residue(hex)of the false test, which could be crutial in deciphering the cyclic problem.
FFT routines are cyclic, and it is mentioned in the source code that there is a problem especially with the SSE2.

Link concerning the frequency of false positives by LLR.
Hardware error?
[url]http://groups.yahoo.com/group/primeform/message/4340[/url]