How does UCI proto handle ...... vs Xboard/winboard proto

[CRoberson]

I've implemented both UCI and Xboard protocols. In my experience, UCI was less work to support. There were a few extra issues because I was implementing both protocols in one engine.

To be clear, there are 2 versions of the UCI protocol. I have implemented UCI-2.

On pondering:
When the engine makes its move, it sends the following string

bestmove mmmm ponder pppp

This tells the UCI GUI that the program makes the move mmmm and plans to ponder pppp. So, the engine tells the interface what it is going to ponder. After that, the interface sends back a go comand with the ponder command, the ponder move, the two time infos and the two inc infos. This is the same move that the engine sent it to start with. The only reason for this way of doing things is to keep things stateless to the engine.

If the engine changes its ponder move during the ponder process, then the engine has to adjust its interpretation of the commands ponderhit and stop(pondermiss). Those commands come from the GUI when the opponent makes his move.


On time control:
UCI does basically the same as xboard/winboard. It sends the engine to go command and lists time left and increment for both sides. Xboard/Winboard does the same thing. It is up to the engine to decide on how much time to think. I have easy move, normal speed move and extended time moves implemented under both Winboard and UCI. The only time it tells the engine when to move is when the user decides to force the move.

On take back move:
This is an advantage to the UCI protocol. It handles take back move automatically. There is a disadvantage in how it goes about it. So, that is merely a trade off to choose from.


On EGTB:
The user interfaces have buttons for turning on and off the two EGTB features. The first of the two allows the GUI to handle EGTB at root level. The second option allows the engine to use EGTBs and where the EGTBs reside. Engine support of the second feature is optional.

On Book Moves:
There are two features here as well. The first allows the GUI to use a book. The second allows the engine to use its own book. You can actually turn both on, thus making the engine book a secondary book. Engine support for the second feature is optional.

On Analysis mode:
This is easier in UCI. The engine always reports from its perspective. The GUI always shows from whites perspective in analysis mode and always from engines perspective in game mode. Given that take backs are automatic in UCI (from the engines perspective), a full featured Analysis mode is easy to implement. A stateless model makes this easier.

There is a tricky issue with your engine is pondering and finds a forced mate or stalemate which ends the search.

So, the choice of protocols is merely a choice of trade offs.

From the commercial consumer's perspective, they will like UCI systems better. It allows them to use the same book with all the engines and handles user selection of engine options through the GUI. So, the lesser techno user can easily set engine options and all engines set their options seemingly the same way (from the user perspective).

The only issue I have with UCI is not with UCI; it is with the GUI's. The best coded one seems to be the ChessBase one, but it doesn't support access to ICC/FICS. There are some that support access to ICC/FICS, but each has some issues. That is not the fault of the protocol.

[Dann Corbit]

For configuration, UCI is better.

For game play, Winboard is better.

If chess were stateless, then UCI would be Winboard's equal in game play. But chess is not stateless.

I think that the best protocol would be a combination of the two feature sets.

Winboard is moving in this direction a little bit.

[CRoberson]

For configuration, UCI is better.

If chess were stateless, then UCI would be Winboard's equal in game play. But chess is not stateless.

Actually, Chess itself is mostly stateless. The game would be completely stateless if it weren't for EP rules and some Castling rules. Also, 3 fold rep and 50 move rule.

[Greg Strong]

For configuration, UCI is better.

If chess were stateless, then UCI would be Winboard's equal in game play. But chess is not stateless.

Actually, Chess itself is mostly stateless. The game would be completely stateless if it weren't for EP rules and some Castling rules. Also, 3 fold rep and 50 move rule.

But it's not really stateless from the engine's point of view... The hash table still holds valuable information from the previous search, for example. Pretending that the game starts over from the beginning each move isn't really helpful IMHO.

[Dann Corbit]

For configuration, UCI is better.

If chess were stateless, then UCI would be Winboard's equal in game play. But chess is not stateless.

Actually, Chess itself is mostly stateless. The game would be completely stateless if it weren't for EP rules and some Castling rules. Also, 3 fold rep and 50 move rule.

It is incredibly difficult for a UCI engine to incorporate learning in a serious way and it is trivial for a Winboard engine to do it.

The reason is game state.

[hgm]

From the commercial consumer's perspective, they will like UCI systems better. It allows them to use the same book with all the engines and handles user selection of engine options through the GUI. So, the lesser techno user can easily set engine options and all engines set their options seemingly the same way (from the user perspective).

This is exactly the same in WinBoard. All engines can use the GUI book, and the engine options can be set through the GUI dialog. So why would they like UCI better?

[Edmund]

From the commercial consumer's perspective, they will like UCI systems better. It allows them to use the same book with all the engines and handles user selection of engine options through the GUI. So, the lesser techno user can easily set engine options and all engines set their options seemingly the same way (from the user perspective).

This is exactly the same in WinBoard. All engines can use the GUI book, and the engine options can be set through the GUI dialog. So why would they like UCI better?

What I am personally missing with the winboard specification is the standard of thinking output.
Of cause the basics: ply, score, time, nodes & pv are implemented, but there is no standard for the form of the pv and the score (mate scores / normal scores).

Furthermore I am missing the support for additional information: eg. fail low/high, hashfull, egtb hit count, current move.
Now the only option is to add the information to the pv, but it is not possible by the gui to use the information in any way.

[hgm]

Indeed, this is a problem. Because the PV was a free-format field, we cannot enforce any format without breaking compatibility with many existing engines.

But the up-side is that exactly because of the free format, adding extra info to the PV is allowed. As long as the only thing the PV is used for is to display it, this should work fine. Although I agree it would be nice if there is some standardization here, that would make it more obvious to the user what he is reading. This could be added to the protocol specs as a recommendation. Engines that would follow it could announce it in a feature command at start-up, so that the GUI could actually use it.

But what could the GUI possibly use this information for, if not for display? It seems to me that fail-low / fail-high info belongs in the PV anyway. (More accurately, it would replace the PV, as you have no PV on a fail.)

I was thinking on a format that would prefix the info on the PV, in the format

egtHits {currentMove seqNr/totalNr} PV

with !! and ?? as fail-high and fail-low indicator at the end of the PV. The egtHits, and other optional numbers, could come before the part enclosed in {}, as a quite natural extension of the four numbers that are there now. I am not sure about hashFull; this seems quite useless. The hash should always be full, except for the first few seconds of the game, not? Hardly interesting.

As to the scores, the recommendation would be to use own POV for the sign, (also during ponder), and 100000+DTM (in full moves) for mate scores.

[Edmund]

But the up-side is that exactly because of the free format, adding extra info to the PV is allowed. As long as the only thing the PV is used for is to display it, this should work fine. Although I agree it would be nice if there is some standardization here, that would make it more obvious to the user what he is reading. This could be added to the protocol specs as a recommendation. Engines that would follow it could announce it in a feature command at start-up, so that the GUI could actually use it.

But what could the GUI possibly use this information for, if not for display? It seems to me that fail-low / fail-high info belongs in the PV anyway. (More accurately, it would replace the PV, as you have no PV on a fail.)

The advantage of a standardized pv would be the ability of the gui to step through the pv of any given engine on an analysis board. Concerning the other values, if the gui could understand them, it could automatically calculate nps, it could let the user decide which values to display and it could do some additional statistics, graphs, etc.

I am not sure about hashFull; this seems quite useless. The hash should always be full, except for the first few seconds of the game, not? Hardly interesting.

I find it quite a useful indicator for determining the required hash size for a specific engine. You can reset the hash and see how much percent it fills up given the average movetime in a game.

As to the scores, the recommendation would be to use own POV for the sign, (also during ponder), and 100000+DTM (in full moves) for mate scores.

I would prefer const - DTM, as the lower the DTM the better. Furthermore I would propose to stick to 16bit scores. Something like 32000 or 30000 is also enough.

[hgm]

The advantage of a standardized pv would be the ability of the gui to step through the pv of any given engine on an analysis board.

WinBoard already does that. No standard is really needed for that. As long as the engine puts something in that field that looks reasonably like a PV, WinBoard will be able to pass it. You can have move numbers and PGN comments in there, it does not matter. Only for engines that print smilies it does not seem to work. But an standard can be violated to break operation, and putting smilies in something that is supposed a PV could be considered as a violation of the extremely liberal standard we have now. The field is specified to be for a PV, not for smilies... As long as it is legal PGN, WinBoard does not care, but unprotected smilies are not PGN.

Concerning the other values, if the gui could understand them, it could automatically calculate nps, it could let the user decide which values to display and it could do some additional statistics, graphs, etc.

Calculating NPS canbe done in the existing standard, and is indeed already done in WinBoard. There is a well-specified standard for nodes and time, and that is all that is needed (and used).

I find it quite a useful indicator for determining the required hash size for a specific engine. You can reset the hash and see how much percent it fills up given the average movetime in a game.

Well, if the average opinion is that it is useful, we could have the engine optionally output it (when it is not 100%) as a percentage, after egtHits, before the {} move stuff. The trailing percent sign would reveal it as the hashfull, which would also be apparent in GUIs unaware of the standard, which display it bare.

I would prefer const - DTM, as the lower the DTM the better.

But then you have to subtract to deduce the DTM, and I hate that. This is why I prefer adding. When the GUI recognizes the standard, it can print it in any form it likes (e.g. something like 'M6' when it receives 100006), and the encoding is immaterial. For GUIs that would not recognize the standard, and present it to the user as a score, the user only has to read the leading 1000 as if it were an M.

Furthermore I would propose to stick to 16bit scores. Something like 32000 or 30000 is also enough.

I intentionally picked something that is outside the 16-bit score range. Engines uses such scores internally, and they should thus be reserved for whatever the engine wants them to mean. Conventional scores should ly outside that range. Otherwise there might be collisions.