Author: Stefan Meyer-Kahlen
Date: 08:36:02 11/29/00
Go up one level in this thread
On November 29, 2000 at 10:44:14, Robert Hyatt wrote: >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. Sounds reasonable... >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. Your choice. I still believe that there are so many advantages in the UCI interface that it is definetly worth trying. >>>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. You will only get the FEN string if the game was not played from the starting position. I'd certainly prefer this to the "edit\n\nnew\force\na2a3\nc\nkabcd ..." of gnuchess. It's true that you'll get this before every search but in my point of view this is not a big deal. Adding support of the UCI interface into a winboard engine will just take one or two days including debugging and you will only have to change or add a few lines of code. That's not a big mess for me. >>>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.