I have committed a fix for this. I have tested it the past day and doesn't seem to break anything - someone may wish to code review it.
On 01/09/09 2:13 PM, "Michael Petch" <[email protected]> wrote: > GnuBG enforces a match limit of 64 points. Worst case is that GnuBG has to > handle 64 away-64away. Since 0away 0away is not possible, you can subtract 1 > and get an "away" score store into 2^6 bits (0-63). > > The problem is that the EvalKeys only use 5 bits (And they don't subtract 1) > so effectively the best our key can hold is an away score of 31 (And wrap > back to 0 when we hit 32). From what I can see 32 away and 0 away are > considered equal after the wrap, and that's not right. I almost wonder if > historically maximum match score was < 64. > > Another side effect is that anScore[ 1 ] > 31 promote an extra bit when > when XORing thus affecting the next field (potentially screwing up the low > bit of log2(nCube data) in the case that it happens to have a low bit of 1 > set. _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
