[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] Some more code-related questions
From: |
Thomas Hauk |
Subject: |
Re: [Bug-gnubg] Some more code-related questions |
Date: |
Sat, 25 Oct 2003 17:06:42 -0600 (MDT) |
On Sat, 25 Oct 2003, Jim Segrave wrote:
> > How does gnubg's search work? Is it basically a beam search, and if so,
> > how are candidates chosen? How many are kept?
[snip explanation]
Thanks, that was helpful. I may check back again for clarification after I
write that part up in my thesis.
> > How do the cubeinfo and evalcontext structs work?
>
> I'm not sure I understand the question - cubeinfo's contain the
> current cube owner, cube value, match score, rule sets etc. This is
> the data needed to do cubeful equity calculations from the raw
> win/wing/winbg/loseg/losebg data. It is also needed even in non-cube
> situations such as the Crawford game, as it affects calculating match
> winning chance etc.
>
> evalcontexts contain the current choices in terms of plies, if cubeful
> evaluations are wanted, if reduced sets of rolls are to be used, etc.
I am wondering what the fields do and how each struct is used.
We have:
typedef struct _cubeinfo {
int nCube, fCubeOwner, fMove, nMatchTo, anScore[ 2 ], fCrawford,
fJacoby, fBeavers;
float arGammonPrice[ 4 ];
bgvariation bgv;
} cubeinfo;
And the comments:
* fCubeOwner: the owner of the cube,
What values does this take? 0 and 1, 0 representing the player whose
pieces are represented by the first slice of the board array? If so,
should this be changed between plies if SWAP_SIDES is called, unless the
cube is centred? (I mentioned before I want to play 1-point matches, but I
still should know how this works if I decide to use the cube later).
* fMove: the player for which we are
* calculating equity for,
Like fCubeOwner, what values does this take, and should the value be
changed between pies?
And:
typedef struct _evalcontext {
/* FIXME expand this... e.g. different settings for different position
classes */
unsigned int fCubeful : 1; /* cubeful evaluation */
unsigned int nPlies : 3;
unsigned int nReduced : 3; /* this will need to be expanded if we add
support for nReduced != 3 */
unsigned int fDeterministic : 1;
float rNoise; /* standard deviation */
} evalcontext;
(Interesting use of bit fields... are thousands of evalcontexts being
generated or something?)
I assume fCubeful is a boolean bit, and I should set it to 0 if I'm not
using the cube?
And I suppose nPlies should be set to 2, if I want a (gnubg)2-ply search.
What's nReduced and fDeterministic for?
I assume rNoise is for adding noise to the NN evaluation, so I should
probably set it to 0.0?
As a side question...
What the heck do all the prefixes to variable names signify? I've seen a,
an, aan, f, n, ... is this some kind of secret code?
> > I want to set up a match between my search procedure at 3-ply (aka
> > gnubg2ply) and gnubg at "best" settings for 3-ply (aka gnubg2ply). To make
> > things simple, I just want to play a series of 1-point matches.
> > 1. How do I "turn off" the doubling cube?
>
> Settings->Options->Use Doubling cube
I meant in the code. Right now the plan is not to use the gnubg interface
at all, just to write my own tournament program (a glorified driver) to go
back and forth between calling either the gnubg search function or my
search function, and checking for a terminal board between each one.
That way I can also do as much verbose logging to file that I want, and go
back and muck around with it later.
> > 2. What function should I call to initiate a "regular" gnubg search, given
> > a board and a roll?
>
> FindnSaveBestMoves()
ok:
extern int
FindnSaveBestMoves( movelist *pml,
int nDice0, int nDice1, int anBoard[ 2 ][ 25 ],
unsigned char *auchMove,
cubeinfo *pci, evalcontext *pec,
movefilter aamf[ MAX_FILTER_PLIES ][ MAX_FILTER_PLIES ] );
So should I just access the first element the returned pointer to a
movelist struct points to, as the the move gnubg has chosen for the given
board?
What is this auchMove thing?
How does the movefilter work?
I guess I can sum up things this way: I am trying to figure out what lines
of code I'll need so I can generate the best (gnubg)2-ply search possible
for any given board & dice rolls.
> > How does the NN cache scheme work? How can I turn it on/off? How can it be
> > adjusted?
>
> A key is generated based on the evaluation done (0/1/2/... ply), the board
> position, and match state. A hash function on this key is used to
> locate a storage point for the evaluation output. I believe (but
> haven't checked), that no collision handling is done - if there is a
> cache entry there which doesn't match, it is over-written.
>
> Why would you ever wish to turn off the cache - the result is a
> dramatic performance hit with no gains that I can imagine.
This is true. But I have my own hash table (aka transposition table)
structure already, in the code. Most state-of-the-art search algorithms
will have one (maybe they all do?). Normally a state is looked up in the
TT before it is evaluated. In this way, I can sidestep the existing cache
entirely, and store a little bit more useful information at the same time.
I also may wish to turn it off to eliminate a possible hidden variable
with my results. The greater control I have over what my code is doing,
the better. Since about the only remaining gnubg code I use are the two
calls to EvaluatePosition() and Utility(), I need to know how those are
doing their work (do a decent degree).
> If you
> expect that your search algorithm will generate evaluations which are
> only applicable at certain points, change the key definitions to
> ensure that cache lookups will only succeed in the correct context.
>
> The only adjustment is the cache size, Settings->Options->Other->Cache Size
How can I adjust that in the code? What would be the line of code to do
that?
TIA,
--Tom
--
Some people, when confronted with a problem, think "I know, I'll use
regular expressions." Now they have two problems.
--Jamie Zawinski, in comp.lang.emacs