Author: Tony Werten
Date: 23:34:55 10/06/05
Go up one level in this thread
On October 06, 2005 at 17:15:37, Dann Corbit wrote:
>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.
It might be easier to just give a movenumber and specify in wich order the moves
have to be generated.
ie start with A1,B1..A2..H8. Moves are generated in the order of direction,
North,NorthEast,East etc. Single square moves before multiple squares (Qa1-a2
before Qa1-a3,h2-h3 before h2h4,Kf1 before O-O (Kg1), major promotions before
minor etc.
This way, moves will fit in a byte. It won't be pretty though.
Tony
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.