Re: [gnugo-devel] endgame module for GNU Go

[Gunnar Farnebäck]

Eric wrote:
> Not really sure what you mean by this, but I'll take a
> stab at it:
> 
> The Semsyn engine itself has already been completed,
> and is proprietary. However, most planning systems
> being developed these days adhere to the "standard"
> PDDL (Planning Domain Definition Language) which
> originated from Yale University.
> 
> If GNU Go treats the planner as a black box, then it
> is not necessary to distribute the planner as integral
> to the GNU Go engine. Users of GNU Go can simply
> "plug-in" their favorite flavor of planner.
> 
> The bulk of the work being proposed currently involves
> writing the endgame module and modelling the Go
> domain, i.e. designing the domain operators. And yes,
> I intend to leave these pieces in the public domain
> (or free, or whatever is the proper terminology).
> 
> If I did not answer your question, then please ask me
> again.

The point here, as others already have commented on, is how useful it
will be to us.

To begin with GNU Go is licensed under the GNU GPL. In order for the
result to be redistributable at all, any modifications and additions
must also be licensed under GNU GPL, or certain other compatible
licenses. See http://www.gnu.org/licenses/gpl-faq.html for more
information on what possibilities and restrictions GNU GPL impose.

Second, we only incorporate code in the GNU Go distribution if the
copyrights are assigned to the Free Software Foundation (the
organization around the GNU software).

Naturally we are most interested working with something that can be
included in the GNU Go distribution if it turns out to be sufficiently
useful. This is not to say that other situations would be completely
uninteresting, many of us may for example be interested from a
research point of view, but generally speaking it can be expected to
get a lower priority the less directly we can use it in GNU Go.

It should be noted that while combining GNU Go with proprietary code
gives something that cannot legally be redistributed, it can still be
used privately, e.g. in a research project.

> > How experienced are you at playing go yourself and
> > how skilled are you
> > at evaluating endgame positions "manually"?
> 
> Not very. As with any other application, I need to
> find domain experts who are willing to help out. Know
> of any?

There are several people on this list who would be competent in this
regard. The reason I asked was to get a general idea of at what level
of go knowledge to aim the discussion. It can also help to know at
what level possible misunderstandings are likely to occur.

> I downloaded GNU Go only 3 months ago. Although I have
> spent many hours playing GNU Go since then, as well as
> occasionally logging in to Yahoo Games and playing
> against other humans, the game is still intimidating,
> and there are lots of sleepless nights on the horizon.

Indeed, it does take time to get into the mysteries of strategy and
tactics in go. Most effective is probably to play against other people
face to face, if possible. There are also many good books to learn
from. Specifically if you want to learn traditional wisdom about the
endgame I would recommend the book "The Endgame" by Ogawa Tomoko and
James Davies.

> > > Analogous to the combinatorial game theory approach I
> > > define a dynamic set of local games, e.g. for each
> > > dragon in the current turn of play, the corresponding
> > > local game board is the smallest board surrounding the
> > > dragon in which the dragon can still fit.
> >
> > This didn't quite make sense to me. Maybe you can
> > illustrate with an
> > example in an actual position?
> 
> Translation - draw a square around each dragon.

Ok, that is almost certainly too simplistic to be useful.

> > Endgame is only occasionally about capturing stones
> > but more often
> > about securing and destroying territory. Your
> > description sounds more
> > like life and death analysis. Maybe I've
> > misunderstood something.
> 
> Guilty as charged! There is a lot of work to do here.
> For the meantime, I just want something quick and
> dirty. You know, a "proof of concept" thingy.

Well, it's a fairly important point what it can be used for. Actually
I would expect some kind of planning to come in most naturally in the
opening and the middle game, but it would probably also require
someone with expert knowledge both of go and planning theory to get
anywhere with it.

> If I can get it to work, then I wanna know in months,
> not years. If I cant get it work, then there's no
> point in thinking about it any further.

I think we can agree on this. :-) I would suggest starting with some
very basic examples (of go endgame positions) to get some familiarity
from both sides with how traditional go reasoning would apply and how
planning theory might be used.

/Gunnar