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

[David G Doshay]

On Aug 24, 2004, at 7:18 PM, Gunnar Farnebäck wrote:

> 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?

It takes 2 parallel calls to genmove() to build the candidate list. 
Every candidate
move results in (lookahead depth - 1) more calls to genmove(). Each 
candidate
move's lookahead sequence takes place on an independent cpu, so wall 
time
is equal to that of the slowest sequence.

There are many ways of looking at the move statistics, and we sometimes
debate about which way is most useful. There are two interesting 
overlapping
distributions: How many candidate moves are considered and the move
selected for each length of the candidate list. I will report what we 
know when
we know it.

> >  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.

Yes, this is the game.  I did think that if both passed then the win 
should
go to White. I must have been tired when I looked at this the first 
time.
I could not read out if there might be a sequence where black plays for
the dead interior shape at H17 and when white passes black then attacks
outside to cause a shortage of liberties. I see now that the inside 
liberties
at J19 and K16 prevent that from working for black.

> > 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[  ].

We will fix that. Thanks.
> 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.

I am quite sure that we could do that for 10 moves without question.

> 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.

Yes, I felt that the THEIR moves could alert us to urgent threats. In
addition to everything I mentioned before, we also have a boosting
function that adds value for moves in the US lists or when on or very
near a move in the THEIR list.

> * 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.

That is what a slightly stronger player does too ...

> * 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.

We recognize this and need to fix it. I know that the problem is in the
boost code, which was not written the way I had asked. But I have been
busy with other things and have not gotten around to this yet. We beat
back a number of other more embarrassing end game mistakes before
taking on Many Faces, but I felt it OK to go public with this still 
unrepaired.

> * 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.

I think to get these even better we need to branch in the lookahead
paths. We have the cpus to do more, but we decided to gather 100
game sets at a number of width/depth combinations before increasing
the branching factors.

> * 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.)

Thanks much for your observations and feedback.

Just to make things clear, we will eventually be willing to put our code
into the GNU Go repository if you wish it. I doubt you do right now and
I do not think our code is ready yet. There are other problems beyond
what was covered above, and we want to improve what we are aware
of before we open up all of our code. Also, on a single cpu box SlugGo
would be rather painfully slow.

Cheers,
David