Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?

[Michael Petch]

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" <address@hidden> 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.