On 2, Feb 2007, at 9:08 AM, [EMAIL PROTECTED] 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
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
