Re: [Bug-gnubg] Beavers and analysis

[Jim Segrave]

On Fri 25 Jul 2003 (08:36 +0000), Joern Thyssen wrote:
> 
> Higher ply is slightly more complicated, since gnubg plays according to
> score in the intermediate plies and does mini-max over all possible cube
> positions and ownerships, so you cannot do a cubeless 2-ply and just
> apply the cubeless-to-cubeful formulae.
> 
> Anyway, let's look at the equities for a initial double:
> 
> ND = fMove on roll, fCubeOwner = -1, nCube = 1
> DT = fMove on roll, fCubeOwner = ! fMove, nCube = 2
> DP = +1
> 
> For the beaver decision we need:
> 
> "take" = fMove on roll, fCubeOwner = ! fMove, nCube = 2    
>        = -DT
> "pass" = -1 = -DP
> "beaver" = fMove on roll, fCubeOwner = ! fMove, nCUbe = 4
>          = -2 * DT
> 
> 
> For the raccoon decision we need:
> 
> "take" = fMove on roll, fCubeOnwer = ! fMove, nCube = 4
>        = 2 * DT
> "drop" = -1 = -DP
> "raccoon" = fMove on roll, fCubeOwner = ! fMove, nCube = 8
>           = 4 * DT
> 
> 
> Take/drop decision:
> 
> "take" = fMove on roll, fCubeOwner = ! fMove, nCube = 2
>        = -DT
> "drop" = -1 = -DP
> 
> 
> The interesting point to note is that we need "fMove on roll, fCubeOwner
> = ! fMove" for various cube values, but fortunately money equities scale
> propertionally with the cube value.
> 
> For the N+1 "normal" cube decision (MOVE_DOUBLE) we store ND, DT, and
> DP. All needed equities for N+1, N+2, N+3, .. can be calculated
> trivially from these, so the equities for N+1 can be shared with N+1,
> N+2, N+3 etc. This is only possible for money play, since match play
> equities or mwc doesn't scale propionally with the cube value, but
> fortunately beavers and raccoons are not allowed in match play(phew!)

OK - I decided to try the following approach (I have code for this
which I can commit):

Each MOVE_DOUBLE, MOVE_TAKE, MOVE_DROP moverecord has the cube
decision data (aarOutput, aarStdDev, arDouble and esDouble as a
substructure. It also has a pointer in the moverecord to this
structure.

For matchplay, MOVE_DOUBLE will always be followed by one of MOVE_TAKE
or MOVE_DROP. The take and drop records have their pointer pointing
back to the cube decision data in the preceding double record.

For money play, you could have a long series of MOVE_DOUBLES,
representing an initial double, a beaver, a raccoon, an aardvark (or
whatever it is), etc. eventually followed by a take or drop.

For every one of these records, the pointer to the cube decision data
will point back to the initial double.

In order to keep track of where we are, I added another element to the
movedouble struct:

int nAnimals;

This will be 0 in the initial double (both money and match play). It
will be 1 for the beaver double record, 2 for the raccoon, etc. So
when it's time to evaluate a double, take or drop, we know where to find the
initial evaluation of the double and we know if we're looking at a
record for the opponent (nAnimals is odd and it's a double, nAnimals is
even and it's a take/drop) or for the initial doubler (nAnimal is
even).
In all cases, the cube value for a pass is ( 2 << nAnimals ), the cube
value for a take is 2 * that and the cube value for <animal-naming> is
4 * the pass cube value.

Here's where I'm getting on to shaky ground and comments would be welcome:

Things I think need changing (all for money play only):

arDouble in the evaluations has only 4 array elements - optimal, no
double, opponent drop and opponent take. But that leaves out doubler
drops (response to a raccoon). I think we also need a figure
expressing the equity for opponent <animal>s - 

GetDPEq returns True iffi the cube is centred or the player pci->fMove
  owns the cube. This will prevent FindBestCubeDecision for ever
  generating aardvarks, because at that point the cube ownership in
  pci is the wrong way around. We could special case this by looking
  to see if plLastMove->p->mt == MOVE_DOUBLE because at that point,
  whoever's making the decision can turn the cube (ownership is a
  looser concept here)

At the top of FindBestCubeDecision, we're using GetDPEq to decide if
cube action is possible, without the above change, you can't go past a
raccoon.

FindBestCubeDecision doesn't look to me like it actually knows how to
deal with a raccoon - it appears to me that it's designed to choose
between no double or double with an indication of what the opponent
should do if it it's a double, but that doesn't allow for all the
possibilities:

Pass, Take, Redouble & opponent should take, Redouble and opponent
should pass, since pass is only ever output as the best move for the
opponent, never for the current player (a return of no-double from
here implies either a take or a pass, but it doesn't say which). 

UpdateStats has no way of considering a drop to a raccoon, if arDouble
were extended, this could be added. It also doesn't look like it has
any way of handling the case where a take or drop should have been a
double 

AnalyseMove skips over ones where DoubleType is a beaver or raccoon. 



-- 
Jim Segrave           address@hidden