Re: [gnugo-devel] address@hidden: Re: GNU go and Artificial Intelligence?]

[Arend Bayer]

Generally speaking, go programs are much more closely modelled after the
way a human approaches the game, than chess programs. And this will (IMO)
not change substantially: even a future go program that does a lot of
global search, will have to be very selective about the moves it tries,
and therefore generate an understanding of the go board position _before_
it starts searching.

On Wed, 29 Sep 2004, Paul Pogonyshev wrote:
> > Stanford University, and he told me that go sometimes is characterized as
> > 'the fruit fly of artificial intelligence’, thereby referring to the area
> > of genetics where researches have used fruit flies as a research object.
> > There aim here was obviously not to create the perfect fruit fly, but to
> > contribute to the progress in the field of genetics.

I think in the case of go, possible interactions with AI are more indirect.
Let me give you a toy example where go is used as testbed for a problem
that might be characterized as AI (to me the meaning of AI is pretty
fuzzy, so...). The research group of Prof. Althoefer in Jena, Germany,
has made a couple of experiments (in go and chess) with what they call
"Dreihirn". A human go player is allowed to choose between the two moves
suggested by two go programs. The interesting part of this experiment is
that this group of three players can be stronger than any of the players
alone.
Now the general interest in their research group this experiment is about
computer-aided decision. They claim that in many situations, decisions
are best made not by either a human or a computer alone, but prepared by
the computer and finally made by the human. The fact that this works in
both go and chess gives them some confidence that it will work in other
fields, too. And some problems that turned up in go may also be instructive
when trying to adapt the general method (computer analyzes the problem,
and gives a few alternative solutions) to other situations: E.g. when
doing this experiment with only one program, and the human being allowed
to choose between the two top moves, it works much worse. The reason is
that the two alternatives are too similar in nature; so more generally
when preparing the alternatives, the computer engine has to make sure
that the alternatives are truly different.

While this may be a simple example, I think it illustrates how indirect
knowledge transfer may work.

> > Since my article is for a popular science journal, I am hoping to make my
> > readers relate to the go-subject by using some real world examples on where
> > this kind of techniques could be applicable some time in the future. In the
> > fruit fly-example from before, it is of course hard to determine the exact
> > future usage, but it is not difficult to guess on using genetics for e.g.
> > curing diseases, inventing medicine, developing crops etc. etc.
> 
> Well, in this case GNU Go doesn't seem like a good pick.  I don't
> think any of the techniques used in GNU Go are particularly useful for
> anything else but another game-playing program.

A go program has to solve quite a lot of different problems
(connectivity of stones, life-and-death valuation, territory valuation,
etc.). When any of these problems is solved badly, it doesn't do much
good to solve any of the others in scientific perfection (not that this
would be possible anyway...). So you have to start by something that
works more or less, and robustly so if possible. 

So that's why GNU Go (which is only 6 years old, quite young by the
standards for go programs) has quite a hands-down approach to all these
problems. Whether this will change, I don't know, since you can never
know what works and what doesn't before you try it out.

But there are some problems that we very much fail to deal with so far.
One difficult and very important problem in go (for computers and humans!)
is to assess weak groups. These are groups of stones that cannot be
captured; but the opponent can attack them, make useful moves while
attacking, while the defender has to make slow ineffective moves to make
sure his group does not get captured. And so the attacker gains
territory on the way.

I don't know how GNU Go will try to deal with this problem in 5 years.
Any good judgement of weak groups should have as input some "reading"
(go term for local search) results, some general "influence concept",
and some "shape" ("good shape" is a go term for a locally efficient
formation of stones; an intuitive feeling of good or bad shape is a very
important part of human go skills) judgement. A good solution to this
problem may well involve a neural network, that will need to be
interfaced with specific go knowledge (reading results etc.) to do well.

Arend