Next: Editing Patterns, Previous: Ladders in Joseki, Up: Patterns
GNU Go uses a special matcher for joseki patterns. It has certain constraints on the patterns it can match, but is much faster and takes far less space to store patterns than the standard matcher.
Patterns used with corner matcher have to qualify the following conditions:
shape(x)
. This is not because the matcher cannot handle other
values in principle, just they are currently not used in joseki databases.
Corner matcher was specifically designed for joseki patterns and they of course satisfy all the conditions above. With some modifications corner matcher could be used for fuseki patterns as well, but fullboard matcher does its work just fine.
The main idea of the matcher is very same to the one of DFA matcher (see Pattern matching with DFA): check all available patterns at once, not a single pattern at a time. A modified version of DFA matcher could be used for joseki pattern matching, but its database would be very large. Corner matcher capitalizes on the fact that there are relatively few stones in each such pattern.
Corner pattern database is organized into a tree. Nodes of the tree are called “variations”. Variations represent certain sets of stones in a corner of the board. Root variation corresponds to an empty corner and a step down the tree is equivalent to adding a stone to the corner. Each variation has several properties:
By corner area we define a rectangle which corners are the current corner of the board and the position of the stone (inclusive). For instance, if the current board corner is A19 then corner area of a stone at C18 consists of A18, A19, B18, B19, C18 and C19.
Variation which is a direct child of the root variation matches if there is any stone at the variation position and the stone is alone in its corner area.
Variation at a deeper level of the tree matches if there is a stone of specified color in variation position and the number of stones in its corner area is equal to the number specified in variation structure.
When a certain variation matches, all its children has to be checked recursively for a match.
All leaf variations and some inner ones have patterns attached to them. For a pattern to match, it is required that its parent variation matches. In addition, it is checked that pattern is being matched for the appropriate color (using its variation “stone color” field) and that the number of stones in the area where the pattern is being matched is indeed equal to the number of stones in the pattern. The “stone position” property of the pattern variation determines the move suggested by the pattern.
Consider this joseki pattern which has four stones:
------+ ......| ......| .O*...| .XXO..| ......| ......|
To encode it for the corner matcher, we have to use five variations, each next being a child of previous:
Tree level | Position | Color | Number of stones
|
1 | R16 | “same” | 1
|
2 | P17 | “same” | 1
|
3 | Q16 | “other” | 2
|
4 | P16 | “other” | 4
|
5 | Q17 | “same” | 1
|
The fifth variation should have an attached pattern. Note that the stone color for the fifth variation is “same” because the first matched stone for this pattern is `O' which stands for the stones of the player to whom moves are being suggested with `*'.
The tree consists of all variations for all patterns combined together. Variations for each patterns are sorted to allow very quick tree branch rejection and at the same time keep the database small enough. More details can be found in comments in file mkpat.c
Corner matcher resides in matchpat.c in two functions:
corner_matchpat()
and do_corner_matchpat()
. The former computes
num_stones[]
array which holds number of stones in corner areas of
different intersections of the board for all possible transformations.
corner_matchpat()
also matches top-level variations.
do_corner_matchpat()
is responsible for recursive matching on the
variation tree and calling callback function upon pattern match.
Tree-like database for corner matcher is generated by mkpat
program.
Database generator consists of several functions, most important are:
corner_best_element()
, corner_variation_new()
,
corner_follow_variation()
and corner_add_pattern()
.