[QUOTE]This was the number I was reading on the server an hour later of the discovery. Why should Tony (whoever that is) change or give wrong exponents and willingly let people throw away processor time for a bad hunt?[/QUOTE]

We are trying to figure out a reason for the mismatching residues.

[quote=Primeinator;176666]We are trying to figure out a reason for the mismatching residues.[/quote]

If they have willingly changed the exponent (and let the people check out the wrong one) it's very bad and I will be more than annoyed. Such a trickery is unacceptable and I will think about stopping support for the project if such methods are accepted ... :furious:

[quote=Primeinator;176666]We are trying to figure out a reason for the mismatching residues.[/quote]
I believe it's been stated quite clearly several times: Because of differences between Prime95 and its Wdx numbers and Glucas/Mlucas and their Res64 numbers. I'll try to get a few interim residues from each to show this is all that's happening...
I can't find a Glucas/Mlucas build for Windows to compare to, but look at this from Prime95:
[CODE][Mon Jun 08 20:51:12 2009]
M10007 interim Wd1 residue 1F85E47BE0468817 at iteration 10006
M10007 interim Wd1 residue 2CC5456D685892E3 at iteration 10007
UID: ANONYMOUS/test, M10007 is not prime. Res64: 2CC5456D685892E3. Wd1: DB33F63F,695,00000000
[/CODE]So I guess Wd1 really is Res64? Hm...either Wd1 is only equal to Res64 on the final iteration, or something else is causing the difference between the testers.

[QUOTE=Primeinator;176666]We are trying to figure out a reason for the mismatching residues.[/QUOTE]

A couple possible reasons have already been given :juggle: :xmastree:.

mdettweiler implied that all these wdx and res64 residues should be the same regardless of what program is running (prime95, mglucas, etc)

[QUOTE=lycorn;176659]So I assume that either the "wrong" exponent had been sitting on the database since the discovery (due to some server mechanism put in place to hide its identity) or someone changed it during the one hour interval between my post and Kevin´s. That´s possible, of course, but it seems rather fast. So I would say that Kevin got the right exponent, unless the server changed it immediately after the discovery.[/QUOTE]I think that Scott OMP, wrote a Schrödïngër (aka electron split) routine into the new server (but didn't tell George, for fear of being fired).

The server could confirm that there is a new prime without any falsity and continue to do so forever.
But, after the first person, Lycorn, saw the expo, it then automatically randomizes the actual prime,
with other potential expos (based upon the criteria that the observer first used to see the prime).
(This does not apply to George, obliviously, because in this realm he is all powerful.)
Thus, once lycorn saw the prime, via user ID, all other observers were treated to a different via,
with the false 000000 moving to a different potential number. If someone had spotted the prime
via a standard "lastest results" query, that very act of view the results would cause the new
prime to be mixed amongst those results. And the false residue, now applied to the actual
prime expo, is based upon the serial numbers on the currency notes that Scott found on
the [URL="http://www.imdb.com/title/tt0120601/"]side of the New Jersey turnpike[/URL].
[attach]3754[/attach]
I know that this is true, because CMD told me so.
P=9 B=8 D=0 q=6

[code][FONT="Fixedsys"]q p
X
d b[/FONT][/code]

[quote=Primeinator;176674]mdettweiler implied that all these wdx and res64 residues should be the same regardless of what program is running (prime95, mglucas, etc)[/quote]
Okay, maybe I didn't quite clarify one key thing: I'm pretty sure (though don't quote me on it) that if you tell Prime95 to run a test as a [B]doublecheck[/B], rather than a first time test, more often than not its randomly-chosen shift value will result in a completely different compuatational path than a first-pass test (with a predefined shift value) would take. Thus, the interim residuals WILL be different, even though the final ones will be compatible.

Mlucas and Glucas both use the same predefined shift value that Prime95 uses for tests entered as Test= lines instead of Doublecheck=. Thus, in order to get a compatible interim residue from Prime95, you'd need to enter the number as Test=. Even running two separate Doublecheck='s with Prime95 may produce different interim residues, since most likely they will have picked a different random shift value at the beginning of the test.

As I said before, though, don't quote me on this. I could be completely wrong, in which case anyone more knowledgeable about this stuff can feel free to correct me. :smile:

Very interesting, and the logic behind for it makes sense as well. On a side note, just how big is the entire hexadecimal residue (on average) per iteration? I imagine MANY times bigger than the 64 bit residue that Prime95 displays.

assuming that 42643801 is the exponent, it completed p-1 b1=715001 b2=12000000

Primeinator, good to have you back!

If the exponent is 42643801 (just to take a random example), the residue at each iteration is 42643801 bits long, while the 64-bit residue is only the last 64 bits of this quantity. So yes, many times larger.

Max, (mdettweiler), you make an interesting point, as Kevin is actually running his verification as a double-check, and if your theory is right, it would explain any discrepancy between his results and say, those of ATH. On the other hand, it might not explain any discrepancy between the results of ATH and the double-checks being run by Rob (rgiltrap) and Tony.

Lycorn, you wrote that George said in this thread that no mechanism to disguise the exponent in the server reports had been implemented. I didn't see that, I only saw that he said that the server did not send out the expected emails. But on the other hand, look at Tony's stats:
1624000/.38075=4265266
1624000/.38085=4264146
In this range, how many exponents were finished between April 12th and June 4th? Not very many. I would be very suspicious that the fake exponent would be chosen that close to the true exponent.

[QUOTE]Okay, maybe I didn't quite clarify one key thing: I'm pretty sure (though don't quote me on it) that if you tell Prime95 to run a test as a doublecheck, rather than a first time test, more often than not its randomly-chosen shift value will result in a completely different compuatational path than a first-pass test (with a predefined shift value) would take. Thus, the interim residuals WILL be different, even though the final ones will be compatible.[/QUOTE]

Ah, okay. This is clarified now, thank you.

[QUOTE]Primeinator, good to have you back![/QUOTE]

Thanks, it is good to be back!

[QUOTE]If the exponent is 42643801 (just to take a random example), the residue at each iteration is 42643801 bits long, while the 64-bit residue is only the last 64 bits of this quantity. So yes, many times larger.[/QUOTE]

Wow, is there a reason it always matches the exponent for number of bits?

[QUOTE]I would be very suspicious that the fake exponent would be chosen that close to the true exponent. [/QUOTE]

I am too now that the issue of the mismatching residues has potentially been resolved by the check vs. double check fact. The only thing I don't understand is why there was a need to pm the actual exponent.