[Computer-go] Semeais

[David Fotland]

Many Faces does something like this, and it does not work well.  Many Faces
includes a static semeai solver with local search, and this is applied in
the tree.  If anyone has many faces you can set up a semeai and ask for
group status.  This shows you the result of the static life/death/strength
analysis, and you can see the kind of semeai it will leave for the playouts.

The problem comes when the tree finds the semeai, and the correct move is
made in the tree to resolve the semeai.  At the exit from the tree, any
semeai on the board has been resolved (in that one side will win by
typically one move).  The tree won't waste extra moves in the semeai, so at
tree exit, the winning side is one move ahead.

Then the playout has no clue about the semeai, and lets the losing side win
perhaps 40% of the time.

Semeai knowledge is required in the playout.  The tree must leave resolved
semeai positions on the board which the playouts can't understand,
introducing a large bias.

David

> -----Original Message-----
> From: computer-go-bounces at dvandva.org [mailto:computer-go-
> bounces at dvandva.org] On Behalf Of Kahn Jonas
> Sent: Friday, January 14, 2011 9:35 AM
> To: computer-go at dvandva.org
> Subject: Re: [Computer-go] Semeais
> 
> On Fri, 14 Jan 2011, terry mcintyre wrote:
> 
> > It is expensive to solve semeai during every playout, but what if semeai
> > solutions were done once per game move (or even less frequently), and
> the
> > information obtained were then amortized over many playouts?
> >
> > The top-level analysis would solve the semeai, and create a self-
> updating
> > set of move-response triggers. The tricky bit is that the indicated
> > behavior must correctly adapt to all possible moves during a complete
> > playout, in a manner which does not interfere with other simultaneous
> > playouts.
> 
> I think that was the most common idea. At least that's how I understand
> Olivier's ideas, and my vague suggestion also fits that description.
> 
> I am copying the suggestion back here to add a remark.
> >> We may make a local tree (moves only in the zone or that take away a
> >> liberty of one of the groups), first without tenukis, and see who wins.
> >> We may then add tenukis for the winning side.
> 
> (Tenukis mean pass move since it's a local tree.)
> 
> >> During playouts, (we may use that during playouts rather than at the
> >> beginning), when a move is played in the area, the winning side has to
> >> follow the tree along a winning line.
> 
> In fact, we also need to make the tree for when the other side is
> winning: taking ko into account during playouts is out-of-reach today,
> but by the time we leave the MCTS tree to enter the playout, there may
> have been a move added for free in the local area (ko in the tree). And
> then the other side is the winner for this playout.
> 
> Jonas
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go