Author: Robert Hyatt
Date: 07:44:14 11/29/00
Go up one level in this thread
On November 29, 2000 at 02:46:20, Stefan Meyer-Kahlen wrote: >On November 28, 2000 at 13:33:06, Robert Hyatt wrote: > >>On November 28, 2000 at 09:15:30, Stefan Meyer-Kahlen wrote: >> >> >> >>There are a couple of _really_ ugly things in this. Ugly because they are >>diametrically opposed to other GUIs like xboard/winboard/robofics/etc. >> >>1. The search vs ponder stuff. I don't see why the GUI has to tell the >>engine to begin to ponder. This makes no sense to me, from either a GUI >>point of view, or an engine point of view. But the main problem is it is >>so different from xboard that the code is going to be very messy. And for >>no gain that I can see. > >We think that it is absolutely necessary to tell the engine to ponder to keep >control of what the engine is doing, otherwise the GUI is never sure weather the >engine is pondering or waiting or doing whatever. Also for some commands (e.g. >searching in a database) the GUI has to be sure that the engine is not wasting >cpu cycles in the background. > >>2. sending too much control info to the engine. The engine ought to be able >>to manage itself, sending moves to the GUI and reading moves from the GUI. >>Having a protocol to alter other things like selectivity and so forth is fine, >>as is having a protocol that allows the engine to tell the GUI certain things >>like offer a draw or whatever. > >Why can't the engine manage itself in this protocol? > >Draw offers are handled by the GUI right now, but it is certainly possible to >extent the protocol. Which control info is not necessary in your opinion? First, it would seem (to me) that offering and accepting draws is an engine function, not a GUI function. IE in a real chess game, the two humans handle those functions, not the TD/arbiter. The thing I don't like are things like "ponder". The reason is that it is so different from winboard the code will turn into some spaghetti in a few places. Obviously, in my case, winboard/xboard are going to be _the_ interface of choice for the people that use Crafty. And that means I have to maintain compatibility with the xboard protocol. To make things like "ponder" and the like work, as well as the idea of the engine not making a move until the gui tells it to, is going to require a significant number of changes, while keeping the current xboard / winboard support "as is". That looks messy. > >>3. The main thing you have really addressed is "race conditions". One thing >>the winboard/xboard protocol is sorely missing is some sort of ack/nak facility >>(it has a sort of nak facility if you send an error message) to eliminate the >>race conditions that occur. IE the interface says "start a new game" and >>immediately assumes this has been done. If you don't check for input quickly >>enough, you miss the new game indicator for a bit, and if you send a move, >>that move can be sent to the server with an immediate "illegal move" response >>since your move came from a game that has ended. >> >>I don't personally like to ack/nak every message, as that does nothing more >>than ramp up traffic. But for critical events (ie new game) an ack would be >>nice so that xboard would wait for you to say "ok" before it would proceed to >>start a new game, etc. > >There is no new game command in this interface. > >We also were aware of this problem and also didn't like the ack/nack mess, so we >only introduced it in the "ready/readyok" and "uci/uciok" commands. If desired >one can always simulate the ack/nak with ready/readyok, but this is not >necessary as we always keep control over the engine. Implicit sync is done as >there always have to be a "bestmove" command from the engine for every "go" >command from the GUI and that the engine must not start searching or pondering >without being told so. That was introduced to avoid the ack/nak thing and don't >having "race conditions". the "ok" messages are a form of acknowledgement/negative-acknowledgement, and perhaps the idea of letting the gui specify the board position is a good one. But in my case (and perhaps for others as well) it adds another level of complexity as when I get a FEN string to set a position, I assume we are at a "brand new position" having nothing to do with previous positions. I clear the game history, set the starting game position to what was given to me, etc. This turns very messy. > >> >>Before this goes too far, it would seem reasonable to design an interface >>once and for all, that everybody will use. > >Hey, that's what we wanted to do with this thing :-) > >> That means we need Tim Mann (or >>someone familiar with xboard/winboard that is willing to make the needed >>changes), someone familiar with ROBOFICS, so that we can have one common >>protocol. > >This has been discussed for years now and there has been many attempts to start >a discussion about a new interface, but after a few days those discussions faded >aways. Tim Mann did a great job "inventing" winboard but I guess that he is too >busy working out a new interface. It is quite a lot of work to design a new >interface so if somebody else had done done Rudolf and I could have saved much >time, but this did not and probably won't happen. > >Rudolf and I are familiar with winboard as we have written engines and user >interfaces for it, so we know of its problems. > >The UCI interface is certainly not perfect, but it's pretty good :-) and there >are already engines and GUIs supporting it. > >If we all are waiting for the perfect interface we will still use winboard in 10 >years. > >> Right now, what you are using is so different from the >>xboard/winboard protocol, it will make some things very messy to keep >>compatibility with both. > >Is it really that different to winboard? I don't think so. In operation? Yes. See my previous comments. > >>I don't like the idea of dictating what the engine can and can't do without >>permission from the GUI. > >What is missing? What should or can the engine do? > >> I think the engine should be free to do anything it wants. > >See above. If you let the engine do what it wants to you get syncronization >problems and need your ack/nak stuff. > >> Otherwise the GUI might assume the engine is idle and not using CPU >>time and be wrong. > >This can't happen in our interface as it is designed in a way that the GUI >always knows what the engine is doing. The opposite is true: If you let the >engine do what it wants to this will happen. > >> Specifying the comm protocol is fine. Specifying a time >>limit for responses to commands is fine. But don't specify what the engine can >>and can't do while waiting for another command... ie why can't it "ponder" >>all the time? > >see above. > >> Why does it have to keep searching after it has found the >>shortest possible mate? etc... That last point might be important as it >>wastes compute cycles. > >There are smarter ways to wait. This is done for synchronization, see above. >Also this is only forbidden while pondering. > >Thanks for your comments > > Stefan
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.