[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: |
Tue, 01 Sep 2009 14:13:21 -0600 |
User-agent: |
Microsoft-Entourage/12.20.0.090605 |
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
- Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?, (continued)
Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?, Jonathan Kinsey, 2009/09/01
Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?, Jonathan Kinsey, 2009/09/01
Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?, Jonathan Kinsey, 2009/09/01
Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?, Jonathan Kinsey, 2009/09/01
Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?, Jonathan Kinsey, 2009/09/02