[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David G Doshay
Subject: Re: [gnugo-devel] SlugGo v.s. Many Faces
Date: Wed, 25 Aug 2004 10:30:10 -0700

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:

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

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


  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]