| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In this chapter we will discuss methods of finding out how GNU Go understands a given position. These methods will be of interest to anyone working on the program, or simply curious about its workings.
In practice, most tuning of GNU Go is done in conjunction with maintaining the `regression/' directory (see section 20. Regression testing).
We assume that you have a game GNU Go played saved as an sgf file, and you want to know why it made a certain move.
5.1 Interpreting Traces Analyzing traces in GNU Go 3.6 5.2 The Output File 5.3 Checking the reading code 5.4 Checking the Owl code Checking the owl code 5.5 GTP and GDB techniques 5.6 Debugboard 5.7 Scoring the game Finding out the winner of the game 5.8 Colored Display
A quick way to find out roughly the reason for a move is to run
gnugo -l filename -t -L move number |
(You may also want to add `--quiet' to suppress the copyright message.) In GNU Go 3.6, the moves together with their reasons are listed, followed by a numerical analysis of the values given to each move.
If you are tuning (see section 9.11 Tuning the Pattern databases) you may want to add the `-a' option. This causes GNU Go to report all patterns matched, even ones that cannot affect the outcome of the move. The reasons for doing this is that you may want to modify a pattern already matched instead of introducing a new one.
If you use the `-w' option, GNU Go will report the statuses of worms and dragons around the board. This type of information is available by different methods, however (see section 5.6 Debugboard, see section 5.8 Colored Display).
If GNU Go is invoked with the option `-o filename' it will
produce an output file. This option can be added at the command line
in the Go Modem Protocol Setup Window of CGoban. The output file will
show the locations of the moves considered and their weights. It is
worth noting that by enlarging the CGoban window to its fullest size
it can display 3 digit numbers. Dragons with status DEAD are
labelled with an `X', and dragons with status CRITICAL are
labelled with a `!'.
If you have a game file which is not commented this way, or which was produced by a non-current version of GNU Go you may ask GNU Go to produce a commented version by running:
gnugo --quiet -l <old file> --replay <color> -o <new file> |
Here <color> can be 'black,' 'white' or 'both'. The replay option will also help you to find out if your current version of GNU Go would play differently than the program that created the file.
The `--decide-string' option is used to check the tactical reading code
(see section 11. Tactical reading). This option takes an argument, which is a location
on the board in the usual algebraic notation (e.g.
`--decide-string C17'). This will tell you whether the reading code (in
`engine/reading.c') believes the string can be captured, and if so,
whether it believes it can be defended, which moves it finds to attack or
defend the move, how many nodes it searched in coming to these
conclusions. Note that when GNU Go runs normally (not with
`--decide-string') the points of attack and defense are
computed when make_worms() runs and cached in
worm.attack and worm.defend.
If used with an output file (`-o filename') `--decide-string' will produce a variation tree showing all the variations which are considered. This is a useful way of debugging the reading code, and also of educating yourself with the way it works. The variation tree can be displayed graphically using CGoban.
At each node, the comment contains some information. For example you may find a comment:
attack4-B at D12 (variation 6, hash 51180fdf) break_chain D12: 0 defend3 D12: 1 G12 (trivial extension) |
This is to be interpreted as follows. The node in question
was generated by the function attack3() in `engine/reading.c',
which was called on the string at D12. The data in
parentheses tell you the values of count_variations and
hashdata.hashval.
The second value ("hash") you probably will not need to know
unless you are debugging the hash code, and we will not discuss it.
But the first value ("variation") is useful when using the debugger
gdb. You can first make an output file using
the `-o' option, then walk through the reading with
gdb, and to coordinate the SGF file with the debugger,
display the value of count_variations. Specifically,
from the debugger you can find out where you are as follows:
(gdb) set dump_stack() B:D13 W:E12 B:E13 W:F12 B:F11 (variation 6) |
If you place yourself right after the call to trymove()
which generated the move in question, then the variation number
in the SGF file should match the variation number displayed by
dump_stack(), and the move in question will be the
last move played (F11 in this example).
This displays the sequence of moves leading up to the variation
in question, and it also prints count_variations-1.
The second two lines tell you that from this node, the function
break_chain() was called at D12 and returned 0 meaning
that no way was found of rescuing the string by attacking
an element of the surrounding chain, and the function
defend3() was called also at D12 and returned 1,
meaning that the string can be defended, and that
G12 is the move that defends it. If you have trouble
finding the function calls which generate these comments,
try setting sgf_dumptree=1 and setting a breakpoint in
sgf_trace.
You can similarly debug the Owl code using the option `--decide-dragon'. Usage is entirely similar to `--decide-string', and it can be used similarly to produce variation trees. These should be typically much smaller than the variation trees produced by `--decide-string'.
You can use the Go Text Protocol (see section 19. The Go Text Protocol) to determine
the statuses of dragons and other information needed for
debugging. The GTP command dragon_data P12 will list
the dragon data of the dragon at P12 and
worm_data will list the worm data; other GTP
commands may be useful as well.
You can also conveniently get such information from GDB. A suggested `.gdbinit' file may be found in See section 11.9 Debugging the reading code. Assuming this file is loaded, you can list the dragon data with the command:
(gdb) dragon P12 |
Similarly you can get the worm data with worm P12.
A useful utility called debugboard is made in
the `interface/debugboard/' directory. This can be run
in an Xterm. Use a smaller font since it requires 50 rows
and 80 columns. This runs examine_position(), then
makes a graphical display of the board. Using the cursor
movement keys, you can move around the board and find
out the contents of the worm, dragon and eye arrays.
GNU Go can score the game. Normally GNU Go will report its opinion about the score at the end of the game, but if you want this information about a game stored in a file, use the `--score' option (see section 3.9 Invoking GNU Go: Command line options).
Various colored displays of the board may be obtained in a color
xterm or rxvt window. Xterm will only work if xterm is
compiled with color support. If the colors are not displayed on your xterm,
try rxvt. You may also use the Linux console. The colored display
will work best if the background color is black; if this is not the case you
may want to edit your `.Xdefaults' file or add the options
`-bg black -fg white' to xterm or rxvt.
On Mac OS X put setenv TERM xterm-color in your `.tcshrc'
file to enable color in the terminal.
You can get a colored ASCII display of the board in which each dragon
is assigned a different letter; and the different matcher_status values
(ALIVE, DEAD, UNKNOWN, CRITICAL) have different
colors. This is very handy for debugging. Actually two diagrams are generated.
The reason for this is concerns the way the matcher status is computed.
The dragon_status (see section 7.5 Dragons) is computed first, then for some, but not
all dragons, a more accurate owl status is computed. The matcher status is
the owl status if available; otherwise it is the dragon_status. Both the
dragon_status and the owl_status are displayed. The color scheme is as
follows:
green = alive cyan = dead red = critical yellow = unknown magenta = unchecked |
To get the colored display, save a game in sgf format using CGoban, or using the `-o' option with GNU Go itself.
Open an xterm or rxvt window.
Execute gnugo -l [filename] -L [movenum] -T to get the colored
display.
Other useful colored displays may be obtained by using instead:
Instead of `-T', try this with `-E'. This gives a colored display of the eyespaces, with marginal eye spaces marked `!' (see section 8. Eyes and Half Eyes).
The option `-m level' can give colored displays of the various quantities which are computed in `engine/moyo.c'.
GNU Go contains two distinct implementations of the concepts of Territory,
Moyo and Area (see section 13.2 Territory, Moyo and Area). Primarily GNU Go computes
Territory, Moyo and Area using the influence code, and reports them
with the functions whose_territory(), whose_moyo() and
whose_area(). To get a colored display of the influence regions
found by this module, use `-m 0x18' to see the initial influence,
and e.g. `-m 0x10 --debug-influence D5' to see the influence
after having made the move D5. There are various other options available
for numerical displays influence; for a detailed description see
13.13 Colored display and debugging of influence.
The regions found by Bouzy's algorithm (see section 14. Another approach to Moyos : Bouzy's 5/21 algorithm) are
used only in the function estimate_score(). These can be
displayed with the following options:
`-m level'
use or (hexadecimal) cumulative values for printing these reports :
1 0x01 ascii printing of territorial evaluation (5/21)
2 0x02 ascii printing of moyo evaluation (5/10)
4 0x04 ascii printing of area (4/0)
|
The `-m' options can be combined by adding the levels.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |