Error 11
 

[code]39509597 69 0xF48D225982FE05__ 23-Jan-08 03:49 adamsutton ADMIN-PC[/code]I tried to check my status in the PrimeNet Account Report and noticed that the number for my second core wasn't listed there. So I tried to have Prime95 update the status, and it gave me an Error 11: Exponent already tested.
Sure enough, I just checked the list of recently cleared numbers and it's listed (as being done 03:49 this morning...it's 23:26 now), completed by "adamsutton ADMIN-PC". Given the size of the number, I assume it expired and was reassigned to me, but the person was still actually running the number. Will I still get credit once I finish? If not automatically, will I have to e-mail George something to get the credit? Will it be accepted as a double-checked number, either automatically or manually, so that a third LL isn't needlessly done on it?
Should I even continue running it? It's currently at ~26% and it should take ~30 more days.

You have generated interest in this exponent already,
because you are testing it with a 2048K FFT, and (unsurprisingly)
encountered a roundoff "error". I would say that this makes
doublechecking it valuable (and I am sure George Woltmann can ensure you
receive due credit).
My vote is soldier on with it!

David

[quote=davieddy;123767]You have generated interest in this exponent already,
because you are testing it with a 2048K FFT, and (unsurprisingly)
encountered a roundoff "error". I would say that this makes
doublechecking it valuable (and I am sure George Woltmann can ensure you
receive due credit).
My vote is soldier on with it!

David[/quote]
Hmm...yes, it is a very strange number.
For people new to this number, here's basically its history in a nutshell: it's just past the 2048K-2560K cutoff, Prime95 ran a self-test and saw it could run at the smaller FFT speed safely. Later in the test, it encountered a round off error. Here's the results.txt of it:[code]Trying 1000 iterations for exponent 39509597 using 2048K FFT.
If average roundoff error is above 0.2425, then a larger FFT will be used.
Final average roundoff error is 0.24118, using 2048K FFT for exponent 39509597.
[Mon Jan 14 01:17:53 2008]
Iteration: 1420185/39509597, ERROR: ROUND OFF (0.40625) > 0.40
Continuing from last save file.
[Mon Jan 14 01:42:17 2008]
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.[/code]I just want to be sure that it will be recognized not only as something to give me credit, but also not have a third LL run on it (unless the residues don't match, obviously).

Sorry about that. The power supply failed on that PC and the test restarted when I replaced it recently.

I just looked at the results and see the same "round off error/disregard last error".

I would also vote to soldier on with it. Like it says, disregard the error. Results with only that sort of error have about the same error rate as results with no errors at all.

[quote=AES;123821]Sorry about that. The power supply failed on that PC and the test restarted when I replaced it recently.

I just looked at the results and see the same "round off error/disregard last error".[/quote]
What are the odds that the one to finish it before me would be a forum member? (not asking that literally, but if someone wants to try, go ahead)
Did you run it at 2048K or 2560K?
I know that normal DCs are run with a different starting point to safeguard against programming errors. These two are run with the same starting point, since they were both run as first-time LLs and both had a rounding error/disregard during it. I wonder if it's possible the residues will match, but both be incorrect due to a programming error? Should a DC be run at 2560K to make sure there wasn't an error?
What if it's prime, and it goes unnoticed for years, because it was simply accepted that GIMPS output is correct?

[QUOTE=Mini-Geek;123826]What are the odds that the one to finish it before me would be a forum member?[/QUOTE]Not as long as the odds that the two tests started with the same random shift, I bet. Unless the roundoff-error/disregard happened at the same iteration...:alien:

All tests get the random shift treatment, not just double-checks. In the example in prime95's readme.txt, the 1414032 is (or comes from) the left-shift: [CODE]M1992031 is not prime. Res64: 6549369F4962ADE0. WV1: B253EF24,1414032,00000000[/CODE]

[quote=Mini-Geek;123826]What are the odds that the one to finish it before me would be a forum member? (not asking that literally, but if someone wants to try, go ahead)
Did you run it at 2048K or 2560K?
I know that normal DCs are run with a different starting point to safeguard against programming errors. These two are run with the same starting point, since they were both run as first-time LLs and both had a rounding error/disregard during it. I wonder if it's possible the residues will match, but both be incorrect due to a programming error? Should a DC be run at 2560K to make sure there wasn't an error?
What if it's prime, and it goes unnoticed for years, because it was simply accepted that GIMPS output is correct?[/quote]
I think the chances that the user's a forum member are 100% in this case--the user, "adamsutton", participates in this forum as "AES", as far as I know. :smile:

[quote=Anonymous;123940]I think the chances that the user's a forum member are 100% in this case--the user, "adamsutton", participates in this forum as "AES", as far as I know. :smile:[/quote]
I think he had worked this one out.

[quote=davieddy;123960]I think he had worked this one out.[/quote]
What do you mean by that?

[quote=Anonymous;123965]What do you mean by that?[/quote]
I thought Minigeek had understood the point.
What the **** else could I mean?