Author: Dann Corbit
Date: 14:15:37 10/06/05
Go up one level in this thread
On October 06, 2005 at 16:11:27, Bruce Moreland wrote:
>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.
I think all three (PGN, FEN, EPD) belong to him.
>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?
Since readability does not matter in binary, a move number would work.
It would be necessary to have a "standardized" move generator that is
deterministic. Then, no sorting is needed. But I would not want to use someone
else's implementation of a move generator. But if I don't, I would always
generate the moves twice under those circumstances. Since move counts of 218
have been recorded, 8 bits would be needed to store it.
I suggest that <source_sqaure><target_square> (6+6=12 bits) is good enough even
though a {usually 8 bit} char is the smallest addressable unit, with the
"wasted" 4 bits used for promotion data.
e.g.
typdef struct chess_move {
unsigned from_sq:6; /* 0 to 63 */
unsigned to_sq:6; /* 0 to 63 */
unsigned prom_type:4; /* 0=Q, 1=N, 2=R, 3=B */
} chess_move;
It would be easy enough to pack and unpack from short using shifts and ands.
Cost of doing things this way is one char more than storing a move number and
you don't need to sort anything or use any special move generator.
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.