Building Opening Books for 9 · · · · 9 Go Without Relying on Human Go Expertise

: Problem statement: Expert level opening knowledge is beneficial to game playing programs. Unfortunately, expert level opening knowledge is only sparsely available for 9 · 9 Go. We set to build expert level opening books for 9 · 9 Go. Approach: We present two completely different approaches to build opening books for 9 · 9 Go without relying on human Go expertise. The first approach is based on game outcome statistics on opening sequences from 300,000 actual 9 · 9 Go games played by computer programs. The second approach uses off-line stage-wise Monte-Caro tree search. Results: After “solution tree” style trimming, the opening books are compact and can be used effectively. Testing results show that GoIntellect using the opening books is 4% stronger than GoIntellect without the opening books in terms of winning rates against Gnugo and other programs. In addition, using an opening book makes the program 10% faster. Conclusion: Classical knowledge and search approach does not work well in the game of Go. Recent development in Monte-Carlo tree search brings a breakthrough and new hope-computer programs have started challenging human experts in 9 · 9 Go. A well constructed opening book can further advance the state of the art in computer Go.


INTRODUCTION
The classical full board search paradigm has produced programs stronger than human expert players in a number of games such as Chess, Checkers and Othello. Yet this classical approach failed miserably in Go, since good Go knowledge does not translate to good evaluation function to be used by mini-max style full board game tree search (Chen, 2003). The playing strength of programs for 19×19 and 9×9 Go stuck at intermediate amateur level until the recent development of Monte-Carlo Tree Search (MCTS) (Coulom, 2007a;Gelly et al., 2006;Kocsis and Szepesv'ari, 2006), which bypassed the need of static evaluation functions and brought a breakthrough in computer Go. Much additional work has been done on MCTS and its enhancement in recent years (Chaslot et al., 2007;Coulom, 2007b;Gelly and Silver, 2007).
Opening books are common in computer game playing (Buro, 1999;Lincke, 2000). The playing strength of 9×9 Go programs can be further enhanced by using expert level opening books. Unfortunately, there are no publicly available expert opening books for 9×9 Go. Even 9×9 Go game records by professional experts are scarce, not enough available for building opening books. We propose two approaches to build 9×9 Go opening books without relying on human Go expertise. The first approach is based on game outcome statistics on opening sequences from 300,000 actual 9×9 Go games played by computer programs. Top 9×9 Go programs can now challenge human experts. We discuss the details of this approach and described how to use such an opening book in a 9×9 Go program. We also discuss a second approach of using off-line stagewise Monte-Caro tree search. The testing results of using the constructed opening books are, which shows GoIntellect using the opening books is 4% stronger than GoIntellect without the opening books in terms of winning rates against Gnugo. In addition, using an opening book makes the program 10% faster.

MATERIALS AND METHODS
We shall discuss the details of our approach in this study.

Fig. 1: Equivalent opening move sequences
Canonical orientation of a game: We call a sequence of moves of any length starting from the empty Go board an opening move sequence. An opening move sequence (including a whole game) can have equivalent move sequences in 8 different orientations. For example, the following 8 opening move sequences are all equivalent (Fig. 1) In building an opening book, we should combine the outcome statistics of all extension games from each of the 8 equivalent initial move sequences. We don't need to consider color flip here, since Black always plays first in Go.
Let B be the set of all 81 points on the 9×9 Go board. We define 8 transformation functions from B to B: f 0 : Identity function mapping every point to itself f 1 : Rotate clockwise 90° f 2 : Rotate clockwise 180° f 3 : Rotate clockwise 270° f 4 : Reflection with respect to the vertical center line f 5 : f 1 followed by f 4 f 6 : f 2 followed by f 4 f 7 : f 3 followed by f 4 Applying f 0 -f 7 to each move in the move sequence in the upper left diagram of Fig. 1, we get all the equivalent variations in Fig. 1.
This short opening move sequence has its location type sequence <c 1 , p 5 , a 4 >. We call the sequence of the subscripts, <1, 5, 4> in this example, its location type index sequence (Table 1). We shall use this index sequence to identify the canonical form of a move sequence.  A move sequence can have up to 8 equivalent move sequences under rotation and reflection (through a transform function f0-f7 on every element of the sequence). We call the one with lexically smallest location type index sequence its canonical form. Considering the earlier example opening move sequence S = <E5, D3, C5>, we have one hundred and twelve is the smallest location type index sequence, so the canonical form of S is <E5, F7, G5>, Fig. 4, which can be obtained via function f 2 (rotate clockwise 180°). We call f2 the canonical transformation for the move sequence <E5, D3, C5>. The canonical transformation converts a move sequence to the equivalent sequence in the canonical form.
The original sequence can be reconstructed via f 2 −1 (= f 2 ). In this example, the canonical transformation can be determined when move 2 is played. A sufficient condition to determine a unique canonical transformation for any extension of an opening sequence is a move at a pie point.
Only about 1/8 of the actual games are in canonical form. Before we merge them into a big opening tree, we should convert them into canonical form, so we can collect all relevant statistics together for the equivalent opening move sequences.

Merge games into a tree:
It would be ideal to use 9×9 games played by human Go experts to build an opening book. Unfortunately the available professional 9×9 games are rather limited. So we use 9×9 games played by computer Go programs instead. We have over 300,000 testing games of GoIntellect against GnuGo, CrazyStone, Mogo and older versions of GoIntellect plus thousands additional 9×9 games down loaded from KGS on the Internet.
All the games were in sgf format. We wrote a script to process the games one at a time. For each game, we first let GoIntellect to step through all moves in the game to reach the end configuration, then count the territory score (we use Chinese rule with 7.5 points komi) and record the win/loss result. Then find its canonical transformation by applying all transform functions to moves one at a time until the canonical orientation is determined (usually after examining no more than first 3 moves). We apply the canonical transformation to moves up to the depth limit of opening book tree; we use 16 as the limit and get an opening sequence in canonical form.
A node in the opening tree needs to record the move location plus the move/player information (we code every board location into a number and use + number for Black move,-number for White move), the number of games passing through the node and the number of winning games (say from the node move player's point of view) passing through the node. We initialize the tree, in sgf form, by using the first game. We merge a new opening sequence into the growing opening tree by tracing its move sequence (in canonical form) through the tree until it goes off the tree, then we augment the tree by attaching a branch from the node for the remaining opening move sequence in the game.
The C-like pseudo code for building an opening book from game records is shown in Fig. 5. We choose tree rather than graph as underlying data structure for the opening book for two reasons. First, it is much more efficient to build a tree from game records than to build a graph. Second, sometimes the path leading to a node affects the set of legal moves at the node (ko status).
Due to the limitation on the memory, we can't just build a giant game tree of 300,000 games. We have to trim game trees before they get too big, then merge trimmed trees together. We developed a procedure to merge many opening trees into one big opening tree, so we can build it a reasonable size piece at a time. Several opening books can be merged into one via the pseudo code in Fig. 6.
Trim an opening tree to an opening book: We can trim move beyond opening depth, if we did not do so before the game merging. Also we can trim away any node with fewer than a threshold number of games passing through, we use 20 as the threshold, so the remaining nodes are more reliable. At this point, nodes with very low winning rates, say less than 25%, can be pruned, since they are likely to be bad moves. If we are to play, we will never choose it. If the opponent selects this bad move, we probably can win without using the opening book. A sorting routine was programmed to order the children of a node according to winning rates for the whole tree providing convenience in tree manipulations.
Assume we play Black, then at each node black is to play next, we just need to keep small number of best successors and trim the rest sub-trees. In that way, we can get a compact "solution tree" opening book with size shrunk by 1000 fold. Similarly we can create a "solution tree" for White. Merging Black "solution tree" and White "solution tree", we get an opening book that can be used by either Black or White. The sgf opening tree we produced after merging 300,000 games before trimming was several hundred mega bytes in size. The final working opening tree is about 60 K bytes containing about 3000 moves.

Practice:
We shall show how to make opening book moves in 9x9 Go matches. And we introduce an alternate approach of building an opening book for 9x9 G0.

Use of the opening book:
The opening book is a sgf game tree containing only move sequences in canonical form. The players may play moves in any orientation. To use the book, we keep 8 tree-node pointers p 0 , p 1 , p 2 ,…, p 7 , where p i points to the node of which the move sequence from the root to it is a move sequence in canonical form <f i (m 1 ), f i (m 2 ),…, f i (m k )> where <m 1 , m 2 ,…, m k > is the actual move sequence of on the board so far, if such a node exists, otherwise p i is null. The 8 pointers are initialized to point to the root of the opening book tree, which corresponds to the empty 9×9 board. When an actual move m is played on the board by either side, for each non-null p i , we advance the pointer p i to point to the successor node containing the move f i (m) if such successor exists; otherwise p i becomes null.
When it is our turn to play and at least one p i is not null, our book move selection is to consider all successor nodes of all nodes pointed by a p i and pick the successor with highest winning rate. We also take the confidence factor into consideration-the more games through it the better. If the winning rate is below a threshold (45% in our implementation), we give up the book move and go back to MCTS. If the winning rate is high enough, get the node move m1 of the best child of the selected node pointed by p i . f i −1 (m 1 ) will be our book move to play on the board. When all 8 p i 's become null, the game is out the opening book. We shall discuss building opening books using stage-wise off-line MCTS.

Off-line stage-wise Monte-Carlo tree search:
We shall discuss building opening books using off-line stage-wise MCTS. The basic idea is to run the program's MC tree growing engine, i.e., UCT algorithm, days and nights to build a huge Monte-Carlo Search Tree (MCST) then take the top part as an opening book. But this basic idea has a drawback: as the tree gets bigger and bigger, the UCT algorithm will play the best move exponentially more often than the rest moves. It more or less converges to the "principle variation" path. A book should be able to provide moves responding to opponent's suboptimal play. To remedy this drawback, we use the following stage-wise strategy to combine many separate MC search trees into one big opening tree. We first did 20 million simulations from the empty board position trying only moves in canonical orientation, which took about a half hour. We identified the top 6 opening moves based on winning rates. For each of the 6 candidate opening first move, we played a Black stone on the board at the position, then start a new MCTS to grow a new MCST. For each such MCST generated, we identified 3-5 top responses and grew a new set of MCSTs with first two moves already placed on the board. We then developed the next set of MC trees with first three moves specified. This process could go on many levels. We only selectively got to no more than 4 levels. We performed 20 million simulations for each MCST. Then we trimmed and merged them and then trimmed it again to form an opening book tree. Since we would like to store and reload MC search trees for later use. We used a compact text format to store essential information of a MC Search Tree (MCST).

RESULTS AND DISCUSSION
We tested the effectiveness of an opening book constructed from over 300 thousand actual games and another opening book generated from stage-wise offline MCTS against GnuGo 6.0 level 10. The number of simulations per move for GoIntellect (GI) is set to 1,2,4,8,16,32,64,128,256 and 512 K (when it does not have an opening book move or does not use an opening book). For each of the two opening books, for each of the number of simulations per move setting, GI using the opening book played 100 games taking Black and another 100 games taking White and GI without opening book played the same number of games for comparison of the outcomes. A total of 6000 games played on various PCs. The result is summarized in Fig. 7.
The versions of GI using opening book outperformed the version without opening book by about 4% on the average in winning rates. Furthermore, when there is an acceptable opening book move available, the program consumes very little time. The time saved can be used by later moves. GI with opening book typically retrieves 2-6 opening moves from the opening book a game, saving about 10% of the time.
GI with the opening book from actual games performed slightly better than GI with the opening book from off-line MC simulations. The outcome may reverse if we use more simulations for a building block and more layers of building blocks in off-line MC simulation based opening book. Additional testing games played against other programs showed similar playing strength improvements.

CONCLUSION
Opening books can help programs play stronger and faster. When expert knowledge is not readily available, we can build opening books by combining actual games and using the outcome statistics to guide the move selection. The book can be trimmed to a compact size leaving out nonessential portions of the tree. Off-line stage-wise MCTS approach is equally effective. The full board opening book approach is effective in 9×9 Go. But when the size of the Go board increases, the outcome statistics on opening sequences become rather sparse and less reliable. For 19×19 Go, instead of building opening books for the full board, we build opening books for corners, called Joseki dictionaries. We use human expert knowledge in this case-Joseki dictionary books are abundant.
In Joseki dictionaries for corners, we also consider Black and White flip. Each of the 4 corners has 4 different variations of a Joseki from reflection w.r.t. its main diagonal and color flip. So each Joseki has 16 equivalents, 4 for each corner. The same techniques described can be used to play standard corner moves using a Joseki dictionary (a move tree) with 16 Joseki tree node pointers, 4 for each corner. The experience of Go Intellect has been that Joseki dictionaries have little benefit in 19×19 Go matches.