Re: computer-go: Complexity & SW

["Fred Hapgood" <hapgood@xxxxxxxxx>]

> 
> I would say that we do not even begin to understand how humans play
> go. Your assumption of pattern matching has obviously something to do
> with it, but is not at all the whole story.

On a 1 dan level it is, whether you measure by resource allocation
or R&D manhours.

The trailblazing work on pattern matching was done by Reuben Fine 
-- a great chessplayer, a world champion, and a psychologist -- in 
the 1950's.  (He figured out that a world champion probably 
remembers 50K patterns; weaker players of course remember fewer 
and the patterns they do remember are not as useful.)  While Fine's 
research was in the context of chess, no go player reading his work 
could fail to see the many parallels with this game.  Read Fine 
yourself if you doubt me.  Read him even if you don't.

>  Also, it is far from sufficient to "have" the better patterns, if one can not use them.
> Make a beginner play with a joseki dictionary, and see what a bad
> opening he is likely to play anyway.

"Having" *means* being able to use them.

> > I see nothing about chess to lead me to think that the task of
> > building a machine good enough to beat a chess master is any easier
> > than building one to beat a 1 dan amateur.
> 
> I can see some:
>   - It is possible to play chess with a simple evaluation function,
>     even down to just counting pieces. Not master-level chess perhaps,
>     but a reasonable game. 

Sure, but the premise is a 1 dan versus a master-level program.  In
that context the design perspectives and problems are the same.

>   - Go has so much larger branching factor that global look-ahead can
>   not be done to any serious depth. In many positions there are many
>    plausible moves to consider.

The branching factors of master-level chess and master-level go
are perfectly identical in that both are too big to think about exploring
directly.

Go programming has much to learn about the fundamentals of 
pattern representation from chess (and more all the time).
In turn, I suspect that really strong chess programs -- programs
that can beat the world champion in ten game matches every single 
time regardless of time controls  -- might well only be attained by 
leveraging work yet to come in go programming.

It's no coincidence that people who play chess well often play go 
well, and vice versa.

Read Fine and all will be clear.

Fred



Fred
www.pobox.com/~fhapgood