Author: Don Dailey
Date: 00:10:56 05/31/98
Go up one level in this thread
On May 30, 1998 at 13:23:08, Peter Klausler wrote: >On May 30, 1998 at 11:51:57, Bruce Moreland wrote: >>>5) Death penalty for programmers who emit zeroes for castling >> >>The standard says nothing specifically about zero-zero. Edwards has >>said in a newsgroup post that zero-zero should mean "double forfeit". I >>am against this. This result is so rare that it can be handled with "*" >>in the result tag, and a comment, if need be. Much better that we be >>able to suck up zero-zero when an errant user types it in. > >Leaving aside the issue of whether a double forfeit needs to be >supported in the notation (though I think that it should be, as >a valid game outcome), the problem that I have with permissive >input routines is this: once anybody's PGN import routine can handle >some sloppy nonstandard construct, everybody's PGN import routine >has to handle it. It's very similar to the problem of proprietary >programming language extensions. It makes the development of a >PGN parser today an incremental process in which one continually >receives e-mail containing examples of constructs emitted by >anonymous, buggy software that some poor user wants your parser >to cope with. > >Handling erroneous user input is a good thing, and programs should >be as forgiving as possible there. But an interchange medium like >PGN needs to be defined with rigor. I think you are absolutely correct. Within reason the standard should be tightly defined. The idea, should be to implement a forgiving parser but encourage everyone (via a well defined standard) to produce output that does not vary from product to product. I even think the "1.e4" thing (as mentioned in Bruce's post) should be rigorously defined to be "1. e4" to be considered as conforming to the standard. Maybe not a big point but why encourage variation? The more variation is allowed, the more liberties the sloppy programmers will take thinking the standard is only a loosely defined guideline. I think it would be nice to know that any 2 products adhering to the standard will not vary in their output. My recommendation is that the standard is strictly defined. The Standards Document itself might contain a section which addresses the most common non-standard practices which the implementor might wish to accomodate for the sake of the poor end user dealing with sloppy implementors, or human produced SAN. ----------------------------------------------------------------- Here is a pet peeve of mine concerning FEN and EPD notation which is a minor nuisance to me: The standard states that the ep target square field always contains a target square if a pawn has moved two squares on the last move: rnbqkbnr/pppp1ppp/8/4p3/4P3/8/PPPP1PPP/RNBQKBNR w KQkq - rnbqkbnr/pppp1ppp/8/4p3/4P3/8/PPPP1PPP/RNBQKBNR w KQkq e6 These two positions are identical in every possible way. But the sequence of moves that led to them produce a different fen record if you adhere strictly to the standard. Why is this? Because the first position arose after 1. e3 e6 2. e4 e5 and the second position happened after 1. e4 e5 I can also construct examples where the same EXACT position can contain 2 or more different en-passant target squares. In neither case is any en-passant capture possible. This issue, while not important most of the time, is very important for some of the work I do, where I need to detect duplicate positions or order them in some cannonical way. The solution is simple and I propose that it is introduced as a minor change to the standard. The change will not break any software and not implementing it probably not hurt anyone either. The change I recommend is that an en-passant target square is only given when an en-passant capture is possible. No big deal, just a small improvement and with absolutely no bad side affects. My program already uses this more correct form. One interesting note to all of this. I was going to claim that this change is so minor, no one would be able to detect (from a file of fen records) that I was not strictly conforming to the standard. But this is not correct. There is at least one case where someone could point to a fen record my program produces (using this modified rule) and say, "Hey, this is not a strictly correct fen record!" I will leave this as a puzzle for the reader to solve. I don't think it's a difficult one. Here is one other "bug" with Fen (or Epd) but is not easy to deal with (and is certainly not a criticism of Fen.) Fen goes to some trouble to deal with the 50 move rule using a device called the "half move clock." This is a good mechanism and I have no complaints. But it doesn't address another (probably more important) issue: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - These two fen positions are clearly different, even though the generated fen output is identical. In the second position, white can achieve a draw by playing Nf3! Fen does not deal with this problem. Does everyone see the point? I am not proposing any change here and I'm sure all of the programmers and probably most of the serious chess program owners are aware of this drawback of FEN (and probably most other formats chess programs use to store positions.) I do not know of any mechanism to deal with this that is not cumbersome. If you want 100% correct representation you must output EPD records with game scores attached to them. Using all 6 fen fields there is slightly more information, but this is irrelevant in detecting the imminent draw: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 5 - Don
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.