Re: computer-go: Programs learning to play Go

[Joan Pons i Semelis <joan@xxxxxxxxxxxxxxxx>]

Richard Brown wrote:
> 
> Dave Dyer wrote:
> 
> [sniped on NN comparing backgammon and go]
> 
> >  Go doesn't really fit this model.  Throwing 361 inputs and outputs
> > at a naive network, and expecting it to learn anything, is like
> > throwing a pail of sand into an oven and expecting silicon chips
> > to emerge.  Not fucking likely.
> 
> I agree, but please say "bloody".  This is a family mailing list.

... Ah! that preference for assassination over joyfull sex :-)

> 
> > #1: if you must try a pure learning technique, start with a reduced
> > domain; 3x3 or 4x4 is a good place to start.  Achieve percect play
> > on 4x4, then work your way up.
> 
> You can also reduce the domain by observing only expert play, instead
> of observing random play.

Then you hardly will learn how to play a ladder.
 
> > #2: after you conclude that you'll never get perfect play on a 5x5
> > board because the domain is too complicated (my prediction), adopt
> > a more pragmatic approach.  Explicitly determine the fundamantals
> > of the board (like group size and liberties) and concentrate your
> > learning on things that actually need to be learned.
 
My approach would be the following:

There are 2 problems in computer go: scoring and branching. So:

First get a good enough analysis of what's happening on the board.
This will probably get the answer about who's winning, but it doesn't
matter, what is important is to get data on a per point basis that
is usefull to classify them.

Then try the NN to learn in which of them play the good players.
And when. Last gote point _is_ played because it is a good point ...
at the right time. And use it as a move proposal to reduce the branching
problem.

Rest skipped, I agree with both.

Joan