gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] SlugGo approach


From: David G Doshay
Subject: Re: [gnugo-devel] SlugGo approach
Date: Mon, 6 Sep 2004 19:55:35 -0700

All input is welcome. Our biggest problem is having the time and human
resources to implement all the things we think about.

Perhaps when we are done restructuring our code and adding some
more desirable logic we will devote some of the cluster to on line play.
So far we have wanted to collect enough data to get a feel for how strong
SlugGo is. But for the next few months I think the cluster will be doing
some physics.

Thanks,
David

On Sep 6, 2004, at 6:58 PM, Evan Daniel wrote:

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


_______________________________________________
gnugo-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnugo-devel






reply via email to

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