>From: "Richard J. Otter" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: Mersenne: Round off errors
>Date: Thu, 4 May 2000 09:16:51 -0700
>
>I am running Mlucas_2.7z.ev4 on a Compaq Alpha machine.
>My results file contains-
>
>M 9392629 is not prime. Res64: 376484177C22AB08. Program: E2.7z
>M 5028911 is not prime. Res64: E1C586E5AB9F9CB6. Program: E2.7z
>M 9965533 is not prime. Res64: 6CDEFF74DD4859B2. Program: E2.7z
>M10068757 Roundoff warning on iteration 126683 maxerr = 0.406250000000
>M10068757 Roundoff warning on iteration 1992762 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 2747426 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 3383066 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 3941973 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 6161725 maxerr = 0.406250000000
>M10068757 Roundoff warning on iteration 7988178 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 8877411 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 9634654 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 9803267 maxerr = 0.437500000000
>M10068757 is not prime. Res64: AEED24F91193EE6F. Program: E2.7z
>
>Is it safe to check in the last result?
>Can I expect more of these errors in the future?
>
>Thanks,
>Richard Otter
Well, I'm fairly new here so take everything I have to say with a grain of
salt.
I am going to somewhat 'water down' the language I use in this explanation
for two reasons: I do not fully myself understand such concepts as FFT
runlength, and I do not know how thoroughly you understand them.
The roundoff warnings essentially mean that the multiplication your machine
is less accurate than the developers thought it ought to be. It so happens
that the last number you tested has an exponent that is only a few hundred
thousand below the point at which it would choose to do a more accurate
multiplication.
The roundoff error is simply the distance that the result of the iteration
was from the nearest integer. As long as the nearest integer was the right
one, this is not a problem. However, if it was wrong, your whole result in
faulty. The Lucas-Lehmer test is completely intolerant of error and, in
fact, acts in such a way that the very next iteration after an error will
scramble the next term in the test sequence beyond recognition.
In order to ruin your work, the roundoff error would have to be greater than
.5; however, it will always appear as a value less than .5. Since none of
your roundoff errors are even near .5, it is reasonable to suppose that none
are over this value.
In any event, IMHO you should send the result. The worst thing that will
happen is that you will lose credit for it in a year or two, when someone
running double-checking finds a mismatch and someone else confirms the
problem. In this case, GIMPS will have expended no more effort than if you
did not turn in the result at all.
In case I have been unclear, these errors are in no way due to a hardware
problem with your machine, so there is no need to worry about that.
Best regards,
Nathan Russell
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
