Next: A Ko Example, Previous: Persistent Cache, Up: Tactical Reading
The principles of ko handling are the same for tactical reading and owl reading.
We have already mentioned (see Reading Basics) that GNU Go
uses a return code of KO_A
or KO_B
if the result depends on
ko. The return code of KO_B
means that the position can be won
provided the player whose move calls the function can come up
with a sufficiently large ko threat. In order to verify this,
the function must simulate making a ko threat and having it
answered by taking the ko even if it is illegal. We call such an
experimental taking of the ko a conditional ko capture.
Conditional ko captures are accomplished by the function tryko()
.
This function is like trymove()
except that
it does not require legality of the move in question.
The static reading functions, and the global functions do_attack
and do_find_defense
consult parameters komaster
,
kom_pos
, which are declared static in board.c. These mediate ko
captures to prevent the occurrence of infinite loops. During
reading, the komaster values are pushed and popped from a stack.
Normally komaster
is EMPTY
but it can also be
`BLACK', `WHITE', GRAY_BLACK
, GRAY_WHITE
or
WEAK_KO
. The komaster is set to color
when color
makes a
conditional ko capture. In this case kom_pos
is set to the location of
the captured ko stone.
If the opponent is komaster, the reading functions will not try to
take the ko at kom_pos
. Also, the komaster is normally not
allowed to take another ko. The exception is a nested ko, characterized
by the condition that the captured ko stone is at distance 1 both
vertically and horizontally from kom_pos
, which is the location
of the last stone taken by the komaster. Thus in this situation:
.OX OX*X OmOX OO
Here if `m' is the location of kom_pos
, then the move at
`*' is allowed.
The rationale behind this rule is that in the case where there are two kos on the board, the komaster cannot win both, and by becoming komaster he has already chosen which ko he wants to win. But in the case of a nested ko, taking one ko is a precondition to taking the other one, so we allow this.
If the komaster's opponent takes a ko, then both players have taken one ko. In
this case komaster
is set to GRAY_BLACK
or GRAY_WHITE
and
after this further ko captures are even further restricted.
If the ko at kom_pos
is filled, then the komaster reverts to
EMPTY
.
In detail, the komaster scheme is as follows. Color `O' is to move. This scheme is known as scheme 5 since in versions of GNU Go through 3.4, several different schemes were included.
Komaster remains EMPTY if previous move was not a ko capture. Komaster is set to WEAK_KO if previous move was a ko capture and kom_pos is set to the old value of board_ko_pos.
Komaster is set to O and kom_pos to the location of the ko, where a stone was just removed.
Play at kom_pos is not allowed. Any other ko capture is allowed. If O takes another ko, komaster becomes GRAY_X.
Ko captures are not allowed. If the ko at kom_pos is filled then the komaster reverts to EMPTY.
Komaster is changed to WEAK_X and kom_pos to the old value of board_ko_pos.