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

Re: computer-go: A problem with understanding lookahead



I still disagree strongly.

I can write a chess evaluator that will take milliseconds to evaluate
a position, and will play well enough to play credibly against human novices
without any additional search.  Roughly, I'll count material, number of threat
inputs to each space, threat outputs from each piece, and immediate king
safety. This will be good enough to favor capturing material, detect threats, 
avoid overloading pieces, and discover simple forks and uncovered attacks. 

I'm pretty sure than any expert in the field would agree that these
are the fundamentals, and then go on to name more aesoteric concepts
to be added.   Just the simple fact that I can name these off the top
of my head, and readily see how to implement them, should demonstrate
that the framework is well understood.

The easily computed quantities that a Go evaluator can use (liberties, 
group size, geographical influence) are laughably bad as evaluators; 
and moving beyond these obvious elements is uncharted territory. The
best Go programs have made some progress, especially using patterns,
but the progress has been painfully slow; and based on ad-hoc algorithms
rather than a sound theoretical framework.

The fundamental difference is that in chess, if you use simple concepts 
such as I outlined, you can understand a position and tell who is winning
a large percentage of the time.  In Go, you undersand NOTHING until you 
have decided which stones are dead, and that is a fundamentally hard
problem.