You are right, it is not a "perfect" solution. I find it attractive though
because it is very simple and I think it will work well on "a lot" of
situations.
Currently Zoe is losing a lot of games on cgos because it doesnt even know
about seki. At least it should be an improvement over what is done in Zoe
now.
You said Valkyria had a lot of logic about what self-ataris should be
allowed. It seems to be usefull, from what I have seen valkyria doesnt seem
to have flaws in its life and death understanding, unlike most other MC
programs (including mine)
----- Original Message -----
From: "Magnus Persson" <[EMAIL PROTECTED]>
To: <computer-go@computer-go.org>
Sent: Thursday, March 13, 2008 8:57 AM
Subject: Re: [computer-go] solving the nakade problem
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/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
