Author: Dan Newman
Date: 13:01:10 09/16/98
Go up one level in this thread
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.
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.