Author: Roberto Waldteufel
Date: 07:05:10 09/16/98
Go up one level in this thread
On September 16, 1998 at 05:28:01, Dan Newman wrote: >On September 15, 1998 at 10:57:31, Robert Hyatt wrote: > >Posted by Robert Hyatt on September 15, 1998 at 10:57:31: > > > >Great. I'm glad you've started this. I think what we need is >a set of commands that is 1) simple, 2) clear, and 3) complete. >(I hope these aren't mutually exclusive.) > >One thing I would suggest is that all commands between engine and >interface be of the form . Then moves >sent to the engine would look like "move Nf3" instead of the current >xboard/winboard "g1f3". The reasons for this move command format are >1) consistency with the other commands and 2) it makes it easier on the >engine to distinguish moves from un-implemented commands--especially >important if we go to SAN representation. > >> >> Questions remaining: >> >> 1. should the interface program be "smart" and understand the rules of >> chess and take care of 50 move draws, draws by repetition, and so forth, >> or should we make the engines handle this themselves. I vote for the >> latter, since an engine should handle this as part of the game, and it >> will tend to keep the interface program simpler. > >The engines should be able to understand these things themselves. >However, I don't see why an interface program couldn't be smart--just >that it shouldn't be a requirement. One reason I can think of for >having a "smart" interface is so it can act as an arbiter when a >program makes a claim that the game is over or that the opponent made >an illegal move, etc. Currently if you send winboard/xboard a "1-0" >(for instance) whether white has won or not, winboard/xboard immediately >terminates the game, sends the result command to both engines, and >records the game (if you have that set up) to a PGN file with the result >as "1-0". This is of course no problem if both engines are functioning >correctly. But it does allow "cheating" of sorts: imagine you run a 500 >game match (1 sec/move) between two programs and one of them emits the >occasional erroneous "1-0" or "0-1" in its favor... > >> 2. move format? I vote for SAN. Easier to read, is more standard, is >> the PGN standard, etc. > >I slightly favor the non-SAN xboard representation of moves because that >representation is much easier to encode and decode--but if the consensus >favors SAN, I have no real objection. > >> >> 3. should the engine be able to communicate with the interface program >> for any reason? IE might the interface program have a window open for >> each program and let the programs send "analysis" to it for display in the >> appropriate window? Or should we "keep it simple, stupid" and not worry >> about this? > >What about having a core set of commands that all engines/interfaces >must implement along with a (perhaps large) set of non-essential commands? >For instance we could have commands to send analysis or other messages to >an interface window, but the interface need not implement these commands >and can just ignore them. > >I've often thought it would be nice to have commands that would cause the >interface (xboard/winboard or whatever) create special engine-specific >menus, dialog boxes, etc. These, again, could just be ignored by an >interface. If the interface implements these commands, it could send >back some sort of confirmation that a menu or dialog was created. The >menu commands might look something like this: > >menu >additem >displaymenu >deletemenu > >(The command string would be sent to the engine whenever the menu item >is selected.) > >Finally, how about a "comment" command so that an engine can send junk >to the interface to be recorded in a debug log file (much as winboard >has) without any worries of accidentally sending a valid command (and >freeing the interface code from having to figure out that the junk >is just junk). > >-Dan. 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
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.