Re: [gnugo-devel] SlugGo approach (was: endgame module for GNU Go)

[Evan Daniel]

On Mon, 6 Sep 2004 18:32:25 -0700, David G Doshay <address@hidden> wrote:
> 
> On Sep 18, 2004, at 3:55 PM, Xavier Combelle wrote:
> 
> > I have some idea about improving
> > the sluggo approach, for example. But I can't give any garantee that
> > my ideas are right.
> 
> As the driving force behind SlugGo, I can assure you that the approach
> is easily improved. We did some very simplistic things. From my
> perspective, the important news is: things which are logically weak, or
> at the very least far less than optimal, made the base program much
> stronger, seemingly about 4 stones.
> 
> SlugGo is a research project and I am open to sharing ideas. We are
> just starting to write a paper for publication.

Let me first say that I find your work very interesting and
impressive.  Congratulations.

I did a modest amount of work with something similar on 9x9 boards,
and met with modest success.  Mostly I worked with lower branch
factors, and I didn't really do any real data taking against other
opponents.  That said, I have a couple suggestions if you're
interested.

When branching at depth > 0, I found (err.. it felt like; no data
here) that it was more effective to branch on the main line and not
everywhere.  So I would take say 2 branches at depth 0, then 2
branches at depth 1 off the first choice move, ditto at depth 2, but
not continue branching off the second choice moves.  So this involved
investigating 4 lines of play, and branched at depth 0,1, and 2 on the
main line.  If the move choice was then not the original first choice,
I would repeat to make sure that the main line actually had the
specified branches.  My limited experience was that this tended to
capture most of the benefit of uniform branching without as much cost.

My other major suggestion was that you incorporate an opening book
involving human play, even if it is machine-evaluated.  I found that
on 9x9 boards that the play strength greatly improved anywhere I
simply presented the metamachine with correct moves to look at, it
could figure out which to play, even in the presence of some noise. 
So if your code is amenable and you have the compute cycles to spare
(which it sounds like you do) you might try creating a tree several
moves deep that is the union of a large number of reasonably
high-level games and let your metamachine evaluate it.

I would also reiterate the suggestion that you play on one of the
turn-based servers (Dragon Go Server and Little Golem are the big
ones) as a way to find human opponents who don't need speed.

Good luck; I'll be watching with interest.

Evan Daniel