Quoting Gian-Carlo Pascutto <[email protected]>:
On Thursday 11 June 2009 13:16:42 Magnus Persson wrote:
Would this be a simple way of using many cores effectively?
I don't see what it has to do with multiprocessing.
Otherwise I cannot see how recursive UCT would be anything else than
an ineffective implementation of UCT. Unless it provides some
information that could be used more effectively than with normal search.
It would improve the quality of the playouts (the evaluation).
The closest thing I know would be internal iterative deepening in chess. If
you don't know what the best move is, and you need to know to get good move
ordering and an efficient search, you just call search recursively with
half the depth.
I see the point of this because internal iterative deepening search
almost nothing before searching for real...
Basically, you would run UCT as normal at the top level, and in the
playouts, use UCT with a small node limit.
...but this just cannot work it means a lot of search in order to
update the tree once.. Valkyria scales between 150 Elo between 5 and
10 playouts against Fuego 0.3.2 using 200 playouts. So assuming I let
the playouts of Valkyria play 10 playouts for each move in the
"Meta-Playout" it will spend 500 playouts for a 50 move deep
Meta-Playout on 9x9. This means valkyria will run only 2 playouts per
second in the tree part. Also this will throw away AMAF information
because the top moves in the sub-playouts are identical in the
beginning and the random moves played deeper become heavily biased
toward the Meta-Playout.
If I had some magic hardware that could play the Meta-Playouts at the
same speed as a normal playouts do it would surely play strongly. But
in practise I think this will not work. But it should not be too hard
to test so please convince me someone with some empirical data and I
will quickly change my mind...
The UCT-guided playouts will avoid many cases of badly resolved semeai, and
this in turn guides the top level UCT search better.
Of course coming up with a vague idea is one thing, getting it to work is
another matter :)
But it's where I would look to solve the "brick wall"/"bias" issue with
current playouts.
--
Magnus Persson
Berlin, Germany
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
