Author: Dieter Buerssner
Date: 12:52:25 08/21/02
Go up one level in this thread
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. In a typical engine, there are some places, where the engine has to interface with some GUI. For example, deep inside the search. 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. 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 ".". 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. 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. 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 ... 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). 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). 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/.... 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. Demand the protocol, to show when a new game starts, or at least to send the result of the last game. Then, the engine setup. I think, this is very well done in UCI. Regards, Dieter
This page took 0.01 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.