Re: [Bug-gnubg] crashed position

[Mark Higgins]

Thanks Ian! That makes it a lot more clear.


On Feb 10, 2012, at 5:34 AM, Ian Shaw wrote:

> I'll just emphasize Joseph's explanation. 
> 
> 
> Mark wrote:
> " I'd imagine a crashed position is one where you're bearing in against an 
> opponent anchor and have to start dismantling your beautiful barricade as the 
> checkers come in."
> 
> This is not the essence of a crashed position. It's not about bearing in 
> against an anchor (although some of these will be in the crashed category). A 
> position is crashed if most of  a players chequers have ended up on his own 1 
> and 2 points, giving him little flexibility. He has no control of his inner 
> board or the outfield, which allows his opponent to spread his chequers 
> around without fear of being hit and contained. This calls for different 
> tactics from the standard contact positions. 
> 
> Perhaps a couple of diagrams will help (view with fixed-width font). Player X 
> has the same structure each time; the difference is in the opponent's 
> position. In the crashed position X can safely slot the front of the prime to 
> roll it forward, but this would be too dangerous when O still has good 
> structure.
> 
> 
>    GNU Backgammon  Position ID: /z4AADBsuxsEAA
>                    Match ID   : cAngAAAAAAAE
>    +24-23-22-21-20-19------18-17-16-15-14-13-+  O: White
>    | O  O             |   |                X |  0 points
>    | O  O             |   |                  |  
>    | O  O             |   |                  |  
>    | O  O             |   |                  |  
>    | 8  O             |   |                  |  
>    |                  |BAR|                  |v 7 point match (Cube: 1)
>    |                  |   |                  |  
>    |                  |   |                  |  
>    |                X |   | X                |  
>    | O     X  X  X  X |   | X  X             |  On roll
>    | O     X  X  X  X |   | X  X             |  0 points
>    +-1--2--3--4--5--6-------7--8--9-10-11-12-+  X: Blue
> 
>    GNU Backgammon  Position ID: sN0tADBsuxsEAA
>                    Match ID   : cAngAAAAAAAE
>    +24-23-22-21-20-19------18-17-16-15-14-13-+  O: White
>    |             O  O |   | O  O  O  O     X |  0 points
>    |             O  O |   | O  O  O          |  
>    |                  |   | O  O             |  
>    |                  |   |                  |  
>    |                  |   |                  |  
>    |                  |BAR|                  |v 7 point match (Cube: 1)
>    |                  |   |                  |  
>    |                  |   |                  |  
>    |                X |   | X                |  
>    | O     X  X  X  X |   | X  X             |  On roll
>    | O     X  X  X  X |   | X  X             |  0 points
>    +-1--2--3--4--5--6-------7--8--9-10-11-12-+  X: Blue
> 
> 
> I hope this helps.
> 
> -- Ian
> 
> 
> 
> 
> -----Original Message-----
> From: address@hidden [mailto:address@hidden On Behalf Of Joseph Heled
> Sent: 08 February 2012 23:09
> To: Mark Higgins
> Cc: address@hidden; Øystein Schønning-Johansen
> Subject: Re: [Bug-gnubg] crashed position
> 
> CRASHED attempts to capture the positions where one side has only a
> small number of "active pieces". The number of active pieces has been
> arbitrarily set at 6, and the definition requires that you have at
> most 6 checkers not on points 1 or 2, accounting for the possibility
> of  one checker from 2 sent back after the rest piled on point 1.
> 
> The most important part in this celebration of arbitrary decisions was
> to use a definition which is non cyclic - positions resulting from a
> crashed positions should be crashed. When this is violated,
> performance deteriorates since each net is trained only on it's own
> kind of positions.
> 
> That was my experience anyway. I will be happy to see someone coming
> up with a better definition and performance. GNUbg pathetic play in
> many backgame situations leaves it open to abuse from humans.
> 
> -Joseph
> 
> On 9 February 2012 00:23, Mark Higgins <address@hidden> wrote:
>> Revisiting this one - I read the eval.c ClassifyPosition code, so have a
>> decent idea of how gnubg defines "crashed" (it's not what I described
>> below).
>> 
>> What I don't get is why it uses this particular definition.
>> 
>> ie I'd imagine a crashed position is one where you're bearing in against an
>> opponent anchor and have to start dismantling your beautiful barricade as
>> the checkers come in.
>> 
>> So why isn't crashed something simple like "contact, and at least one player
>> has all their checkers at their nine point or closer"? Seems like that's
>> roughly when you'd start caring about how to bear off against an anchor.
>> 
>> Or maybe you'd replace "nine point" with "six point" if you want to get
>> closer to the end of the game. But I don't really see why how many checkers
>> are on the 1 or 2 point specifically matter than much (vs the 3 point, or
>> why >1 checker is the threshold vs >0 checkers).
>> 
>> Anyone remember the motivation for the current definition?
>> 
>> 
>> 
>> On Dec 17, 2011, at 12:22 PM, Øystein Schønning-Johansen wrote:
>> 
>> 
>> 
>> On Sat, Dec 17, 2011 at 4:05 PM, Mark Higgins <address@hidden> wrote:
>>> 
>>> I'm trying to find the exact definition gnubg uses for a "crashed"
>>> position.
>>> 
>>> The one reference I've found (Thomas Haug's thesis) says it's contact,
>>> plus the restrictions that the player has fewer than 7 pieces remaining with
>>> none in the opponent's 1 or 2 position. Is that correct?
>>> 
>>> If so, can someone give a little color on why those particular
>>> restrictions? eg why is it contact if the player has a piece on the
>>> opponent's 2 position, but crashed if it's on their 3 position?
>>> 
>> 
>> The source is the documentation!
>> http://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/eval.c?revision=HEAD&view=markup
>> 
>> Search for the function called ClassifyPositon()
>> 
>> -Øystein
>> 
>> 
>> 
>> _______________________________________________
>> Bug-gnubg mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>> 
> 
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-gnubg