Vlad Dumitrescu wrote:
Hi Don,
On Dec 10, 2007 9:08 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
/snipped a lot of interesting stuff/
However MC play-outs is not horizon limited like this. It's stupid to
make it greedy because it may notice that winning the big group leads to
a loss every time and that some other course of action is more productive.
I like the way you make your arguments. I have a question about the
above, hopefully you or somebody else will know the answer.
Am I confused in my understanding that a weakness of MC evaluation is
that due to its random play it will miss sequences where there is only
one winning move at each play? This is the way I am interpreting the
"nakade problem" discussed in another thread: to keep a dead-by-nakade
group dead, one must not miss one single move in the sequence. Of
course, in games the nakade example is just one of the simpler
variants, most semeai (capturing races) will fall into that category.
In Crazy Stone (maybe that is the case of MoGo, too), nakade is such a
big problem because the program avoids playing self-atari in playouts.
Crazy Stone will play the self-ataris anyway, but with a low
probability, so they are played at the end of the playout only. In case
there is a semeai around the nakade, this behaviour generates awful
evaluation errors.
I expect it should not be so difficult to fix many evaluation errors by
adding knowledge to make the distinction between nakade self-atari and
others self-atari.
This uncertainity is what gives the less-than-1 confidence you
discussed, but my feeling is that it varies too much with the sequence
length -- the answer would be to add some intelligence, like MoGo and
the other top programs do.
The nakade problem we observe here is not because the programs have not
enough intelligence, but rather because they have too much: they give a
low probability to some bad looking moves that turn out to be good in
this particular position.
Whatever clever features are used for patterns in playouts, there will
always be cases where they give a low probability to an urgent move
(typically, in a semeai). So this is a problem that cannot be completely
solved by just adding knowledge to patterns. We need deeper algorithmic
improvements.
Rémi
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
