Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: new autoplayer interface standard

Author: Roberto Waldteufel

Date: 18:20:48 09/16/98

Go up one level in this thread



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

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



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.