On 4 May 00, at 19:58, Nathan Russell wrote:
> The roundoff warnings essentially mean that the multiplication your
> machine is less accurate than the developers thought it ought to be.
Yes, those of us running Mlucas _know_ that there is a problem in
this area, with at least some architectures.
> 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.
Less than that - the critical point in Mlucas 2.7z is 10110000 (cf
10320000 for Prime95). Obviously even this is a bit high for safety.
For the critical points for other FFT run lengths, refer to
ftp://209.133.33.182/pub/mayer/gimps_timings2.html
The reason why Mlucas should be "less accurate" is that the floating-
point hardware is pure IEEE G-float (53-bit mantissa) whereas, whilst
Prime95 stores FP values in memory in the same format, internal
calculations in the FP registers use a proprietary Intel format with
a 64-bit mantissa (plus sign, plus 15-bit exponent, making a length
of 80 bits in total - awkward on modern systems with native 32-bit,
or longer, data bus architecture!)
> 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
Explanation perfect so far ...
> 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.
Hmm. If you get just one bit wrong, in general terms the number of
suspect bits will double with each iteration.
> 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.
If you report a rounding error of x then it means that the absolute
value of the difference between the computed value and the nearest
integer was x. Of course you could be measuring to the wrong integer,
e.g. if you went wrong by 0.7 you would pick the wrong integer &
return the roundoff error as 0.3.
For fairly obvious reasons you _can_ get a roundoff error of exactly
0.5 - but no bigger than that.
Depending on the FFT method used, there may actually be a strong
tendency for computed values of roundoff error to be of the form
k/2^n, where k is a fairly small integer. Now the following
information from Richard Otter's original message is interesting:
>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
There are only two values of roundoff error reported - 0.40625 =
13/2^5 and 0.4375 = 7/2^4. So it looks as though Mlucas has an
algorithm which generates k/2^n roundoff errors. Note that, if there
was a hardware problem, we'd expect to get at least some results not
following the k/2^n pattern.
> Since
> none of your roundoff errors are even near .5, it is reasonable to suppose
> that none are over this value.
I'd prefer to say that _none_ of the "preferred" values 29/2^6, 15/2^5, 31/2^6
are observed. It's unlikely (but not impossible) that we'd get an actual
roundoff >= 0.5 without hitting a value in (0.4375,0.5] at least occasionally.
> 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.
Absolutely.
Regards
Brian Beesley
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
