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 humans. -- GCP _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
