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

[Michael Petch]

On 01/09/09 1:37 PM, "Jonathan Kinsey" <address@hidden> wrote:

> Although I made a slight change, it was always the case that these where
> stored,
> the comment was just out of date...

Sorry, I noticed this after when I was reviewing the code that builds the
key. One thing I believe is a bug or concern for match play is this (Should
be relatively easy to fix) and a long standing bug as well (Unless I am
missing something):

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.

My opinion is this. We should extend both anScore fields to have 6 bits
instead of 5 so this code would need to be changed accordingly (the shifts)

 ( ( pci->nMatchTo - pci->anScore[ pci->fMove ] ) << 13 ) ^
        ( ( pci->nMatchTo - pci->anScore[ !pci->fMove ] ) << 18 ) ^
        ( LogCube( pci->nCube ) << 23 ) ^


Something else that may have to change, but maybe it is already handled (I
don't think so). I am pretty sure  nMatchTo is the actually match length.
I'm unsure if pci->anScore[ 0 ] and pci->anScore[ 1 ]  are 0 based or not
(My assumption is that a score of 0 is represent as 0 not as score+1). If
that's true, then if we add a bit we might consider changing the code
slightly to:

( pci->nMatchTo - pci->anScore[ pci->fMove ] - 1 )
and
( ( pci->nMatchTo - pci->anScore[ !pci->fMove ] - 1)

Then when decoding the keys you'll have to make sure you add 1 back to the
values. This would allow you to hold all the away based scores from 1-64 as
0 to 63 (And fit it in 6 bits).

Without these changes score based results for situations with large away
scores will share keys, and thus share potentially invalid cache data.

Michael