$Source: /home/heiner/ca/chest/MEMOS/RCS/MEMO.pgn,v $ $Id: MEMO.pgn,v 1.3 1999/12/18 20:18:04 heiner Exp $ Author: Heiner Marxen Date: Sun Jun 27 15:44:35 MEST 1999 Topic: PGN Format and Test Suites ========================== The traditional CHEST input format is suited for single jobs or small sets of jobs. The traditional output is suited for humans to read, and for collecting statistics about the internal operation of CHEST. Here we want to address the need for large collections of jobs, to be processed in a large batch, producing a machine readable output, suited to be automatically processed and judged. Trigger: C.A.P. (Dann Corbit). The EPD format seems to be suitable for this. There is one line input for each job, and one (or none) line output. We term this "bulk mode". New option is "-b". Standard ^^^^^^^^ We use the PGN Standard document (1994.03.12 from S.J.Edwards). We will mostly use EPD, which contains FEN and is itself part of PGN. - Max line length 255; preferred maximum is 80. - Newline as in UNIX: LF - Allowed controls: HT, VT, LF and CR. Tabulators in output are discouraged. - Comments: + start with semicolon ";" upto end of line + start with brace "{", end with brace "}". No nesting, no escape. + start with percent "%" in column 1 (termed "escape" instead of "comment") - FEN fields are separated by a single blank. - FEN requires '/' between rows (ranks) FEN fields ^^^^^^^^^^ [1] Forsyth string (lower case = black) [2] Colour to move ("w" or "b") [3] Castling availability: "-" or a subset of "KQkq". Obey order in output. [4] e.p. target square: "-" or e.g. "e6" Standard: Iff the last move was a double step pawn move. We like to reduce this. [5] Halfmove clock (for 50-move rule), >= 0. [6] Fullmove number, >= 1, move number of the next move to come. EPD fields ^^^^^^^^^^ [1-4] same as FEN rest series of "operations". - EPD consists of one text line - Recommended max. text line size is 1024. - Opcode max length 15 - Opcode is like an identifier - Operations should be sorted alphabetically by their opcodes. operation := white* opcode operand* ";" operand := " " ( character+ | string ) string := '"' character* '"' [length < 256] opcode := acn [out] analysis count: nodes acs [out] analysis count: seconds am [out] avoid move(s) [set of moves, ASCII sorted] bm [out] best move(s) [set of moves, ASCII sorted] ce [i/o] centipawn evaluation [16-bit integer] dm [?/?] full move until mate [dm N == ce 32768-2N] id [copy] identification [string] pm [out] proposed move [first element of "pv"] pv [i?/o] principle variation [series of moves] All others may be accepted and preserved (copy). If a "pv" is present, its first move is the "pm". Centipawn evaluation values ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Value range: -32767 .. 32766 [inclusive] It is relative to the side to move (positive is good). Values > 32000 and < -32000 indicate absolute (mate) values. - Mate in N full moves (in 2N-1 plies): 32767 - (2N-1) mate in 1 32766 mate in 2 32764 mate in 5 32758 mate in 10 32748 - Facing unavoidable mate in N moves, i.e. 2N plies until mate, scores -32767 + 2N I'm mate -32767 [Standard: illegal] I'll be mate in 1 -32765 will be mate in 5 -32757 - Stalemate and other draws: 0 SAN (Standard Algebraic Notation) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Piece codes (upper case English) P pawn N knight B bishop R rook Q queen K king The pawn code is normally omitted from move notations. This is already the way CHEST works (with output language English). Square := column row column := one of "abcdefgh" row := one of "12345678" O-O king side castling O-O-O queen side castling NB: those are capital Os, not zero digits (0). Already ok. Qe7 Normal move Qxe7 Capturing move e4 pawn move dxe6 pawn capture (+ source column) dxe6 pawn e.p. (no special indicator) e8=Q pawn promotion dxe8=N capturing pawn underpromotion Disambiguation: (1) Add source file (=column) letter. If that fails: (2) Add source rank (=row) digit. If that fails: (3) Add both. Already done that way. Check indicator: - Append "+" if the move says check. - Append "#" instead iff the move says checkmate. Maximum length of SAN without check indicator: 6 characters Maximum length of SAN with check indicator: 7 characters Move conversion options (MVCO) ^^^^^^^^^^^^^^^^^^^^^^^ - Capture indicator "x" (instead of ":") - Capture indicator infix (instead of postfix) - Show checkmate indicator "#" (instead of "+") - Do not rely on check-bits in move - Promotion indicator "=" (instead of "") - Extended length = 7 - For length=6 from "Qe6xd5+" drop "x" or "+" - For length=6 from "exd8=Q+" drop "x" or "+" or "=" - Ep indicator suffix "ep" | infix "*" or none What is the Job ^^^^^^^^^^^^^^^ (A) EPD specifies |ce| > 32000: implies depth & -x option (B) EPD specifies dm: is the depth; no -x (C) EPD specifies pv ending with mate indicator: implies depth & -x option (D) -z option specifies max depth. FFS: always override? -Z? - ce >> 0 specified: normal - ce << 0 specified: with -x - else: try both? (E) use default depth (5?), and try both JobType "normal" is acceptable. Currently forced. For the other JobType's the semantics of the "ce"-Tag are a problem. - JobType "*stalemate": pv does not even end in "#". - JobType "selfmate/helpmate": Since the ply depth is one off from "normal", this could be an option. However, "selfmate" and "helpmate" would appear to be equal, i.e. we need another tag to find out which one is ment. Construction of bm/am ^^^^^^^^^^^^^^^^^^^^^ (A) Normal operation (no -x): All key moves (solution list) go into "bm" List. One (the first) is used for "pv" generation. FFS: the last could be better present in cache. For "am" we would need anti-Information, or refu-depth INF. FFS: we could use refu-depth >= 62 for this. (B) With -x (tom gets mated, anyhow): All moves "are to be avoided", but some more so. FFS: shorter by >= 2 moves | shortest (if any). Those moves in the top list, which achieve the greatest depth, are the best moves: go into "bm" list. One (the first) is used for "pv" generation: just followed by the normal pv from the solution. Generation of the "pv" is similar to solution/solopt: - Compute a single key move for the current depth. - Sort the answers (like in do_ana). - Compute sub-solutions (for answer list) until we find one of depth d-1. Try to do snooping to find it (avoiding real computations). Really compute, when no such sub-solution is found by snooping. Problems with the current version of CHEST (3.16) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - The capture indicator has to be changed and moved between src and target. - Checkmate indicator (currently not present) Does need the board to be evaluated, but that is present, already. - Max move length is currently 6, what fits well to "solopt". Currently, only fully disambiguated capture moves can be 6 characters, already: Qe6xd5 An additional check would not fit, and the capture indicator is dropped: Qe6d5+ With the additional '=' required by SAN, this can happen for promotions, also: exd8=Q Here, either the capture indicator 'x' or the promotion indicator '=' could be omitted. Alternatively we could have a special conversion function allowing for more than 6 chars. - When presented with a negative "ce", we shall confirm, that the side to move will lose. This corresponds to the flag "-x". First shot: produce one line of output. Iff after all replies there is a (near enough) mate, produce a "ce". Create PV from the first of the deepest solutions. If any replies do not follow with mate, make those "bm". Also, try to mate in the other direction? FFS === - Accept "quoted printable". Produce it? Neither! - When do we have the checking bits in moves?