On Thu, Sep 10, 2009 at 09:18:40AM -0400, Jason House wrote:
> Somewhat... One could generate a random number (r) and combine it
> with the move mask (m) as follows:
> black moves = m & r
> white moves = m & ~r
>
> This has the drawback that the number of black and white moves may
> not be equal. It can be modified to give an equal number of moves
> such as requiring that each subset of n intersections generates the
> same number of black and white moves, or doing some kind of looping
> until the condition is met.
>
> For looping, you could keep some subset of the generated moves in
> order to guarantee convergence. For example, if there are 14 more
> white moves than black moves, keep all generated moves except for 14
> white moves. Then you only have to pick 14 moves in the next loop
> iteration.
As a quick test mainly to test the speedup, I have made a simple hack
that takes every other intersection (creating an X-pattern) and
assigns it a randomized value (S_NONE,S_BLACK,S_WHITE). No check
on number of stones is made.
Now it thinks black has 46% win probability on empty board with no komi,
for a speedup of 1000 playouts/s. So the speedup seems totally
disappointing, and the bottleneck is in fact in the latter phases of the
game (merging groups and capturing). Hmm, something to dig into.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
