[Computer-go] semeai example of winning rate

Darren Cook darren at dcook.org
Wed Jan 19 20:35:00 PST 2011


>> The risk to scalability is that we will bias the search by focusing on
>> variations that a blitz program cannot discover, but a massively scalable
>> system could.
> .... 
> It seems to me that improvements in playout policy would apply to any
> time control.  But perhaps in-tree heuristics should be dependent on
> the number of visits to the node.

I think there is some minimum number of playouts needed, however heavy
they are. Imagine an algorithm that improves semeai handling, but makes
each playout take four times as long. The old algorithm at 1000 playouts
might play better than this one at 250 playouts; but at 40K vs. 10K
heavier playouts it might be the other way round.

Another way to think of it is the more playouts each player has, the
higher the quality of play. The nature of the game changes as the
quality improves: a 30 kyu game can be decided by a ladder that gets
played out, a 10 kyu game by a bulky-5 life-death problem in the corner,
and the 1-dan game by a complex corner involving choices between ko and
seki. But these don't crop up in the pro-level game as the players see
the ladder, the life-death status and the coming ko, and their game is
all about trading ladder breakers for better endgame moves and ko threats.

You don't need a joseki library when you're playing with 10K or even
100K playouts because play will be dominated by middle game mistakes.
But once the players are strong enough then games will be decided by
subtle mistakes in the opening. To test a joseki library at 10K playouts
and decide it actually makes you a rank weaker would be to miss the
point that it could make you 2 ranks stronger at 1 million playouts.

Told you I was getting passionate about this point ;-). Though actually
I wasn't even thinking so much about number of playouts, more about
other ideas such as first spending a few seconds on static semeai or
life-death analysis on the root position then using that information to
influence the playouts the same way RAVE values are used.

Darren




More information about the Computer-go mailing list