Capturing race

In the game of go, a capturing race (Japanese language semeai, 수상전[soosangjeon] in Korean.) is a tactical situation created in positions when both players have groups striving to capture each other, in some closely delimited area of the board. Typically it is not possible for each side to create a safe group with two eyes.

One common outcome is that one group is captured, resolving the race. In the most simple situations it is possible to predict this result, by counting the liberties on each group: if for example there are four liberties each, the advantage will lie with the player able to play first, while if one side has four liberties and the other five, the result is already decided and neither player will continue (the player who is behind will normally leave the area alone, seeing it as a future source of ko threats).

There are numerous other possible outcomes, for example a seki, a ko of a direct or indirect nature, and (rather rarely) more exotic types of repeating situation such as triple ko or chosei. In the more orthodox races some theory is available to help understand the status as far as liberties goes, when these are not completely WYSIWYG; but such theories are not so far able to give an exhaustive description of all capturing races.

Example
This problem (Difficulty: 5 dan) begins with B1. Can white save his stones and "make life"? This kind of problem is called a semeai; where one is in a "race" to capture the opponent first... W2 is the correct move here. Black approaches with B3, and white protects with W4. Note that both B and W groups have four liberties, and now it's Black's move... After the next few moves, the situation becomes clearer. Despite black's best responses, the five white stones have one more liberty (the one below move 9) than black does. If it's not clear how white survives, see the next image for detail... After W10, B11, W12, the black stones are in atari. When eventually black plays 13 (as a ko threat), white can capture the four black stones.
gollark: Better idea: just make mouse_hover return RANDOM NUMBERS!
gollark: That's a terrible idea.
gollark: How about `mouse_hover` but it only works in potatOS and constantly provides the mouse position of a random player on the server?
gollark: >and really no decent program would rely on it
gollark: >that shouldn't be needed

See also
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.