Author: Dann Corbit
Date: 13:17:22 08/21/02
Go up one level in this thread
On August 21, 2002 at 15:52:25, Dieter Buerssner wrote:
>On August 21, 2002 at 15:04:26, Dann Corbit wrote:
>
>>It might be nice if someone would write a formal BNF grammar for a chess
>>protocol that incorporates:
>>1. All the best features of Winboard
>>2. All the best features of UCI
>>3. Any missing features (perhaps that appear to be found in professional
>>programs)
>>4. Standardized access to opening books
>>5. Standardized allocation of cache buffers
>>6. Standardized analysis of EPD/FEN positions
>>7. An "auto" feature where the engine plays against itself (my pet request).
>>8. Other stuff that ought to be included (you fill in the blank)
>>
>>Having a formal grammar, it becomes trivial to write interfaces. Just toss it
>>to LEX/YACC or FLEX/BISON or PCCTS or Lemon and -- voilla -- you have an
>>interface command parser. Several different versions might become available as
>>standard, easy to bolt on, tool sets.
>
>I fear, lex/yacc are not suitable for this task. Without thinking about it too
>deep, it seems one would need to design the engine around the protocol.
This already happens, or the engine is bent to comply to it, if the protocol was
unknown when the design began.
>In a
>typical engine, there are some places, where the engine has to interface with
>some GUI. For example, deep inside the search.
I think that a formal API should also be specified. This would lead to a
complete tool kit. I would also like to see a queue for the commands. Special
commands like 'quit' would just flush the queue and exit. Which reminds me that
I would like to see a command that means 'quit when you have accomplished the
other tasks I asked you to do'. Maybe 'done' or something.
>Anyway, some randomn thoughts about a protocol, that should be easy to
>implement, and that allow the engine programmer all creativity. Perhaps WB does
>this already - but I think, it is prone to errors, because it is not strictly
>defined enough.
Hence the request for a formal BNF grammar. Once the grammar is totally
complete and parses without errors, then the ambiguity should be removed.
>Actually, it is rather easy for an operator in console mode to
>use. But one should get rid of this for an engine-GUI protocol. Engine authors,
>that like the console mode, can implement something anyway. Look for example at
>Analyze mode in WB. Everything, that can be done now, could be done with much
>less demands to the engine. Only allowed commands would be exit and ".".
Perhaps the analyze command can be removed. It's really very little more than:
A. Set the board to this position
B. Tell me what I should do here...
{possibly iterated if we are analyzing a whole game}
Which is little more than setpos and go {combined}, really.
>A
>setboard during analyze could be done by "exit\nsetboard\n\analyze\n". Moves
>similarily. For me, allowing moves in analyze mode (and setboard) was the only
>problem to implement this mode - otherwise it would be trivial.
Moving during analysis could be accomplished by simple commands. Really, we
have to pause the current analysis, change position, and analyze the new one.
Little more than a new setboard/go.
>I think for an engine-GUI protocol, one idea of UCI is much better: Minimize the
>commands allowed during search. Under UCI, I believe only stop and ponderhit is
>possible. Under WB many things are possible.
I think if a separate thread reads commands and puts them into a queue, some of
the difficulty goes away.
>Also, WB has all its modes. For an engine writer (when not starting from an
>engine, that already has some text interface for practical play), the modeless
>philosophy of UCI should be much better. The engine allways is in force mode.
>This "allways" may be a bit misleading. Actually, it will be most of the time in
>some search mode. But thos search mode are triggered by a command (like go in
>WB).
>
>Look at many messages in the WB-forum. How many engines have (subtle) bugs. For
>one color it must search by itself, for another it must wait for go ...
Another reason why a clear and unambiguous specification would be a big benefit.
I suggested (more than once) a formal grammar for Winboard to Mr. Mann, but he
felt it was overkill, I think.
>The black/white time/otime stuff in WB seems just stupid. (time will not be time
>for white, but time for the computer - but some commands will change side ... I
>guess there are many engines, that do not implement this correctly in all
>circumstances - Yace is one of those).
I like the idea of a separate clock thread. And all the clock functions should
be exposed to inquiry. The ACE project has an interesting idea with a special
sort of client server model. Both client and server can be active inquirers of
each other. So the server might query the client and the client might query the
server -- both asking for the sort of information they are interested in [and
clearly the needs are different].
>Also here, the idea of UCI, to start a
>search with all the info about the clocks is much superior IMO (and will
>probably yield in less engine bugs concerning these things).
I was not aware of this difference. Perhaps another reason why some like UCI.
>In WB, the engine keeps track of a game state, in UCI, it does not need this. I
>can live with both, but prefer the WB-method here. Mainly, because it makes
>implementing learning features easier.
>
>So, assuming a "sort of WB" protocol here. The GUI would send a move or some
>other commands. The engine would execute the move and commands. Then the GUI
>would send a "search command". It could send clock information, permanent brain
>status, ... together with the search command, or before it. I wouldn't care.
>Instead of a search command, it could also issue a ponder command. This would
>mean: You have time now. Do with it what you want. I got your last move - when
>the opponent moves, I will tell you.
>
>One thing, that both protocols don't have: Tell the engine, when a game/search
>tree/... is analyzed. Note, that a WB-GUI, that wants to implement automatic
>analysis of a game, will do this without going to analyze mode. So, knowing,
>that this is analyis, some engines with assymetric evaluation, may want to
>switch this off. Others may want to do other things (like persistent hash
>tables).
>
>
>Many other things are needed. We can learn from UCI and WB here. WB has the
>small features like name/rating/tellics/....
I think a superset command list would be nice. Some commands may be discarded,
if redundant. Mix and match to choose the best ideas.
>UCI has the displaying of currently searched move/nodes/tbhits/...
>Also the restriction of the to searched moves and the MultiPV mode.
>
>At the moment, UCI has indirectly support for any time controls, but it hides
>some info to the engine. For example when playing 40 moves/ 1 hour - 30 minutes
>for the rest of the game: In the first 40 moves, the engine will not know about
>the second time control. In WB, such time controls are not possible at the
>moment.
I would like to see as much flexibility as possible. The commercial programs
seem to have very flexible time controls. We should model what they do. Better
yet, allow any sort of sensible time control that might be useful for a contest.
In particular, handicap time controls where one side has {e.g.} G/30 and the
other G/57 would be useful for hardware matching contests. Another would be
where one side has some particular time control and the other infinite. Hence,
a person could tell the computer it must play the game in two minutes, but they
can think as long as they like. This will allow weaker players to have some
chance against the machine. I think some will like that.
>Demand the protocol, to show when a new game starts, or at least to send the
>result of the last game.
Reporting of terminations seems to be a major weak point (despite its apparent
simplicity) since so many engines get that bit wrong.
>Then, the engine setup. I think, this is very well done in UCI.
>
>Regards,
>Dieter
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.