[computer-go] UCT caveat (was in Explanation to MoGo paper wanted)
Jacques Basaldúa
jacques at dybot.com
Tue Jul 10 05:01:17 PDT 2007
Brian Slesinsky wrote:
>Since the players in the playouts are so weak, it seems like the
>improving the ability to defend a strong position from a
>not-very-clever move (and not lose it via a blunder) should be more
>important than improving the ability to find an attack. If there are
>two equally bad players that can easily attack each other but can't
>defend, it seems like the results will be close to random, almost
>regardless of starting position, unless it is very strong. On the
>other hand, if two bad players are somewhat better at defense but
>lousy at seeing weaknesses in the other side, there will be less noise
>and the one with more territory will tend to win, but an attack on a
>mostly solid position will sometimes be found via a random move, and
>given enough playouts, this will result in the probability of defense
>with a weakness being slightly lower than a truly winning position.
>It seems like this effect would be especially true of the endgame
>where there aren't so many points to take, but a position could be
>lost due to a blunder.
>I'm not sure how useful that is, since to defend a position you need
>to know how it might be attacked, but perhaps it leads somewhere?
This is a good example of something really dangerous. It is not obvious
why this is biased, but it is. In my previous post about bias, I did not
mention that: playouts must be unbiased _for all possible root positions_.
When you favor defense (or attack) you may think: "This is unbiased
since some times it favors black and other times it favors white" But
the fact is when black is in danger at the root of the tree, it is in
danger in most of the tree, therefore the trick gets the evaluation wrong.
And the same applies to white. What these tricks do is make the program
weaker. No matter who is in danger the evaluation gets wrong. And wrong
after a long random playout means _very wrong_.
Jacques.
More information about the computer-go
mailing list