Author: Robert Hyatt
Date: 09:53:01 11/29/00
Go up one level in this thread
On November 29, 2000 at 11:36:02, Stefan Meyer-Kahlen wrote: >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. I wouldn't disagree. I would also agree that Intel would _love_ to be able to add registers to the X86 architecture. But that ugly C-word (compatibility) caused them to stick with the ugly choice made so long ago. Compatibility is a big issue. There are multiple interfaces that work with the current xboard protocol, in spite of the design holes here and there. IE xboard, winboard, robofics, my custom interface I wrote, the chessbase interface, etc... I don't mind seeing change, but I would prefer one solid standard, not N. > > >>>>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. It is more than that for me. IE the pondering issue is _very_ complex in Crafty, because I couldn't originally afford to do a threaded version of pondering due to the demand for dos versions. I could rewrite now to put the interface in one thread, the engine in another, but it would both be a lot of work, and lead to headaches when it doesn't work with xboard. I have wanted to ignore DOS anyway, and re-do the way I ponder. Which would be a major design change, but it would probably be worthwhile, since threads work fine in windows and unix. > > >>>>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.