Author: Bruce Moreland
Date: 13:11:27 10/06/05
Go up one level in this thread
On October 06, 2005 at 13:41:00, Robert Hyatt wrote: >On October 05, 2005 at 22:38:42, Bruce Moreland wrote: > >>If I recall correctly, EPD was a standard invented by John Stanback and promoted >>by Steven J Edwards. Stanback used it to communicate moves back and forth >>between programs via a text file. Edwards apparently had an aggressive plan to >>extend this via a suite of weirdly named utilities that I had never heard of >>before, so I expect they never were written. >> >>These days, EPD is used to store test suites. >> >>Some of the EPD operands appear to suggest the idea that you will run the EPD >>through your program, and out the other end will pop another EPD, which has a >>bunch of fields filled in that can be used to calculate and interpret results. >> >>Does anyone use these fields? Does anyone in practical reality ever use the >>fields other than "am" (avoid move), "bm" (best move), "id" (a title), and maybe >>"hmvc" and "fmvn", which are the two fields of the FEN that don't appear in the >>EPD? >> >>My guess is that all of the opcodes are dead except for these five. >> >>Anyone else have a contradictory opinion? >> >>bruce > > >It is pretty hopeless. Even PGN has its issues, such as no consistent way to >introduce annotations, or other computer-generated stuff like evaluations, etc. >FEN has quirks such as requiring an EP target if the last move was a 2-square >pawn push, even if no enemy pawn can recapture. > >Alas, they are so ingrained in everything, that changing the standards to be >more reasonable would be tough due to the volume of data already out in "net >land". Shoot, half the programs that produce PGN can't even get "castle" >correctly and use zeros rather than ohs. Not to mention things like 1.e4 rather >than 1. e4. I end up parsing proper and improper PGN correctly, just to keep >the complaint level down. :) FEN can't require it, since a FEN is just a position description, and Edwards doesn't own that standard anyway. FEN can allow it, and EPD can allow it, and PGN can allow it, and maybe EPD thinks it can require it, but I expect that it can't. I would balk at the bad FEN strings, personally. If you balk on them, you are important enough that people will change their crap in order to work with you. Anything that induces people to not emit FEN strings like "K1k5/8/8/8/P7/8/8/8 b KQkq a3 0 1" is a good thing. Let this stuff get caught early and fixed by those who screwed up. The reason that this bogus en-passant square is allowed is that there was resistance on the part of someone to the idea of verifying that the square denotes something legal. This is a perfectly fine attitude, but it is inconsistent with SAN, which never takes into account illegal moves when disambiguating. It is certainly insane to specify that the bug *must* occur. It's also weird if you look at the fragment of a binary standard that Edwards inserted into the PGN standard. He wants to store the move generator index of the move in there, which is a fine idea, but when faced with the problem of how to deal with different move generators generating moves in a different order, he specifies that the moves be generated and *sorted by SAN*. That will destroy the performance of any reader or writer, and at that point in the standard you can stop reading and shake your head. If he's going to even think about imposing that kind of performance burden on anyone ever, why not a fraction of that elsewhere? bruce
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.