let me know if you follow the discussions on the computer Go mailing list, so I don't send you stuff you might already have read. ________________________________________ From: [email protected] [[email protected]] on behalf of Woody Folsom [[email protected]] Sent: Friday, February 08, 2013 2:08 PM To: [email protected] Subject: Re: [Computer-go] Scoring a go board.
I wrote an AI agent which plays go using a pure Java implementation of UCT-RAVE for my MS project at Georgia Tech. With better data structure optimization I'm relatively sure 10,000s of roll-outs per second, per core, is not an unreasonable goal. Chinese scoring is easier than Japanese but I wouldn't go so far as to say trivial - my initial implementation erroneously counted surrounded dead groups as points! I used no heuristics whatsoever in the roll-out policy, and would recommend getting your MCTS algorithm working with purely random roll-outs first. I also did not explicitly code for avoiding filling the player's own eye, but used Zobrist hashing for super-ko detection and in practice never observed games run into hundreds of moves. I would recommend using a board state data structure which encodes groups (or strings) of stones. Counting liberties recursively consumed 40% of my first agent's total run-time, for negligible memory gains. I did not deal with culling the state tree at all. Finally, (3) above is quite difficult. I am currently attempting to train a neural network which usefully estimates this value by means of temporal difference learning. For more details, feel free to check out my project write-up at http://woodyfolsom.net/blog/?page_id=43. I did not manage much original research since the whole project was done start to finish in one semester, but it covers the basics of MCTS and computer go. On Fri, Feb 8, 2013 at 4:41 PM, Don Dailey <[email protected]<mailto:[email protected]>> wrote: Score a go board using Chinese rules - it is trivial. The basic concept is that you play random moves and (usually) allow no passes until there is nothing else to be done. To prevent eye filling there is a fairly simply but very effective rule that prohibits filling a one point eye - otherwise the game can last for hundreds of moves. That is the "basic" concept. These "playouts" can be greatly improved on with some simple rules and patterns. But there must sitll be some element of randomness and getting this right is subject to a lot of research and is considered a bit of a black art. Even a pretty trivial (uniformly random) playout strategy with the rule not to fill properly constructed one point eyes can give a reasonable evaluation, especially near the end of the game if you view it statistically. For example if you play 1000 of these "random" playouts and black wins 950 of them, black probably really does have a won game. With a little bit of intelligence added to the playout strategy it can become quite good. MCTS basically integrates a best first search with this concept. Don On Fri, Feb 8, 2013 at 4:33 PM, Rémi <[email protected]<mailto:[email protected]>> wrote: surely at any time during a game of go, three passes can be made and the game can be scored... On 8 February 2013 22:31, Rémi <[email protected]<mailto:[email protected]>> wrote: If there really is a difference between (1) and (2) then I have always been completely oblivious to it. For your third (3) case I again see not what the difference is. On 8 February 2013 22:02, Nick Wedd <[email protected]<mailto:[email protected]>> wrote: On 08/02/2013 20:34, Rémi wrote: Hy, There are a lot of interesting papers on UCT and selection strategies ... But it's harder to find information about the more 'pragmatic' side of computer-go. How do you score a go board? What do you mean by "score a go board"? I can think of three reasonable possibilities. (1.) Count the score in a game that is over. (2.) Count the score in a game that is not over, but both players have passed because they think it is. (3.) Count the score in a game that is still being played. (1) is difficult but practicable. (2) is similar to (1), so long as you are not bothered about the result being meaningful, but just want to calculate the score as a referee might if asked to score a game in which both players have passed prematurely. (3) is as difficult as playing Go perfectly. Nick What would be a faster algorithm to score a go-board? Could you pre-calculate and accumulate some information early in the game (on every move), knowing you're going to evaluate the board many times? When do you decide to finish/score the game? Also, what are some of the languages used besides C(++)? Does anyone work in something like java or a functional language? Rémi de Zoeten. _______________________________________________ Computer-go mailing list [email protected]<mailto:[email protected]> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go -- Nick Wedd [email protected]<mailto:[email protected]> _______________________________________________ Computer-go mailing list [email protected]<mailto:[email protected]> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go _______________________________________________ Computer-go mailing list [email protected]<mailto:[email protected]> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go _______________________________________________ Computer-go mailing list [email protected]<mailto:[email protected]> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
