[computer-go] Monte-Carlo Go simulation

[David Doshay]

I think that the bias Alain meant is the choice of moves that control  
the
branching factor. If I understand correctly, this can happen differently
in two places in MoGo: once in the branching below a node in the UCT
tree, and either the same or differently in the random playouts.

In some ways this is like SlugGo, where branching at the first level
(our move) may or may not be determined in the same way as at
the next (their guessed reply). If SlugGo is set for multiple levels of
branching in the lookahead we do the same thing but from the other
perspective. But for deeper linear lookahead things are different, just
like in your random playouts.

Alain's point, that knowledge can both help narrow the search to "good"
moves and at the same time steer you away from the best move is
absolutely true in SlugGo's case. This is the primary reason we have
always wanted to have multiple Go engines making move suggestions,
not just multiple instantiations of the same engine like we have now.

But we could get up and running faster with one engine, so that is
where we are now. Hopefully not much longer ...

Cheers,
David



On 8, Feb 2007, at 2:09 PM, Sylvain Gelly wrote:

>> It seems i was ambiguous: I was speaking of the simulation player  
>> too.
>> What i meant is a random simulation player is not biased, whereas  
>> a "better"
>> simulation player is biased by its knowledge, and thus can give wrong
>> evaluation of a position.
> I think we have to start defining what the bias. For me the bias is
> the difference between the expected value of the outcomes of playouts
> by the simulation player and the "real minimax value". In this
> definition the uniform random simulation player is VERY biased and
> gnugo much less.
>
>> A trivial example is GNU Go: its analyze is "sometimes" wrong.
> Of course, if not computer go would be solved :-).
>
>> Even if it is obviously much stronger than a random player, it  
>> would give wrong >result if used as a simulation player.
> Hum, are you sure? I think that GnuGo with randomisation, (and much
> faster of course) would make a very good simulation player (much
> better than any existing simulation player). But a weaker player than
> GnuGo can make an even better simulation player.
>
>> David Doshay experiments with SlugGo showed that
>> searching very deep/wide does not improve a lot the strength of  
>> the engine,
>> which is bound by the underlying weaknesses of GNU Go.
> Yes, this a similar non trivial result. I think there are more
> existing experimental and theoritical analysis of this, though.
> Perhaps such an analysis already exist for MC also, it is just that I
> don't know.
>
>> Or maybe i just understood nothing of what you explained ;)
> It was not really "explanations", just thoughts. I have no the
> solution, just think that it is an interesting question, and that it
> may be discussed. May be from a strong explanation of this phenomenon
> could come new ideas.
>
> I understand all these counter examples, I just think that it is more
> complicated than that.
>
> Sylvain
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/