Quoting Ivan Dubois <[EMAIL PROTECTED]>:
Hello,
I think there is a very easy and straigthforward solution to the
"nakade/seki" problem, here it is :
For moves that are self-atari on a group that contains MORE than
5 stones :
Both in the tree and the playouts, strictly forbid them (exactly
like you forbid filling an eye).
(This is to handle seki and have efficient playouts).
For moves that are self-atari on a group that contains LESS
than 5 stones :
Allow them both in the tree and the playouts. In the playouts,
they should be played with a low probability. But
they should be played when there is no other move left. (This is to
ensure groups with are dead with nakade are eventualy captured in
"some" playouts).
What do you think about this solution ? I will probably implement it
in Zoe to see if it efficient, unless someone finds a flaw in the
logic.
Valkyria has a lot of logic about what self-ataris should be allowed
or not, and the size of group is part of that.
I see two possible flaws in playing the remaining moves self ataris
with low probability.
a) In some cases the group under attack will appear as alive because
the nakade is always always captured in a way that creates a second
eye. Just playing all moves with low probability does not mean that
the right move is played. Also correct nakade handling means that some
moves has to be played immediately as response to a liberty filling
move from the other player.
b) You also have the problem of seki. Many nakade problems includes
seki as a possibility in the search tree. And there are some common
seki patterns involving just a few stones, so in some cases the
probability of playing a move should be zero even with few stones.
I think the program need to either:
1) Implement proper logic for picking the correct moves
2) Learn from its mistakes, maybe hash every suicidal situation in the
playouts played and store statistics.
But of course there are always room for any quick and dirty heuristics
which actually improves the playing strength. It does not have to be
perfect to work well.
-Magnus
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
