[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Beavers and analysis

From: Joern Thyssen
Subject: Re: [Bug-gnubg] Beavers and analysis
Date: Thu, 24 Jul 2003 15:53:42 +0000
User-agent: Mutt/1.4.1i

On Thu, Jul 24, 2003 at 04:54:02PM +0200, Jim Segrave wrote
> > 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.   

As you indicate, you can deduce the "double type" from the current
matchstate (before the current move is applied). Check the function
DoubleType in eval.c. It's already used to filter out beavers, which are
not yet handled correctly.

> 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

I think the following logic should cover all situations:

(I assume all equities are calculated for the player on roll)


Normal double:

We need equities for ND, DT, and DP:

if ( DT >= ND && DP >= ND )
   if ( DT >= DP )
      double, pass (DP)
      double, take (DT)
   no double (either too good or not good enough) (ND)


we need equities for "take", "pass", and "beaver" which happens to be
exactly DT, DP, and 2 * DT.

if ( DT >= DP )
   if( DT <= 0 )
      /* kauder paradox */


We need equities for "pass", "raccoon", and "take", which is -DP, 2 *
DT, and DT.

if ( DT <= DP )
   if ( DT >= 0 )
      /* kauder paradox */

Take or Drop:

Same logic as Beaver above

The equities needed for all decisions are the same so they can all share
the same struct with equities.

The GUI and exports has to be changed to display different widgets for
each type of decision:

Normal double:

No double
Double, Take
Double, pass







reply via email to

[Prev in Thread] Current Thread [Next in Thread]