Re: [gnugo-devel] SlugGo v.s. Many Faces

[Gunnar Farnebäck]

David wrote:
> The primary reason the code is so very slow is that we have found a
> lookahead depth of 16 works very well, and it thus takes a bit more
> than 16 times as long as GNU Go to settle on its move.

Do you have any statistics on how many GNU Go genmove() calls you do
at most and on average per move?

> We have been encouraged by our success against the GNU Go base code,
> where we can win about 70% of the games when giving GNU Go a 5 stone
> handicap, but were worried that our success was primarily the result
> of our correctly guessing the responses to our move choices because
> they are all generated by GNU Go, that is to say that we know
> exactly how our opponent thinks.

There can be no question that this is a part of what you're seeing.

> We are now confident that we are indeed much stronger than GNU Go
> because of our results against Many Faces of Go.

That's interesting to know.

> A very complicated endgame board where perhaps White wins by 76, but
> if play were to resume again perhaps black could pull off a win by
> something like 20. I have not worked this one out completely.

If this is the position in the game record slugGo010.sgf, it is
objectively a white win by 76. The top center white group is locally
alive in seki (*) but the black group in the top left corner has no
chance to get more than one eye and is dead, thereby dissolving the
local seki and all black stones in the area dies. Of course either or
both programs might misplay in a continuation but if both pass in that
position it's clearly a white win.

(*) If black plays J19 or K16, then white plays the other one. If
black plays F16 then white plays H17. If black plays H17, white
passes. If black gets both H17 and F16 it's still a seki.

> The sgf files for these games can be downloaded from:
> 
>         http://hsrf-mc2.cse.ucsc.edu/~cowboy/mfgo_sluggo.tar.gz

Thanks, those are really interesting. A minor point is that pass
should be encoded B[] and W[], not B[  ] and W[  ].

Some observations about the differences compared to vanilla GNU Go:

* The first few moves are indeed not very good. As long as GNU Go is
  in the full-board fuseki database (move value 75) I would recommend
  just accepting those moves without lookahead. An important benefit
  of this is that it helps increasing the variability of the play.

* Some moves are very solid but quite slow. It's debatable whether
  those really make the program stronger but it's probably effective
  against many computer programs and possibly in handicap games
  against humans. In terms of style those moves feel similar to Go++.

* It has a stronger tendency to take care of weak dragons. The use
  of moves generated for the opponent seems to be part of the reason.

* It also has a stronger tendency to keep pressure on weak opponent
  dragons. I wouldn't say that it does this very systematically but
  it gets in useful moves often enough to make a difference.

* The moves generated for the opponent are not always good. Most
  obvious are "reverse monkey jumps" and one point jumps (where
  opponent wanted to cap) which had better be longer jumps. I would
  guess it's possible to solve this problem by tuning GNU Go to better
  evaluate the kinds of positions these moves lead to.

* It is better at finding and probably also defending against
  combination attacks which are out of reach for GNU Go, like subtle
  connection intransitivities and double threats to cut or invade
  moyo.

* Not surprisingly it retains some of GNU Go's glaring weaknesses. It
  also introduces some new systematic misplays, e.g. playing

  .......
  OOO....
  XXa.*..
  .......
  
  instead of a more appropriate solid bend at 'a'.
  
In summary I think the most important improvement over ordinary GNU Go
is that it's better at taking care of weak groups and finding moves to
put pressure on weak opponent stones. Of course we have long been
aware that this is one of the most important areas to try to improve.
(And if we manage to do that, no doubt SlugGo will benefit further.)

/Gunnar