Quoting Yamato <[EMAIL PROTECTED]>:
In other words UCT works well when evaluation/playouts is/are strong. I
believe
there are still improvements possible to the UCT algorithm as shown by the
recent papers by Mogo and Crazystone authors, but what really will make a
difference is in the quality in the playouts.
Sylvain said that good moves in the playouts do not always improve
the performance of UCT. What do you think about this claim?
I think it is true to some extent. When a new pattern is added it introduces a
bias towards certain shapes. When this happens the UCT search will encounter
new types of positions which it cannot handle, becuase it does not have those
patterns yet.
So it sometimes happens that the program gets worse with pattern A alone but
with patterns A and B it gains in strength.
A second way of formulating this is that there are no rules without exceptions
in go. Thus for every pattern added one creates problems, and one might
need to
discover those exceptions to get the benefits. And then there are of course
exception to the exceptions... So when I think it is possible to improve
playout infinitly I would also say it is really really difficult... at
least by
hand which I am doing now.
Here is a problem I have experienced both with Viking5 (my first
MC-program) and
Valkyria. When ladder reading code is added moves premature on the second line
become more popular because everytime a random move of the other color is
played on the first line just below the move on the second line then the
program can capture that stone in a ladder and get stronger. The solution to
this is to prune this kind of moves onf the first line .
With Viking I also had problems with code for defending eyshape which I know
made the program slightly weaker overall although it played life and death
situations better. Here I think that for most such defensive moves in a
playout
the group is already dead ore alive anyway, and tenuki would be correct. thus
using this code would also require the knowledge of what is alive, dead and
unstable and this was too complicated for Viking, so in the end I
disabled that
code.
-Magnus
--
Magnus Persson
Berlin, Germany
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
