So I wouldn't be surprised at all if at some point you'll see a
marriage of the best ideas of traditional Go programs and Monte-Carlo /
UCT. In fact, this is most likely already happening as these
Monte-Carlo programs use algorithms / ideas from the traditional
programs for tactics, pattern-matching and possibly others.. And I go
out on a limb to predict that at some point "heavy playouts" will use
information like territory, eye-space and group-strength to guide their
playouts just like the "traditional" programs do. And that using fixed
3x3 patterns will be a passing fad.
My first MC-Program actually used the code from my knowledge intensive
program Viking. Then I rewrote everything from scratch which is
Valkyria2.7. And I am now working with rewriting the search part in
order to allow threaded search and that is Valkyria3.
Since Viking used territory, eye-space etc to compute groupstrength, I
guess I could comment on what I believe can and cannot be used in
heavy playouts.
Valkyria uses eye-space calculations, which prunes really bad moves in
the playouts. My board representation keeps track of all liberties,
and surrounding stones for all chains. It is designed for playouts
(undo is not possible) but a lot of information is computed so that at
it is easy to write "knowledge"-algorithms. It is faster than my old
Vikingcode but still it is much easier to work with.
Valkyria does not do explicit 3x3 patternmatching, but uses handcoded
patternmatching which often are equivalent to 3x3 patterns. But
sometimes the code will look at a larger area. It also computes
ladders in playouts. The ladders are fast and sloppy, that is, in some
situations they make mistakes, but in the playouts one makes (and
should make) compromises with correctness all the time. It is the
UCT-search that should find out how to play correctly not the playouts.
My program as a consequence is probably the slowest in terms of
playouts/second. It does about 1200/sec on 9x9 on Pentium-M 1.4Ghz.
The good thing is that the code is so bloated I do not slow it down so
much when I add new stuff to the playouts. I recently found a lot of
bugs working with version 3 so I added that to the 2.7.8 which has
been rated about 40-60 Elo higher than 2.7.7.
I do not think that territory and groupstrength will ever be included
into heavy playouts. Because this is implicitly computet by the
MC-evaluation. Several MC-programs today collects statistics such as
the probability that each position on the board is assigned to black
in the end of playouts. I recently added a colored graph of such
statistics to Valkyria3 and it looks really pretty. You can easily see
what is safe territory or not and which groups are weak and not.
Actually this visualisation is good to hunt for bugs in the playouts.
If a groups is almost dead despite having plenty of eyspace then
something can probably be fixed in the playouts. These kind of
statistics looke quite nice already after as little as 100 playouts,
and are in my opinion better than what I ever achieved with Viking
evaluation function. Most importantly one sees that although
MC-evaluation often misjudges positions, the effect of moves is almost
always goes in the right directions. Traditional statical evaluation
has the problem of being brittle. It does 90% right but 10% completely
wrong. MC-eval does 80 % right and 20% slightly wrong. (I made up
those numbers of course but hope you get the idea)
So computing territory and groups strength in playouts appears to me
as reinventing the wheel because this is what MC-eval actually is
doing implicitely. An open question is to what extent these statistcs
can be used to improve performance in UCT-search or biasing playouts.
I have no clear idea about it because, in some versions of my programs
it was good and sometime it did not. It may be that UCT-search itself
is so efficient that whenever you have reliable statistics for a
position the search does not benefit from that knowledge anymore.
I also agree that some really old techniques do come back. In my first
goporgram for the Amiga I wrote 18 years ago approximately I first
implemented the following pattern
?B?
W+W
?B?
and variations thereof. When I first made the playouts heave this was
the first patterns I added, and it worked really well. So the irony is
that my current programs have more in common with my very first
completely stupid program than the versions in between...
-Magnus
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/