Author: Dann Corbit
Date: 19:22:32 09/09/03
Go up one level in this thread
On September 09, 2003 at 18:33:22, Steven Edwards wrote: [snip] >EPD: There are several items of concern: > >1. Currently, the first four EPD fields match the first four FEN fields. This >was done to save space with the idea that the "hmvc" and "fmvn" EPD operations >could provide the extra information if needed. This is rather arbitrary and I >suggest that every EPD record have the same first six fields as a does a FEN >record. Alternatively, EPD opcodes can be defined for the (current) first four >EPD fields and so there would be NO required fields at the start of an EPD >record. > >2. Representations of string/symbolic data in operands is inconsistent with >respect to the need for quoting. This is also the case with PGN tag values. A >uniform rule is needed for both. > >3. Representations of time and date value operands needs to be formalized along >with a provision for sub-second decimal resolution. > >4. The centipawn evaluation operand type needs a mate score indication >correction. > >5. The centipawn evaluation operand type probably needs to be deprecated and >replaced with a pawn evaluation operand type with a provision for sub-pawn >decimal resolution. perhaps ced instead of ce. >6. The time control operand type needs to be extended and formalized. PGN has a >problem with this as well. > >7. A formal XML schema could be useful. Likewise for PGN. > >8. Removal of record length limitations. > >9. Explicit support for 64 bit integer values (decimal and hexadecimal) as >operands. > >10. Inclusion of progam-to-program comand protocol opcodes. Approximate depth of analysis in plies (acd is what Crafty uses, dep for Hiarcs. An essential field for me). Your own SAN kit for use with crafty supplied this valuable information. For me it is crucial (without it, the ce is practically meaningless) Approximate number of nodes for analysis (acn is what crafty uses). This is very valuable if I have two records that have the same depth. If one has a larger node count, it is probably better data (if the engine does not change). For positions where e.p. capture is not possible, it is very bad to have the field tagged with an e.p. square. Quite frankly, that part of the standard was broken. A formal standard for a compact binary format would be nice. I have some suggestions there.
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.