[Bug-gnubg] Beavers and analysis

[Jim Segrave]

Posting here, as the web interface reformats and doesn't support
threading. The commentary on this bug report is getting lengthy and
has divided into two distinct threads.

On Thu 24 Jul 2003 (07:38 -0400), address@hidden wrote:
> 
> =================== BUG #4408: LATEST MODIFICATIONS ==================
> http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4408&group_id=66
> 
> Changes by: Joern Thyssen <address@hidden>
> Date: Thu 07/24/2003 at 11:38 (GMT)
> 
> ------------------ Additional Follow-up Comments ----------------------------
> Re: first:
> 
> gnubg doesn't analyse beavers... But your "sharing" of the result may be the 
> first step towards support.
> 
> 0..N      N+1         N+2       N+3         N+4
> prev ==> double ==> beaver ==> take/drop ==>roll
> moves    play1    (double)      play1       play1
> play0 
 
> N+1 and  N+2 can be  shared, but N+3   can only be  shared for money
> play. Fortunately there are no beavers in match play!
 
> For N+1 we need both the ND and DT numbers. FOr the N+2 we only need
> the DT numbers, and for N+3 we also only need the DT numbers.
 
> For the racoon decision (N+3) we actually need both "drop", "take",
> and "raccoon", but "drop" is trivial and "raccon" is equal to 2 *
> "take" since the only difference between "racoon" and "take" is the
> value of the cube -- the cube ownership is unchanged.

As it works out with the most recent changes:

N+1 will have the ND and DT numbers as would any other double

N+2 is treated as a double (that's the moverecord type) and will have
    a place for its own set of ND and DT numbers. I assume that if A
    doubles to 2 that the match state when considering N+2 will be
    with the cube on 2 and cube owner being player 0. An analysis at
    that point needs to look at the equity of player 1 on roll and
    cube on 4 vs. drop with cube on 1. I haven't looked at the code to
    see if it can handle that or not. Whatever the analysis of this
    position comes up with will be stored in arDouble, aarOutput and
    aarStdDev for the analysis of the beaver. I actually wonder if we 
    need a different moverecord type (but identical structure to a 
    MOVE_DOUBLE) marking beavers and raccoons separately so that 
    the analysis functions will know about the differences in who owns
    the cube and who is on roll.   

N+3 (the take) is shared with N+2. I would think it the take/pass
    is the same as any other take/pass decision except that if you 
    take, you don't own the cube but you are on roll. At the moment,
    the common part with the double doesn't give you any way to see if
    you are sharing data with a double, a beaver or a raccoon. Maybe 
    this is where we need a second marker in the cubedecisiondata 
    struct - it would also address potential problems with the
    doubling decision - say type MOVE_DOUBLE (ordinary double),
    MOVE_BEAVER (beaver by new cube owner), MOVE_RACOON (redouble
    by player on roll but not cube owner). It would be easy enough to
    add if it makes analysis easier


Now I know why I don't like money games.

-- 
Jim Segrave           address@hidden