[Computer-go] Chess vs Go // AI vs IA
gcp at sjeng.org
Tue Jun 1 23:12:54 PDT 2010
Dave Dyer wrote:
> By contrast, there are no obvious evaluation metrics that work for Go,
Really? Sampling the board position in playout games seems quite
effective, about as effective as a static evaluation in chess. It's a
bit slower, but that is just one constant factor in speed.
> and the
> search tree is impossibly large.
What is "impossibly large"? It's not like a chess program can see to the
end, either. I don't see a fundamental difference here. It's a bit
bigger, so the programs are relatively weaker compared to humans, but
not more than that.
> Advances in computer speed have not,
> and arguably never will make the same simple, brute force methods that
> work for Chess suitable for Go.
Howso? There is no significant difference between an alpha-beta search
with heavy LMR and a static evaluator (current state of the art in
chess) and an UCT searcher with a small exploration constant that does
playouts (state of the art in go).
The shape of the tree they search is very similar. The main breakthrough
in Go the last few years was how to backup an uncertain Monte Carlo
score. This was solved. For chess this same problem was solved around
the time quiescent search was developed.
Both are producing strong programs and we've proven for both the methods
that they scale in strength as hardware speed goes up.
So I would say that we've sucessfully adopted the simple, brute force
methods for chess to Go and they already work without increases in
computer speed. The increases will make them progressively stronger
though, and with further software tweaks they will eventually surpass
More information about the Computer-go