Author: José Carlos
Date: 13:40:27 08/21/02
Go up one level in this thread
On August 21, 2002 at 16:17:22, Dann Corbit wrote:
>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.
I mostly agree with you, Dann, but you're missing here time management, ie I
do different things with my time if analyze, ponder or search mode. Somehow, the
engine should know it's not playing a game.
José C.
>>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.