Author: Michael Yee
Date: 05:39:00 03/15/05
Go up one level in this thread
On March 15, 2005 at 06:01:06, Vasik Rajlich wrote: >On March 14, 2005 at 12:45:22, Michael Yee wrote: > >>The protocol proposal has been updated to reflect several good >>comments/suggestions. >> >>(1) There is now a table of what commands are valid in each state. This makes >>the protocol clearer and even look simpler than it did before (at least to me >>:). Thanks to Harald for this suggestion. >> >>(2) New commands from GUI to engine : getstartpos, getmovelist, getresult >> >>This enables the protocol to be truly extensible since variants that aren't >>officially supported by the GUI can still be supported by letting one engine be >>the "referee" or "arbiter". This interesting idea came from Reinhard (also the >>source of the move and position formats for officially supported variants >>FRC/CRC). >> >>(3) New command from engine to GUI : error >> >>------ >> >>Even if people are dead set against introducing a new protocol into the mix, I'm >>curious what UCI fans think about some of the extensions. Specifically, >> >>- describing what options mean, >>- custom thinking output, and even >>- getstartpos, getmovelist, getresult >> >>could be added without too much fuss (while maintaining the core philosophy of a >>stateless engine)... >> >>Thanks, >>Michael > >It looks like quite a bit of work has gone into this. I glanced only quickly - >here are a few points to consider: > >1) It's good that very little work will be involve to adapt a UCI engine. > It actually should be pretty easy for a GUI author to adapt their UCI handler, too. (Alternatively, a UCI to XCI adapter would be trivial.) >2) Pondering (Dieter also mentions this) - you should clarify how this works. I >guess you don't want the ponder move to be made on the "internal" board. Is the >engine responsible for resuming the normal search in case of a "ponderhit"? > >Also keep in mind that some GUIs (specifically Chessbase) will display the >ponder move and ponder analysis from the engine. The GUI should have some way to >get this info. > The way I envisioned pondering was this way: - engine remembers "official" state of its internal board - engine can temporarily make a predicted move - engine outputs regular thinking lines where the first move in the pv is always the pondermove - when engine gets next move command, it can decide for itself whether it predicted correctly, etc. This approach seems pretty general (and doesn't add any new commands), e.g., an engine can change its ponder move and alert the gui. An alternative solution would be to have a special style of "info" used during pondering, e.g., info pondermove move ... >3) "move" command - there's a sort of myth floating around that this provides >"state". It's nothing more than a difference in syntax - there's a simple 1-to-1 >mapping between the GUI specifying the position in UCI, and doing so in >XCI/Winboard. Personally I wouldn't break the syntax, but anyway the adaptation >to an engine is minor here. > I also initially thought it was identical, but it might not be totally 1-to-1. The key difference is that when getting a move command in XCI, the engine can (and is supposed to) assume that it's a continuation of the current game. Under UCI, the engine can *infer* that the move list represents a continuation, but only if it remembers the previous movelist (which goes against the spirit of UCI?). In any case, it might make sense to extend the XCI position command to allow an initial position followed by a move list (to allow more backwards compatibility with UCI). In XCI, a position followed by movelist would indicate the start of a "new" game/game fragment and would simply be another way of expressing a position. >4) Draw & resign - nice (though small) value added. I've been working on my >engine for almost two years and still haven't even touched draw offers & >resigning - this is really a "professional" topic. Keep in mind also that the >GUI should be able to adjourn games as well - users are now used to a >centralized option in the GUI for this. > I agree that the benefit might not be too great here. But there are a couple ways it can make people's experiences a little easier/nicer: (1) If both engines see a draw (by rule) coming up (say in 12 moves), the game can end by mutual agreement sooner than if the GUI had to detect the actual draw. This might save engine TD's a little time. Similarly, the resign feature might allow engines to resign earlier (since they're presumably smarter than the GUI). (2) In a human-engine game, it allows the human to propose a draw. I suppose a GUI could simulate accepting the draw on behalf of an engine, but it wouldn't really seem fair. >5) FRC support - nice value added. > >Vas Thanks for the feedback! Michael
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.