Quoting Erik van der Werf <[email protected]>:
On Thu, Sep 9, 2010 at 9:33 AM, <[email protected]> wrote:
When it plays a random move many moves are pruned and a new random
move is generated until an acceptable move is found.
Funny, that is roughly the strategy I used 3 years ago in the first
version of Steenvreter (which then won the Olympiad). At some point I
made it more like the Mogo playouts, because that was faster and at
the time seemed to perform a bit better. Nevertheless, Steenvreter's
current performance is still quite similar on the low end (also
breaking even with gnugo on 9x9 at about 100 playouts), though I think
I get most of that from good priors in the tree. Maybe I should dust
off my old policy some time...
I am also using the playout policy as priors in the tree. This means
every change I do to the playouts also affect tree priors. As you say
this is also very important. Playouts can be noisy but tree priors
also is an absolute necessity for effective selective search.
Another thing one can do rather than simply prune moves is to propose
an alternative local move that dominates the pruned move. I do this in
Valkyria too. This way one gets better moves without repeating the Get
Random Move/Check For Pruning cycle, and also forces the programmer to
make sure the pruned move is really bad.
Some pruning is essential. If one want the playouts to handle seki
some checks must be done. If one solves seki in the tree then full
board search will be inefficient everytime a seki is present on the
board. it might work well for 9x9 but not for 19x19 where many
tactical situations may be present that has to be independently
handled in the playouts.
Magnus
Erik
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
