Next: , Previous: Persistent Cache, Up: Tactical Reading


11.4 Ko Handling

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.