Ishi Format
Various formats are used for recording Go games on computers. The "Ishi" format used to be quite popular, though now SGF has mostly taken over. The following specification of the Ishi format was provided by David Fotland.
Standard Format for Go Data Files
Specification
17 March 1990
Contents
- Standard Format
- Definitions
- General Discussion
- Detailed File Structure
- Keywords
- General Error Conditions
- Sample Valid-Format Data
1. Standard Format
The Standard Format for Go data provides a means for storing and transferring data that represents Go games, Go problems, joseki dictionaries, diagrams, and other Go-related information, in a way that is reasonably independent of machines, operating systems and application programs.To support the Standard fully, an application program must be able to recognize and interpret correctly all data signalled by the keywords listed and described in Section 5.
An application that only reads Standard Format files, and does not also write such files, must be able only to recognize and interpret the keywords of interest to it. An application that only writes Standard Format files can write a minimum subset of keywords, sufficient to capture the information it generates.
An application that both fully reads and fully writes Standard Format files must be able to recognize and store all data signalled by the keywords described in Section 5, and write all that data into an output file without adding to, losing, or modifying data in the file in any significant way. Not significant are white space, case outside of commentary and board marks associated with commentary, and order except where obvious or where specifically required.
2. Definitions
- current event
- the event most recently defined in the data file
- current move
- the most recent Black or White move in the current sequence within the current event
- event
- a game, or problem, or joseki, or other similar block of conceptually-related G0 data
- keyword
- a string of valid characters with no blanks; signals that data of some particular type follows
- sequence
- a series of consecutive moves NOT including any variations on those moves; can be in the main game/problem or follow a variation on some other move; every sequence is terminated either by an EVENT, or by an ENDVAR, or by the end of the data file
- setup
- non-indexed moves/stones including handicap stones, problem-situation stones, and stones associated directly only to diagrams
- SF
- Standard Format for Go data
- valid characters
- characters in the ASCII decimal range 32 to 126 inclusive, plus tab (ASCII 9) and the carriage-return-line-feed pair (ASCII 13 and 10 consecutively)
- white space
- blank spaces and tabs (ASCII decimal 32 and 9 resp.)
3. General Discussion
Data files in Standard Format (SF) are line-oriented, keyword-driven, and white-space-delimited. That is:- The main unit of reading/writing in an SF file is the line: a series of valid characters terminated by the ASCII carriage-return-line-feed pair.
- Each line in an SF file either begins after white space with a keyword, or is part of a block of lines set off by the keyword pair COM/ENDCOM (commentary) or by the pair USER/ENDUSER (user-defined data).
- Any pair of data fields - keywords, plus other fields that are required to follow them or can optionally follow them - can be separated from each other by any amount of white space (spaces and/or tabs) but by at least one space or tab. A keyword can have any number of spaces or tabs before it on its file line.
An SF file is not required to have any data in it: a completely empty file is a valid-format file.
Valid characters in an SF file are those in the ASCII range 32 to 126 inclusive, plus the tab character (ASCII 9) and the carriage-return-line-feed pair (ASCII 13 and 10 consecutively). All other characters can be ignored by applications.
Case is irrelevant in SF files except within commentary blocks and for explicit characters that represent board marks (see the section on Notation). Outside of board marks and commentary, all of upper case, lower case, and mixed case are accepted and treated as equivalent for keywords, move locations, special-character designations, etc.
No assumptions are made in SF files about evenness or oddness for move numbers in relation to player's color. Black's moves can be even-numbered and White's can be odd-numbered, or vice-versa for both colors. No assumptions are made about alternation of play between Black and White.
4. Detailed File Structure
4.1 Files
Each Standard Format (SF) file contains one or more events. An event can be a game, a problem, a joseki, a special diagram, or some other block of Go-related data. Each event occupies a distinct, contiguous block of lines in the file.An empty SF file consists only of the default implicit event with no attached data. A file with no events specifically defined via the EVENT keyword, but with moves or other data, has an implicit first event to which the data is associated.
An SF file looks like this:
Event 1
Event 2
.
.
.
Event n
4.2 Events
Each event has a single, square board size between 2x2 and 19x19 inclusive, with default 19x19 unless otherwise specified. Each event contains zero or more of the following (but no more than one tree of moves and diagrams):- remarks in the file that apply to the event and are typically seen only by a person viewing the file directly;
- header records such as player names and ranks, date, source, place, handicap, komi, result, etc.;
- unnumbered Black and White setup stones, for example handicap stones or problem-situation stones;
- commentary that applies to the event as a whole;
- blocks of user-defined data that apply to the event as a whole;
- board marks - letters or special characters or shapes that will be displayed on the empty board at the start of the event, before any setup stones or moves, and only then;
- a "tree" of numbered Black and White moves that represent the flow of play in the event, plus any number of diagrams interspersed with the moves; the moves and move-related diagrams in an event follow all other data that applies to the event as a whole.
Remarks
Event definition (EVENT keyword)
Event header data
Event commentary and marks
Event setup stones
Event user data
Tree of moves and diagrams
The remarks if any precede the event definition in the file. The event definition line precedes all the remaining
lines in the event. All header lines, commentary blocks, marks, setup stones, and blocks of user data may occur in
any order among themselves, subject to those keywords' own rules, but all must precede the tree of moves and
diagrams if any.
4.3 Moves
Each move in an event is defined by a player color, a move number that is greater than zero, and the board position for the move or an indication that the move was a pass or tenuki. Each move is either a move in the main flow of play, or a variation on such a move, or a move within a sequence that follows a variation upon another move. Variations may be nested to any "depth": moves within variation sequences may have "deeper" variations on them.A move is defined either as a setup stone (SETUP keyword) or as a regularly-played Black or White play on the board (B or W keyword respectively).
A move has associated with it zero or more of the following:
- remarks in the file that apply to the move and are typically seen only by a person viewing the file directly;
- a list of the prisoners taken when this move is played;
- commentary that applies to the move;
- board marks - letters or special characters or shapes that normally relate to the commentary and will be displayed on the board when the move itself becomes displayed as the last of the current sequence, and only then;
- blocks of user-defined data that apply to the move.
Remarks
Move definition (SETUP or B or W keyword)
Prisoners
Marks
Commentary
User data
Variations on the move
Remarks if any precede the move's definition. Prisoner lines, commentary blocks, marks and user data all follow the
move definition line and may occur in any order among themselves. Variations on the move must follow all other move data.
4.4 Diagrams
Each diagram occupies a specific place in the tree of moves, variations and diagrams associated with an event.A diagram is defined by a board region to be displayed when the diagram is shown. Unless otherwise specified, the region is the same as the parent event's board size. The region can be any rectangular subarea of any board between 2x2 and 19x19 in size;
Each diagram contains zero or more of the following:
- remarks in the file that apply to the diagram and are typically seen only by a person viewing the file directly;
- a list of Black and/or White setup stones that will be displayed only when the diagram is displayed; these stones have no bearing on the flow of play that precedes or follows the diagram;
- a list of stones/moves to hide when the diagram is displayed; i.e., to remove temporarily from the display when the diagram is shown and to restore to view when the diagram is taken down;
- commentary that applies to the diagram;
- board marks - letters or special characters or shapes that normally relate to the commentary and will be displayed on the board when the diagram itself becomes displayed, and only then; these marks can apply to regular moves in the sequence and/or to the diagram's setup stones;
- blocks of user-defined data that apply to the diagram.
Remarks
Diagram definition (DIAGRAM keyword)
Setup stones
Hide moves/stones
Marks
Commentary
User data
Remarks if any precede the diagram's definition. Setup lines, hide-stone lines, commentary blocks, marks and user
data all follow the diagram definition line and may occur in any order among themselves.
5. Keywords
5.1 List of Keywords
Event keyword
EVENT begin next event: game, problem, joseki, etc.
Header keywords per EVENT
ANALYSIS person(s) who provided the commentary
BLACK Black player's name, rank etc.
DATE date(s) on which game was played
HANDICAP handicap count (informational only)
KOMI komi
PLACE location(s) where game was played
RECORDER person(s) who recorded the data
RESULT result of the game
RULES Japanese (the default) or Chinese
SOURCE source for data: book, journal, etc.
TIMELIMIT time limits for one or both players
WHITE White player's name, rank etc.
Data keywords per EVENT
B next Black move(s)
BOARDSIZE size of square board for event
COM begin a commentary block
DIAGRAM begin definition of a diagram
ENDCOM end a commentary block
ENDUSER end a user-defined block
ENDVAR end a variation sequence
HIDE stones/moves to hide in a diagram
MARK board markers related to commentary
PRISONER prisoners taken by current move
REMARK file-writer's remark on event, move, diagram
SETUP setup B/W stones for an event or diagram
UNMARK remove some previously-defined MARKs
USER begin a user-defined block
VAR begin a variation sequence
W next White move(s)
5.2 Header Keywords
Header keywords represent informational data about the current event. Each header line consists of a keyword optionally followed by free-form text that represents the header data. This text may contain any amount of white space.Each header keyword can be repeated within an event. In the case of generally textual data such as source, place, analysis, etc., the total data is the sum from all the repeated lines. In the case of normally once-only data such as Black player, komi, etc., the last line encountered should be taken as the correct data. An application may treat multiple occurences of once-only data lines as an error condition but is not required to do so.
A note on handicaps: Exact board locations for a given number of handicap stones are usually ambiguous. For this reason, handicap stones are placed in specific locations using the SETUP keyword. HANDICAP keyword data is informational and does not necessarily have to match the actual setup.
Below are valid examples of header keywords.
Analysis Jim Kerwin, professional 1-dan
ANALYSIS Kato 9 Dan
BLACK Honinbo Shusaku
black Alan Chen (9 years old)
Black
Date 8 March 1990
Date 3-21-48
date November 21-24, 1847
DATE Dec 9, 1938 and Mar 3-4, 1939
Date June 3 and 7, 1958
HANDICAP 0
Handicap 7
komi 5
Komi 3 1/2
KOMI 4.5
Place
PLACE Kyoto (April) and Tokyo (May)
place US Go Congress, Denver
Recorder Ishi Press
RECORDER Phil Straus (playing Black)
RESULT White wins by resignation
result Black by 3
Result Black resigns at move 186
RULES Japanese
Rules CHINESE
Rules
SOURCE "Invincible: The Games of Shusaku"
SOURCE John Powers, Kiseido Publishing Co., Tokyo 1982
Timelimit 1 hour
WHITE James Redmond 5-dan (made 6-dan after this game)
5.3. Notation for Keyword Specifications
<> nonrepeatable required data field with no
embedded white space
<>* repeatable required data field, each occurence of
which contains no embedded white space
[] nonrepeatable optional data field that may have
embedded white space if so indicated
[]* repeatable optional data field, each occurence of
which may contain white space if so indicated
n positive integer
n-n sequence of positive integers increasing from the
first number n to second, inclusive: e.g., 21-29
loc board location of form cn, where the character c,
in the (case-insensitive) set a b c ... not
including i, represents the column starting from
the left, and the number n represents the row
starting from the bottom; e.g. A3 r17 F6
cc one or two characters in the standard ASCII range
33 decimal to 126 decimal inclusive; the blank
character ASCII 32 is not included; if the first
character is \ then c, d, s or t as the second
character indicates a special character (see next
notation)
\C special marker character, under DOS outside the
ASCII range 32-126; case-insensitive; one of
\d diamond ASCII 4
\t triangle ASCII 30
\c check mark ASCII 251
\s square ASCII 9
| "or"; precedes next in a series of alternate
entries in a data field; e.g. <#n | loc>
5.4 Specifications for Non-Header Keywords
B | BOARDSIZE | COM | ENDCOM | DIAGRAM | ENDUSER | ENDVAR | EVENT | HIDE | MARK | PRISONER | REMARK | SETUP | UNMARK | USER | VAR | WB <n> <loc | PASS> Next move by Black. The move number <n> must be greater than 0. Consecutive B lines in a file are not required to have consecutive move numbers, though applications may choose to treat nonconsecutive numbers as an error condition. Examples B 17 q3 B 21 pass
BOARDSIZE <n> Size of current event's square board, between 2 and 19 inclusive. If no boardsize is indicated for an event, 19x19 is assumed. Examples BOARDSIZE 2 BOARDSIZE 9 BOARDSIZE 13
COM [title data] Begin block of commentary on current event, move or diagram. If there is no current move or previously-defined setup stones in the current event, apply commentary to the event as a whole. All other data after the COM keyword on the line is treated as "title" data for the comment that follows. Title data may contain white space. The next keyword line in an SF file after a COM line must be an ENDCOM line. COM blocks cannot be nested. All lines between a COM and an ENDCOM are treated as commentary text. Examples COM COM JK's notes \c + ! COM The famous "ear-reddening" move
ENDCOM End block of commentary. A line starting with ENDCOM must follow each COM line. All lines between the COM and ENDCOM are treated as commentary text. Example ENDCOM
DIAGRAM [<nXn> | <loc loc>] Begin definition of a diagram and specify its board region. The region of a diagram is any rectangular subarea of any board of size 2x2 through 19x19. If no region is indicated, a diagram occupies the full BOARDSIZE of the current event. A full-board diagram of a certain size is given by nXn where n is in the range 2 to 19. If a diagram's size is different from the current event's BOARDSIZE, it is up to the application to decide whether or not to clear the board's display, or to put up a separate window with the diagram, or whatever. Diagram title and commentary data is contained in COM/ENDCOM blocks as with regular B and W moves. See also the HIDE keyword discussion. Examples DIAGRAM (use current event boardsize) DIAGRAM 19x19 (full 19x19 board) DIAGRAM a19 t1 (full 19x19 board) DIAGRAM 9X9 (full 9x9 board) DIAGRAM a1 j9 (9x9 lower-left corner of board) DIAGRAM b5 j12 DIAGRAM b12 j5 (same region as previous example)
ENDUSER End a block of user-defined data. Must be preceded in the file by a USER line. Example ENDUSER
ENDVAR End a variation sequence. Must be preceded in the file by a VAR line. Example ENDVAR
EVENT [event title] Start the next game/problem/joseki/diagram/etc. An EVENT line terminates the current sequence if any and terminates the current event if any. All other data on the line after the EVENT keyword is treated as title commentary on the event. Such title data may contain white space. Examples EVENT Problem 6 EVENT Joseki for 3-4 point attacked from 5-4 point EVENT Honinbo 1989 Final
HIDE [loc | #n | #n-n]* For a DIAGRAM, temporarily remove from display the indicated stones, which are specified either by board location or by move numbers in order to support removal of regularly played moves as well as handicap/setup stones. See the syntax discussion under MARK. Examples HIDE #21 HIDE #3-9 q9 R11 #17
MARK [ALL | loc | #n | #n-n | \C@loc | \C@#n | \C@#n-n | cc@loc | cc@#n | cc@#n-n]* Board marks (highlights) attached to the current event, move or diagram. If no move or diagram exists in the current event then the marks apply to the empty board. Both kinds of indicator for move locations - move number or stone location - are supported because handicap/setup stones can be marked and because move numbers can be ambiguous within a variation sequence: does the number apply to the move within the variation, or to a move with the same number in a higher-level variation or in the main game? Board marks are instructions to a program to display or undisplay special letters or shapes on the board, usually in conjunction with commentary. The sequence of mark keylines is important: a read-write application must preserve the sequence in which MARKs and UNMARKs are defined. For example, the below lines in the order presented cause moves 1-5, 11, and 21-33 to have their move numbers displayed: MARK #1-33 UNMARK #6-20 MARK #11 A different order would result in a different display. Data fields: ALL show move numbers on all visible numbered stones (does not show numbers on setup or handicap stones) example MARK All loc show move number on stone at this location example MARK Q8 #n show number on most recent move with this number example MARK #21 #233 #n-n show move numbers on a range of moves example MARK #21-28 #221-233 \C@#n special character on specified move number example MARK \s@#221 \t@#18 \C@#n-n special character on all of specified range of moves example MARK \t@#21-30 \C@loc special character at board location; can be at a stone example MARK \t@Q5 \S@R1 \T@m3 cc@loc one or two characters at a location; case is retained; can be at a stone example MARK a@R3 B0@o9 +@A6 X@r7 cc@#n place one or two characters on a numbered move example MARK aa@#33 X@#102 cc@#n-n place one or two characters on a range of moves example MARK x@#81-90 ..@#320-323
PRISONER [#n | loc]* Prisoner(s) taken by current move. Both forms of move/stone indicator are supported - move index and board location - because handicap and setup stones can be captured. Examples PRISONER #22 Q9 F3 #28 PRISONER #25 #3 #11 #33
REMARK [free-form text] A remark in a file is normally meant for view only by a person who is directly reading or editing the file. Each remark applies to the next EVENT, SETUP, B or W move, or DIAGRAM in the file. Each of these keyword types can have any number of remarks preceding it in a file. Examples REMARK file test.go REMARK Jack - are the next 3 lines OK? REMARK Diagram 3 of 9
SETUP [<B | W> [loc]*]* Place unnumbered setup stones for an event or diagram, including handicap stones for a game. In general, all setup stones in an event or diagram are considered one generalized "move": they are all displayed or undisplayed as a unit in a single step. An event or diagram can have any number of SETUP lines. Either B or W must precede any list of setup stones to indicate their color. Multiple sets of different-colored setup stones can follow the SETUP keyword on a line. Only the first SETUP line in a series of setup lines can have an associated REMARK. Only the last of a series of SETUP lines can have MARKs, UNMARKs, commentary or user- defined data. Examples SETUP B d4 q4 d16 q16 SETUP W a6 B a7 R11 J9 W b5 B M4
UNMARK [ALL | loc | #n | #n-n]* Board marks attached to the current event, move or diagram. If no move or diagram exists in the current event then the unmarks apply to the empty board. An UNMARK removes a MARK previously specified. A series of MARK and UNMARK keywords can be used to build Boolean operations on the marks to be displayed. See the discussion under MARK for details. Examples UNMARK All UNMARK Q8 #21 r3 #39-43
USER [user-defined data of any format whatsoever] Begin a block of user-defined data. This line, and all lines after it and up to and including the next ENDUSER line, define a block of user data. USER/ENDUSER blocks may not be nested Examples USER USER Ishi inventory USER Printed diagram #4 of 8
VAR [cc] Begin a variation sequence. The variation in question applies to the current move, which must be a B or W keyword-prefixed move. The optional one- or two-character marker may be placed by a display application at the variation's board location as a visual cue, or the character(s) may represent sequencing numbers or letters with no special display significance. Example VAR VAR b VAR 10
W <n> <loc | PASS> Next move by White. The move number <n> must be greater than 0. See the discussion under keyword B for more details. Examples W 38 R19 w 99 pass
6. General Error Conditions
A keyword line that is missing required data is in error.Duplicate or out-of-sequence move numbers within a sequence usually implies an error condition. For example, "B 12 Q3" followed by "B 11 R5" or "B 12 R8" probably implies an error. In certain cases an application may choose to accept out-of-sequence moves. In all cases, however, duplicate moves indicate errors.
In general, a missing move index implies an error condition. For example, if Black 19 is followed by B 21, a White move is probably missing. This may be an acceptable condition for certain application; it is up to the application to decide.
Certain keyword fields may have, after their required and/or optional data, further data on the line. Most applications will ignore such extra data. It is NOT necessarily an error condition for extra data to be present. For example, the ENDVAR keyword has no further required or optional data; a line such as "ENDVAR back to main game" should not generate an error, but a program that reads a file with such a line is not expected to write the extra data to an output file. If the specification for a keyword would cause extra data to be parsed, and if that data has incorrect format, than an error condition would however be indicated. For example, the line "B 22 Q3 R7" should be seen as an error.
7. Sample Valid-Format Data
The below data is valid-format with respect to the Standard. Nearly all of the keywords are represented in this data, and most data-field variations for the keywords are represented.
Remark testspec.go
Remark Three-event SF file for illustration and testing
event
B 1 R16
W 2 D17
B 3 Q3
W 4 P17
B 5 C4
W 6 E3
B 7 Q5
W 8 C6
B 9 D6
W 10 D7
B 11 E6
W 12 E7
B 13 E4
W 14 D3
B 15 C7
W 16 C8
B 17 B7
W 18 F7
B 19 B8
W 20 F4
B 21 F6
W 22 C9
B 23 G7
W 24 G8
B 25 H6
W 26 J3
B 27 E9
W 28 B9
B 29 F8
W 30 D8
B 31 G9
W 32 H8
B 33 H9
W 34 J8
B 35 J9
W 36 K8
B 37 D11
W 38 C12
B 39 C11
W 40 B11
B 41 B12
W 42 B13
B 43 D12
W 44 A12
PRISONER B12
B 45 C13
W 46 C14
B 47 B12
PRISONER C12
W 48 F10
B 49 F9
W 50 C12
PRISONER B12
B 51 D13
W 52 B6
B 53 B5
W 54 A8
B 55 C5
W 56 A7
PRISONER B8 #17 C7
B 57 B12
PRISONER C12
W 58 G5
Event Yose Problem 7
Source Page 164 of "Basic Techniques of Go"
Source By Haruyama and Nagahara
Source Ishi Press, Berkeley-Tokyo, 1969
Black Haruyama 6-dan
White Nagahara 4-dan
Komi 0
Boardsize 10
Timelimit 30 minutes each
Handicap 1
Result Black wins by 1
Rules Japanese
Analysis The authors
Recorder W. Lobb
Date 8 March 1990
Place Concord MA
Setup w e10 f9 j9 k9 b8 f8 g8 h8 k8 b7 c6 h6 k6
Setup b B9 C9 D9 E9 A8 C8 E8 J8 D7 E7 F7 G7 H7 J7 K7 D6 J6
Setup w C5 G5 H5 J5 K5 B4 C4 F4 G4 a3 b3 e3 f3 a2 c2 d2 e2 b2
Setup b d5 f5 d4 e4 h4 j4 k4 c3 d3 g3 j3 f2 g2 h2
Com Yose Problem 7.
How should Black play so as to win by one point?
Endcom
B 1 h9
W 2 h10
b 3 f10
Mark #1-2
com
Black 1 and 3 are kiri (cut) and horikomi tesuji. The meaning of
these moves will become clear in a moment.
endcom
w 4 g10
PRISONER #3
b 5 b6
COM \d
Black 5 is the atekomi tesuji and is worth 1 point with
sente for Black.
ENDCOM
w 6 a6
b 7 c7
w 8 b5
PRISONER b6
b 9 f1
w 10 f6
b 11 E5
w 12 G6
b 13 E1
w 14 D1
b 15 D10
w 16 g9
Prisoner h9
b 17 a9
w 18 a7
b 19 f10
prisoner E10
w 20 j2
b 21 k2
w 22 E10
prisoner #19
b 23 A5
w 24 A4
prisoner #23
b 25 F10
PRISONer E10
User Print-Diagram 1 of 10
MARK All
numbase -22
partial c1 k8
show 12 28
Ko information goes here
Enduser
w 26 J1
b 27 H1
w 28 E10
Prisoner #25
b 29 j10
w 30 k10
prisoner #29
b 31 f10
PRISONER e10
COM
After Black takes ko at 31, White has no more ko threats. Black
wins by 1 point, having 15 points against White's 14.
ENDCOM
EVENT Problem 1 from Ishigure
COM
Adapted from page 111 of "In the Beginning"
By Ikuro Ishigure, Ishi Press 1973
ENDCOM
BOARDSIZE 19
SETUP B R16 C4 R5 P17 O5 W E17 Q3 E3 Q8 P5 P4
SETUP W O6 N6 Q10 B P6 Q6 O7 W O4 N4 L3 B P8 O3 N5 M5
COM Problem 1
Black to play.
ENDCOM
B 1 Q12
MARK 10@R12 8@Q13 8@R13 8@C17 8@C16 8@D15 \S@q10
MARK \t@Q8 8@L5 7@P9 7@J17 7@J16 7@K16
COM \D \c
Black 1 is the best move and scores 10.
The focal point of the game as it now stands is the unsettled
position on the right side. Black should make a pincer play
either at 1 or at '10', attacking the white stones marked \T and
\s while forming territory in front of his shimari.
If you chose to play one line higher, at one of the points
marked 8 in the upper right, you can take credit for finding the
right direction of play, but you are being too timid.
ENDCOM
VAR 8
B 1 M7
COM Score: 8
ENDCOM
W 2 R13
MARK m7
COM
Black 1, capturing two stones and tying Black's forces
together, is an important point, but White 2 makes White's
position safe, too, and robs Black of territory on the right
side.
ENDCOM
VAR
W 2 p7
MARK M7
COM
This is not good for White.
ENDCOM
USER Some user data here.
More user data.
Last line of user data.
ENDUSER
ENDVAR
ENDVAR
VAR 8
B 1 D5
COM Score: 8
ENDCOM
W 2 M6
B 3 L5
W 4 L6
B 5 K5
W 6 L8
MARK ALL
UNMARK #6
MARK \t@L8
COM
If Black plays on the left side, 1 looks best, but then White
will play 2, 4 and \t, and be one move ahead on the right side
of where he comes out in the main sequence.
ENDCOM
ENDVAR
VAR 7
B 1 Q9
COM Score: 7
ENDCOM
W 2 R9
B 3 P9
W 4 r13
MARK #1 r9 p9 X@r10
COM
If Black plays at 1 and 3, White will extend to 4, with
nothing to fear from Black's cutting at X.
ENDCOM
ENDVAR
W 2 M6
VAR
W 2 P9
B 3 L5
MARK p9
COM
If White answers Black 1 directly by playing, say, 2, Black
will capture at 3. White, his three stones on the right side
sandwiched between two strong black positions, faces a dreary
prospect. White cannot play this way; the fight in the main
sequence is inevitable.
ENDCOM
ENDVAR
B 3 L5
W 4 L6
B 5 K5
W 6 L8
MARK all a@k6
COM
After Black 1, White should push out into the center with 2 and
4, then jump to 6 (or, if he prefers, keep pushing at 'a'). This
starts a four-way fight between two weak black groups and two
weak white ones. It will be difficult, but Black has already
staked out his claim on the best ground by playing 1.
ENDCOM
VAR
DIAGRAM
HIDE q12 r16 p17 e17 c4 e3 l5 k5 l6 m6
MARK 1@q8 2@o5 3@p5 4@p6 5@p4 6@q6 7@o6 8@o7 9@n6 10@p8
MARK 11@q10 12@o3 13@o4 14@n5 15@n4 16@m5 17@l3
COM
For your reference, the position in the lower right
corner arose from this pincer joseki.
ENDCOM
ENDVAR
Last updated Mon May 08 2017.
If you have any comments, please email the webmaster on web-master AT britgo DOT org.
If you have any comments, please email the webmaster on web-master AT britgo DOT org.