The static evaluation gets the correct status for the groups in the semeai. The static evaluation thinks that white is far, far ahead. The MCTS engine thinks black wins 60%, so the playouts don’t get it right.
It's a little frustrating that MCTS is so much stronger, even though in many simple positions it is far weaker than the static evaluation. David > -----Original Message----- > From: [email protected] [mailto:computer-go- > [email protected]] On Behalf Of Aja > Sent: Friday, January 14, 2011 10:06 AM > To: [email protected] > Subject: Re: [Computer-go] Semeais > > David, can Many Faces solve this position posted by Magnus? > > http://www.littlegolem.net/jsp/game/game.jsp?gid=1226980 > > I test this position in Erica, Erica can score/solve it correctly. But > that > is because I tried to handle similar positions in the past. Erica still > fails easily if the condition is different. We really need a general > soluation for semeai, so that we don't need to deal with so many cases of > semeai. > > Aja > > > -----????----- > From: David Fotland > Sent: Saturday, January 15, 2011 1:58 AM > To: [email protected] > Subject: Re: [Computer-go] Semeais > > 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: [email protected] [mailto:computer-go- > > [email protected]] On Behalf Of Kahn Jonas > > Sent: Friday, January 14, 2011 9:35 AM > > To: [email protected] > > 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 > > [email protected] > > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go > > _______________________________________________ > Computer-go mailing list > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go > > _______________________________________________ > Computer-go mailing list > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
