Author: Robert Hyatt
Date: 19:03:04 09/16/98
Go up one level in this thread
On September 16, 1998 at 21:20:48, Roberto Waldteufel wrote:
>
>On September 16, 1998 at 16:01:10, Dan Newman wrote:
>
>>On September 16, 1998 at 10:05:10, Roberto Waldteufel wrote:
>>
>>>
>>>Regarding notation of moves, I would personally prefer SAN, but I think that the
>>>engine should be allowed to send either form of move (eg Nf3 or g1f3) and the
>>>interface should be able to parse the move properly. That way existing programs
>>>that do not support SAN will not be difficult to adapt. In fact, the more choice
>>>we give the engine, the better. We could allow, for example, g1-f3 or Ng1f3 or
>>>Ng-1f3. Captures could be supported both as Nd4 or Nxd4, with the x optional.
>>>Checks could be optionally indicated (+). The engine could then send its moves
>>>in whatever form is already implemented, the interface would interpret it and
>>>send the move to the other interface in a standard form, eg SAN, to the other
>>>interface. Now the interesting part is when the second interface sends the move
>>>to the second engine. We could allow the engines to specify a move format by a
>>>special command to their respective interfaces, eg:
>>>
>>>natation SAN
>>>
>>>This would tell the interface to supply moves to its own engine in the specified
>>>notation, although it would not alter the way the interface communicated with
>>>the other interface.
>>>
>>>Best wishes,
>>>Roberto
>>
>>I've begun to rethink this move representation stuff...
>>
>>Here's what I think:
>>
>>1) We should settle on exactly one precisely defined move
>> representation scheme for both engine and interface: either
>> SAN or the xboard representation. That is, I don't think
>> it would be wise to allow all sorts of variations in move
>> representation as that will give all sorts of headaches to
>> engine and interface writers and uncertainties as to what
>> is allowed and what isn't. Might as well keep it as
>> simple and well defined as possible. (On the other hand
>> who amongst us doesn't like the occasional programming
>> challenge?)
>>
>>2) SAN looks nicer than the xboard representation, but is much
>> more complex and difficult from a programming standpoint
>> than the xboard representation--it's absolutely trivial to
>> produce an xboard move. I typically do something like this:
>>
>> printf("%c%c\n", fromfile+'a', fromrank+'1',
>> tofile+'a', torank+'1');
>>
>> (It is a tiny bit more involved of course since you must
>> also handle promotions.)
>>
>> On the other hand to properly do SAN you must check for
>> ambiguities and generate the disambiguating chars. Also,
>> proper SAN must have the 'x' for captures, file letter instead
>> of piece letter for captures by the pawn, O-O and O-O-O for
>> castling, etc.
>>
>>3) Since this is principally (entirely?) for engine to
>> interface communication, readability or appearance
>> should take a back seat to simplicity.
>>
>>So I guess my vote goes to the xboard move representation because
>>it's much easier to implement. (I'm thinking more of ease for
>>beginners and for programs in the early phases of construction.
>>I already have a couple of routines for SAN translation that I
>>needed for reading PGN and for best move comparison in test
>>suite runs...so it's no problem for me what we settle on.)
>>
>>-Dan.
>
>I like the idea of keeping things simple, especially for interface/interface
>communication, where one standard is OK as long as it is complete (eg includes
>underpromotions, ep captures etc), but I see no need to be too strict about
>parsing engine--->interface communication. As long as the interface understands
>the move, it does not matter how sloppy the format, so we might as well try to
>cater for as many varieties of move format as possible. Consider, for example,
>how many "pgn" files are not truly pgn, eg spaces after move numbers:
>
>1. e4 e5 2. Nf3 Nf6
>
>is not proper pgn as far as I understand. It should be:
>
>1.e4 e5 2.Nf3 Nf6
>
this is backward. the move number is supposed to be separated from the white
move by a single space. so 1. e4 is correct. 1.e4 is not. This according to
the PGN standard I looked at a few months ago...
>with no spaces between move numbers and moves. However, I have never come across
>any software that could not interpret the first version correctly. The same
>tolerance for variation in format would seem to be useful for an
>engine--->interface message, since that way programs using all sorts of funny
>notations can all be properly understood by the same interface. By minimizing
>the amount of programming effort for the engine to comply with the interface's
>requirements (ie no need to change move format), we encourage programmers to
>support the protocol in their existing programs. I think that the interface will
>need the engines as much as the engines will need the interface, so we should
>make it as easy as possible to support it.
>
>Best wishes,
>Roberto
I don't disagree totally, but a standard is a *standard*. PGN has specific
requirements for 7 tags that are mandatory, others are allowable. Move format
must be SAN. move numbers in a specific form as above. Comments and analysis
inside delimiters, etc... Let's don't loosen things to the point that just
parsing the variants becomes a problem. I'd rather tell someone "look, you
screwed up here, this is the only move format we accept (whether it be
e4 or e2e4 is not important to me other than if someone is going to produce
a PGN game score, e2e4 is incorrect.) That way writing code is not nearly
so complicated as trying to read in the *real* PGN game scores, plus all the
*broken* PGN game scores that many programs are bad about producing. Ditto for
moves and commands. Let's be *precise* so that coding is kept simple...
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.