Hi,
At 05:19 PM 11/10/98 +0100, Ignacio Larrosa Caņestro wrote:
>What are the two last and new fields in that two lines?
>UID: ILC/P150-FEDUC, M5014301 is not prime. Res64: xxxxxxxxxxxxxxxx. WT1:
>5B3769CD,0,80000000
>UID: ILC/P200-FEDUC, M4865933 is not prime. Res64: xxxxxxxxxxxxxxxx. WT1:
>6F38D9BF,3089921,00000000
This is very briefly discussed in the readme.txt file but deserves
elaboration.
The first new number (the 3089921 in your second result) is the shift count.
Version 17 starts a Lucas-Lehmer test by shifting the first value (four) by
a random amount. If two people test the same exponent with a different
shift count and get the same result, then the exponent is considered
double-checked. I needed to print the shift count in the extremely rare
event that two people started with the same random shift count.
The second new number (actually a 32-bit hex value) is actually 5 new
values dealing with errors. The top bit is on if some initial iterations
were done with an earlier version - which tells me to look for errors the
old-fashioned way by looking in the log files. Note that's also why the
shift count on your first LL test was zero.
Then there is a 7-bit value and three 8-bit values. If the counts are
too large to fit in the container the count maxes out at 127 or 255.
The first value is a count of "Ignore last message the problem was
reproducible" messages. The second value is a count of "ILLEGAL SUMOUT"
messages. The third value is a count of "ROUND OFF (xxx) > 0.40" messages.
The fourth value is a count of "SUM(INPUTS) != SUM(OUTPUTS)" messages.
First, I'd like to prove the ILLEGAL SUMOUT errors do not affect the
quality of the result, and secondly I will use the data to make sure
that exponents where errors occured are retested as soon as possible.
Note: these two values are stored in the intermediate file. That is
why version 16 cannot read intermediate files produced by version 17.
Hope that enlightens,
George
