Author: Vasik Rajlich
Date: 04:24:53 03/16/05
Go up one level in this thread
On March 15, 2005 at 08:39:00, Michael Yee wrote: >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.) > Yes - but in the case of an adapter, you'd miss the value-added of draw/resign & FRC. Personally, I'm interested in FRC support. Chess theory is becoming ridiculous. Did you see Linares? There were like 3 or 4 variations which everybody was playing in every game ;) >>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 ... See my reply to Dieter. When an engine is told to "stop" pondering, it will exit immediately and lose its place in the search. It will be awkward (and maybe lossy) to resume. I would suggest that you add some way for ponder mode to transition into think mode. Alternatively, you could adopt the UCI method of pondering, but then you break the intention behind your "move" command. > >>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?). > Well, this can turn into a religious debate - which we've had here a few times. :) I'll just point out that in both cases, if an engine needs to know what a "game" is, it must make this decision for itself. For example, using your syntax: 1) What if the opponent wants to take back a move, forcing the GUI to resend the new move list? Should the engine consider the result a part of the game? 2) What if the opponent "switches sides" - that is, the engine is asked to think for white, then later for black? 3) What if the opponent is just scrolling through a game (in think rather than analyze mode) - ie. he's not playing the "bestmoves" from the engine. 4) What if the GUI specifies positions by resending the move list anyway? We can blurr the line of what exactly a "game" is equally easily with both syntaxes - which isn't surprising since they map 1-to-1. :) >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. Yes - I agree - this does make sense. One bad point from your point of view is that some GUIs may be tempted to send the current position the same way in UCI & XCI. Anyway it's a minor issue, adding support for a "move" command takes a few minutes. > >>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. Agreed - though engine support for this will be very small, especially among amateur engines. > >>5) FRC support - nice value added. >> >>Vas > >Thanks for the feedback! > >Michael No problem - good luck. Vas
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.