Hello,
At 09:30 PM 4/1/99 -0800, [EMAIL PROTECTED] wrote:
>Do I need to upgrade if I am only factoring?
No. The bug does not affect factoring or double-checking below 4,194,304.
At 11:47 PM 4/1/99 -0500, Vincent J. Mooney Jr. wrote:
>I am still using Win 3.11 so I am not using Prime 95.
>Is there an error in my software too? The executable is prime.exe
>The range is in the 5,000,000 size.
If you are using version 17 of prime.exe then you are affected.
At 02:51 PM 4/2/99 +0200, Henrik Olsen wrote:
>I hope you didn't do as said in the whatsnew.txt, shouldn't it be
>KEEPING those below 4194304?
>2) Only v17 save files below 4194304 are deleted.
You are correct. I will update the whatsnew.txt file today.
At 02:43 PM 4/2/99 +0200, Hoogendoorn, Sander wrote:
>I'm at 92% off my current exponent, should i upgrade now or waste 2 more
>days to produce a (possible wrong) result?
Upgrade now. Your 92% of work is no good (unless you started testing
the exponent with version 16 - if so, version 18 will not delete your
save file).
At 12:28 PM 4/2/99 +0200, Philip Heede wrote:
>- The Linux MPrime version correctly reports itself as v18.1.2 when run
>as "./mprime -v". But the 'menu-item' Help/About in the configuration
>menu still reports v17.1.2
I will fix this today.
At 12:43 AM 4/2/99 EST, [EMAIL PROTECTED] wrote:
>Can you give us details on this bug and exactly why it starts affecting
>exponents above that 4-mil number?
The bug was in the routine mulmod which was supposed to compute a * b mod c
The implementation was a rather sloppy:
unsigned long tmp;
tmp = a * (b & 0x3FF);
tmp += ((a << 10) % c) * (b >> 10);
return (tmp % c);
You can see in the first computation of tmp there will be an overflow if
a exceeds 2^22 or 4194304. The new implementation is:
double tmp;
unsigned long q;
tmp = (double) a * (double) b;
q = (unsigned long) (tmp / (double) c);
return ((unsigned long) (tmp - (double) q * (double) c));
This implementation isn't perfect, but will work as long as a * b does
not exceed 53 bits.
The old mulmod code was adequate in version 16, but in version 17 I started
calling it with the "a" value being the shifted bit number (i.e. where to
subtract the two from in each Lucas-Lehmer iteration).
><<My records indicate that 10,794 of the 59,169 Lucas-Lehmer tests
>above 4,194,304 will have to be discarded.>>
>
>Why not all of them?
All version 16 results are OK. They look like this:
M6521737 is not prime. Res64: 12340D1080151234. WS1: D4D7319A
If the test started in version 16 and was completed by version 17,
the result is OK (the shifted bit value was always zero). They look
like this:
M4317283 is not prime. Res64: 1234FB37253F1234. WT1: E9B7F252,0,80000000
Results computed entirely by v17 are no good. They look like this:
M6632413 is not prime. Res64: 123484E907DD1234. WT1:
AC762921,1322056,00000000
Best regards,
George
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
