>Doesn't the simple mathematics of why go is difficult make the 'faster hardware' topic a small issue?
That's what the simple math says, but the complex math says that UCT is asymptotically optimal! Since math is internally consistent, it must be that increasing speed does help and the simple math is going wrong somewhere. MCTS is a selective search algorithm. The effective branching factor is very small. At most nodes you have only a handful of moves that are searched at all. Most of the nodes that are searched receive only a few trials. Increasing speed improves the outcome in two ways. First, you have more time to examine the better moves more deeply. Second, you can expand more moves at each node. A third potential advantage is to keep the tree the same size and do better analysis. That is, use the speed to reduce the error rate. If this is done by having heavy knowledge then the solution is not scalable. But you can also create online learning algorithms that improve analysis, which could be scalable. The problems that cause MCTS to "hit a wall" usually have to do with the RAVE heuristic, which is the preeminent selective method. If you start by disliking the best move, and the RAVE heuristic collects bad results for that move, then it could "never" get a trial. One of the problems is that as you scale the search you are also scaling the data collected by RAVE, so it becomes more convinced that the move is bad. There are solutions for this, though. Fuego simply "turns off" RAVE for a small fraction of trials. Another solution: don't use RAVE. I recall that Crazy Stone does not use RAVE. Maybe its static move ordering is really good, and Remi doesn't want to "mess it up." If static move ordering is good enough, then you can get a scalable search by admitting N moves at trial f(N) where f grows exponentially. Brian _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
