[computer-go] Monte-Carlo Go Misnomer?

[David Doshay]

On 2, Feb 2007, at 9:08 AM, dhillismail at netscape.net wrote:

>      I agree with what you say here and I'll try to make my point  
> better. First, my limited experience working with Monte-Carlo  
> simulations involved photons traveling through scattering media.  
> The sequences of moves described in the Mogo paper are pleasantly  
> reminiscent of this.
>
>      I did not mean to suggest that heavy playouts, incorporating  
> go knowledge, makes the Monte-Carlo description incorrect. Rather,  
> the term is increasingly insufficient as a Go engine description  
> because it lumps together such very different algorithms.

It is clear that a wide variety of MC attempts are in use and under  
construction, each with their own way of attempting to construct a  
proper distribution (and some with no idea that this is even an  
important part of the procedure). I think that MoGo is being so  
successful because they have gone the farthest is getting the  
sampling closest to a distribution appropriate for Go. Unfortunately,  
there is nothing like a Boltzman function that helps us with Go.

> The earliest MC engines were extremely simple and easily described.  
> It seems inevitable that someone new to the field will seize on  
> this description, and then combine it with the success of current  
> Monte-Carlo engines, leading to unnecessary confusion.

I am not sure what you mean by that. Do you mean that different  
people will use the term MC in different ways and cause confusion in  
the minds of third parties? In other words, some people are using the  
simplest pure random playout (no consideration of distribution at  
all) and calling that MC while others are trying hard to keep the  
moves searched "Go-like." and thus get different results. Or do you  
mean that naive programmers will try pure random playout and wonder  
why the MoGo folks are doing so very much better, not realizing the  
importance of getting a decent distribution for MC to be effective?

>      On a tangential note: MC/UCT with light playouts and MC/UCT  
> with heavy playouts are different beasts. If SlugGo's mixture of  
> experts work expands to include MC/UCT, you might want to consider  
> adding one of each.

I am quite open minded about what kind of experts we add to SlugGo.  
We are limited more by the time required to implement and integrate  
than anything else. Integration is a problem that can be quite severe  
for experts (or move suggesters) with completely different evaluation  
functions. How does one arbitrate between suggestions that come to  
you with evaluations of move quality that are on scales that are not  
co-linear? This point has kept SlugGo as a pure GNU Go dependent  
engine for longer than we had originally expected.

But I am not sure what the value is in what you are calling "light"  
playouts. As per the above, it seems to me that light playout is  
simply ignoring any proper distribution, and thus is just a much more  
inefficient way to sample.

Cheers,
David