www.delorie.com/gnu/docs/gnugo/gnugo_175.html   search  
 
Buy GNU books!


GNU Go Documentation

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.3 Ko Handling

The principles of ko handling are the same for tactical reading and owl reading.

We have already mentioned (see section 14.1 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 have arguments komaster, kom_pos. These mediate ko captures to prevent the occurrence of infinite loops.

Normally komaster is EMPTY but it can also be BLACK, WHITE or GRAY. 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 and after this further ko captures are not allowed.

If the ko at kom_pos is filled, then the komaster reverts to EMPTY.

The komaster scheme used in GNU Go 3.0 is known as komaster scheme 1. It may be summarized as follows. It is assumed that `O' is about to move.

In GNU Go 3.2 a new komaster scheme 5 is used. It may be described as follows.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

  webmaster     delorie software   privacy  
  Copyright 2003   by The Free Software Foundation     Updated Jun 2003