Author: Stefan Meyer-Kahlen
Date: 05:35:59 11/30/00
Go up one level in this thread
On November 29, 2000 at 21:30:18, Tim Mann wrote: >[Note: I'm sending this before reading any of the other replies in the >thread. If some of the questions are answered there, no need to >answer them again.] > >Your new interface sounds like a good thing. My approach with the >xboard/winboard protocol has always been to try to keep compatibility >with existing engines, but that forces me to always drag along the >ugly baggage of the way things used to be, and it makes it hard to fix >certain problems. Even if I add a new feature to fix a problem, old >engines that don't implement the new feature still have the problem. >Starting with a clean slate lets you produce something clean from the >start (assuming you do it well!), at the cost of having it work only >with your own engine(s) until you persuade other authors to go along. I think it's time for a change and hope that many authors of GUIs and engines will support this. Some authors have already shown their interest. >Posting your interface for comments is a good idea; additional input >should help turn up any problems early on, before a lot of engines and >GUIs are committed to it. From the way your message is worded, it >looks like you already consider the interface design complete and have >implemented in some software that is already released. Nevertheless, >I'm going to comment on it on the assumption that it's not set in >stone yet. It's included in the Shredder5 engine and GUI and in SOS already, so it will be hard to make major changes. >I like your approach to making sure the GUI always knows what the >engine is doing: having the engine never start a search >automatically, but only in response to one particular command, and >having a "bestmove" response always come back at the end of the >search, no matter how the search was stopped. For use this was the easiest way to keep in sync with the engine. >I don't like the fact that you always send a FEN position and move >history before every search (except when the special "ponderhit" >feature can be used to change a pondering search into a normal >search). In a long game, this could mean that a lot of data gets >stuffed into the engine before every move. Note that it's not safe to >simply send the FEN for the most recent position followed by one move >(or zero moves), because in that case, the engine does not know the >game history and does not know when it is legal to claim a draw by >repetition. You would have to at least start from the position after >the last irreversible move (pawn move, capture, or castling) and send >all the moves since that point. This is certainly feasible, but seems >quite awkward and potentially slow. We also thought about the problem that the "go" commands can get pretty long, so I did some tests with very long games (>1000 plies) ignoring the 50 moves rule. As expected the time needed to parse and execute the moves in hardly measureable which sound right if you consider that this can be done very fast by the engine if the engine is prepared to get long move sequences. You only have to take care to make the input buffer big enough. >One could address this issue by saying that the engine has to have >logic that says "If the position I was sent is the same one that was >already on the internal board, then I will assume that the game >history I have stored internally is still accurate", but I think that >would be an extremely bad idea. It would result in an absurdity in >the case where the user actually set up a new position that just >happened to be the same as the last one the engine saw. It also would >violate the "stateless" spirit that you seem to be going for in this >design. This was also discussed by us, a "smart" engine that can compare the last two move sequences and only execute the last move if the beginning is identical. We also didn't like it and also couldn't think of any advantage doing it that way. >I suppose you could also say that the GUI is responsible for detecting >and claiming draws by repetition. I don't think that's a good idea >either, because sometimes an engine will tend to make the same move in >a certain position repeatedly unless it *knows* the move has been made >before, in which case the engine makes a different move and may end up >eventually winning. I don't understand, so I will try to explain the way we did it. The engine never claims a draw, it just has to repeat the moves, if one move is leading to a draw by 3rd repetition, the GUI will claim the draw before executing the move. >A few more scattered points: > >Do you want to support chess variants? If so, you may need some >extensions to the notation, such as bughouse/crazyhouse drops (N@e4). >There also needs to be special notation for castling in Fischer >Random; you can't always just give the king's move and be able to tell >it is castling because that move wouldn't be legal otherwise. For >example, the king can start at f1 and castle kingside, landing on g1. We haven't considered chess variants yet. >If "isready" is sent while the engine is searching, does the engine >send "readyok" immediately, or not until after "bestmove"? "readyok" has to be sent immediately, but right now there is no real need to send it while thinking, except for a check weather the engine is still alive or has crashed. Actually there is no real need at all for "readyok" if things are working well except at the beginning. >What happens if the GUI sends other commands between sending "go" and >receiving "bestmove", such as setoption, debug, position, or another >go? "setoption", "position" and "go" must not be sent while thinking, this is missing in the specs. If it is sent nevertheless the engine can ignore it. "debug" can be sent anytime. >What should the engine do if the GUI sends it an illegal move in a >position command? What about an illegal position (several kings, etc.)? This should not happen as the GUI has to take care of it. >What bestmove should be returned by "go" if there are no legal moves? If there is no legal move the engine won't get a "go" command. >What if the engine's best "move" is to claim a draw by repetition or >the 50-move rule, without making a move first? The engine has to make the move only, the rest is done by the GUI. We wanted to make the engines as simple as posible, so the main work has to be done by the interface. All critital points like no legal moves or illegal moves has to be handled by the GUI. >What if the engine has a draw by repetition or the 50-move rule, but >only after making a move? Tournament rules require the player to >claim the draw and demonstrate the move, but not actually make the >move and hit his clock. The engine needs a way to say "make this move >and immediately claim a draw." By the way, both ICC and FICS have >special commands for doing that, but unfortunately they are >different. (On ICC, saying "multi Nf3 ; draw" is guaranteed to get >the draw claim in before your opponent can move. On FICS, you must >say "draw Nf3".) This is done by the GUI. >If "quit" is sent, must a bestmove still be returned from a search >that's in progress? I'd guess not, but then because the bestmove >might already be on the way when the GUI says "quit", GUI implementors >have to realize that they may or may not receive a bestmove in that >case. For every "go" the engine has to send a "bestmove", even when quitting. In my GUI I am sending a "stop" before "quit". >Wouldn't it make more sense for the copyprotection command to go >before uciok instead of after? Then the GUI can know for sure that it >isn't going to get the command before proceeding further. Yes, this would have been better, but there was a problem we couldn't solve. The UCI engines support a sort of "auto install" feature. If you want to install a UCI engine the engine is started and is identifying itself and sending its options, after that the engine is closed again. We didn't want to disturb this "quick start feature" with the copyprotection because it can also be used to find out about the engines's feature or its default settings. >In info, I guess the "pv" subcommand has to go last, because it takes >a variable number of arguments. Or is the GUI supposed to understand >"info pv e2e4 e7e5 depth 2 ..." because "depth" can't be a legal move? "depth" has to be recognized as a token, so the pv can be anywhere. >You might want to reserve some option names for future expansion of >the protocol. That way, if you want to add an option with a standard >meaning later, you are guaranteed not to clash with a private option >that some engine author has defined. This kind of thing worked well >in Internet email headers -- the standard there guarantees that no >header standardized in the future will have a name starting with "X-", >so such names can be freely used for application-specific extensions. Good point, I suggest to reserve options with the prefix "UCI". I will also add your comments to the protocoll. Are you interested in supporting UCI engines in Winboard? Thanks a lot 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.