Author: Stefan Meyer-Kahlen
Date: 10:03:14 11/29/00
Go up one level in this thread
On November 29, 2000 at 12:53:01, Robert Hyatt wrote: >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. So do I and I bet all the users. That's why we have to agree on one interface. I made the first step and we will see who is following... >>>>>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. Yes, go for it! >>>>>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.