[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?
From: |
Michael Petch |
Subject: |
Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem? |
Date: |
Fri, 04 Sep 2009 01:37:46 -0600 |
User-agent: |
Microsoft-Entourage/12.20.0.090605 |
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.