Author: Robin Smith
Date: 12:13:48 09/11/03
Go up one level in this thread
On September 11, 2003 at 10:59:32, Robert Hyatt wrote: >On September 10, 2003 at 21:11:51, Robin Smith wrote: > >>On September 10, 2003 at 13:26:38, Robert Hyatt wrote: >> >>>One thing I really dislike is resumption of moves. IE >>> >>>23. e3 (some comment) then 23... black's next real move. The "..." looks >>>ugly. In many old annotations, the better form 23. ... black's move makes more >>>sense. >>> >>>But in any case, nn... is ugly... >> >>Why? Most chess books published these days use nn... Also this is what chessbase >>produces when you export a game to text. Ugly or not, I think nn... has become >>the norm, and it takes less space. > > >The original intent was for the "..." to indicate "there is a move missing, >you need to back up to the last move actually played..." > >All the books I have use 21. ... Re7, for example. Every book by Gambit uses nn..., Everyman Chess uses nn... etc. Some of the modern books I have don't use a . for white moves, and therefore for a black move use nn ... (Cadogan, Batsford, Pergamon etc). The books I have that use nn. ... are very old, or by small publishers like C.I.R.C. Do you have an old book collection? >It is easier to >parse. One token (always) for the move number. One token for a missing >move, one for a real move. Rather than one token that can be a move number >or a move number _and_ a missing move. I think there is a big advantage to staying cosistent with what both Chessbase and ChessAssistant do, which is nn... If PGN readers suddenly can't parse Chessbase or Chessassistant output, that seems like an even bigger problem. Perhaps there could be a different token for missing moves, besides ..., to fix the parsing problem?
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.