Ugly UCI

[Roger Brown]

I agree 100%. I'm actually surprised so many are voicing concerns about UCI in this thread. I know Bob and H.G. are not fans, but I thought the debate was basically over. I thought winboard, as a protocol, was dead. Are there any new engines implementing winboard?

I never understand why people seem to think it's some sort of popularity contest. There are two protocols that do more or less the same thing; you pick the one that suits you best, for whatever reason. I really don't get why (some) UCI fans feel the need to put down CECP or people who prefer that as a protocol.
As for new engines that support CECP, there's probably some. Variant engines certainly, but there's only a handful of those. Either way, the communication protocol is by far the least interesting aspect of a chess program.

If you take a 35,000 ft perspective - all the top engines use UCI as their main (only?) protocol. So it can't be all that bad.

I find this type of comment equally strange. The strength of a program does not depend on the communication protocol it uses.
The most popular commercial chess GUIs use UCI as their native protocol, which by itself is sufficient reason for the top engines to implement UCI.

UCI and CECP are both perfectly serviceable and mostly interchangeable. UCI has some limitations that CECP doesn't have, if you find those important you can pick CECP. CECP has some peculiar quirks that UCI doesn't, if those irk you you pick UCI.

People say that there is a philosophical difference between the two: if you think the GUI is in control of everything and the chess engine is just a dumb piece of software that does what it's told, then go for UCI. If you think the chess program is in control and it's the GUI's job to communicate with the user on the program's behalf, then go for CECP. Perhaps there's something to that.

Hello Evert,

Please repeat that because I think that truth is being lost in the noise:

The strength of a program does not depend on the protocol it uses to communicate with the gui.

I find it fascinating that persons who pride themselves on devising and implementing logical programming, cannot help utilizing all sorts of illogical arguments for favouring one protocol over the other.

*All the top engines borrow from Stockfish, Fruit, Robbo, Ivanhoe, Rybka etc.*

So then....what exactly?

To say that UCI is not a perfect protocol is to voice a concern about it? CECP is not perfect either. H. G. is the first to say this. Repeatedly.

In fact, in using the engine, who really cares what protocol it uses? The gui should be able to use UCI and CECP engines simultaneously, if it is any good.

Oooops!

Do what you like I say...

*tongue in cheek*

Later.

[tttony]

I dont think UCI it's ugly, it just a simple protocol, compared to xboard that it's more specific and it has more options

I think UCI protocol needs to be updated

[jdart]

Learning is not a problem, the gui will not send you result command but you have the move history score plus the number of moves sent by gui. Take fritz interface for example. Near the end of game you will receive the typical position startpos moves .... More moves say 60 from both sides. Then suddenly the fritz will send position startpos moves g1f3. Why only 1 move my move history has more than 1? That signals to you that you are in a new game. That is fritz interface from chessbase, at least version 13 which I have. I already sent an email to support ucinewgame command. I don't know if this is supported in fritz 15 now.
Other interface like arena and winboard they send ucinewgame command that would tell you that you should be ready for a new game and have to clear your move history after doing your learning stuff and other things.

What you are describing is basically a hack to get around the fact that UCI does not send any game end indication to the engine (and Fritz apparently doesn't send ucinewgame either).

In fact, there is no easy way to know when a new game starts. And if you want to do learning, you really want to know when a game ends, not when one starts. Without a game end indicator, you can't do learning on the last game played before exit.

--Jon

[bob]

You and I have COMPLETELY different ideas about simplicity. Chess is NOT stateless. Yet UCI pretends it is and introduces the kludge of sending the entire set of moves. That's NOT "brilliant".

You don't have to focus in the protocol per-se but in how this affects the code needed to parse/handle it.

The protocol is brilliant (and you can clearly realize it was designed by a very good programmer) because allows the code needed to handle it to be:

- Straightforward

- Simple (meaning with the minimal number of 'if' branches and logic)

- General (meaning the same algorithm can handle all the different cases in an uniform fashion).

The aim of the UCI protocol is to make the code simple, that's why I think it was made for programmers by a (great) programmer.

I agree 100%. I'm actually surprised so many are voicing concerns about UCI in this thread. I know Bob and H.G. are not fans, but I thought the debate was basically over. I thought winboard, as a protocol, was dead. Are there any new engines implementing winboard?

If you take a 35,000 ft perspective - all the top engines use UCI as their main (only?) protocol. So it can't be all that bad.

- Steve

Poor logic. If that were true, then Windows must be the work of a genius and be better than any option. Give me Linux/Unix EVERY last time. The only virus I worry about is the Flu virus...

[Ferdy]

Learning is not a problem, the gui will not send you result command but you have the move history score plus the number of moves sent by gui. Take fritz interface for example. Near the end of game you will receive the typical position startpos moves .... More moves say 60 from both sides. Then suddenly the fritz will send position startpos moves g1f3. Why only 1 move my move history has more than 1? That signals to you that you are in a new game. That is fritz interface from chessbase, at least version 13 which I have. I already sent an email to support ucinewgame command. I don't know if this is supported in fritz 15 now.
Other interface like arena and winboard they send ucinewgame command that would tell you that you should be ready for a new game and have to clear your move history after doing your learning stuff and other things.

What you are describing is basically a hack to get around the fact that UCI does not send any game end indication to the engine (and Fritz apparently doesn't send ucinewgame either).

In fact, there is no easy way to know when a new game starts. And if you want to do learning, you really want to know when a game ends, not when one starts. Without a game end indicator, you can't do learning on the last game played before exit.

Game end indication is not a requirement for learning. It is the recording of positions, move scores, moves history and some evaluation on the trend of the move history that matters.

[Ferdy]

In fact, there is no easy way to know when a new game starts.

There is, here is one situation.
1. Your engine just started and it receives the following commands
a. uci
b. isready
c. ucinewgame (assuming the gui supported this, Fritz 13 does not)
d. position startpos
e. go wtime 10000 btime 10000
That would indicate you are in a new game. Why? because you did not receive the,

Code: Select all

go infinite

You also did not receive the,

Code: Select all

setoption name UCI_AnalyseMode value true

Assuming the engine supported such uci option.

2. Your engine was already started and you receive a fen with moves
a. ucinewgame (assuming the gui is not Fritz 13)
b. position fen <fen> moves <move1 move2 ...>
c. go wtime 10000 btime 10000
That also is the start of a new game because you receive the ucinewgame command

3. You did not receive the ucinewgame command from gui because you are using Fritz 13
a. isready
b. position startpos moves e2e4 e7e5 g1f3
c. go wtime 10000 btime 10000
If your move history is empty then consider it as a start of a new game.
If there are moves in your move history records, check if the position sent by the gui makes sense according to your move history and if they are not then consider it as start of a new game. Before deleting some info in your move history records, check the score of the moves close to the end part of move history, if there are scores there that have -1 queen for example consider it as you lose the game, if there are big positive score there, consider it as you won the game. Check also the number of moves in the move history, and make sure it is not a move history from analyses mode.

[abulmo]

I think UCI protocol needs to be updated

Personally, I think any protocol should never be updated.
Any update or new version creates another protocol. The main difficulty with Xboard/Winboard protocol that is constantly updated is that you do never know if your program, being a GUI or an engine is still compliant or not with a new addition.
IMHO, a protocol should have ZERO optional feature, it should be set in stone to be never updated, and be clear and concise.

[hgm]

The main difficulty with Xboard/Winboard protocol that is constantly updated is that you do never know if your program, being a GUI or an engine is still compliant or not with a new addition.

That is just not true. For one, XBoard protocol is never really updated, but only extended. And it is always extended in such a way that it is fully compatible with all previous versions. So programs that are compliant, be it GUIs or engines, will always remain compliant. It is just that they might look pretty stupid and user-unfriendly compared to engines that do use the protocol extensions, but they will continue to work in the way they did without problems.

It is just that they will not be able to benefit from the new possibilities offered by the protocol extensions.

A protocol that does not adapt to the needs of the era will become extinct. There was a time where even a decent evaluation function would hardly fit in memory, and hash tables were pure science fiction. So protocols did not include methods for controlling such hypothetical engine features. But memories grew, and hash tables became common, almost universal. When the protocol would not provide the means to set them people would resort to cumbersome kludges, like setting them through arguments in the engine startup command, or in ini files, much to the chagring of their users, who would have to dig through README files to figure out how to do things, as they would be different for each engine. What you propose would lock the world in such a permanent state of backwardness....

I agree on the issue of optional protocol features. I think it is madness that XBoard protocol allows engines to choose whether they want to receive moves in SAN or coordinates notation, and positions as FENs or lists of pieces.

OTOH, a protocol must address the most demanding user case, so it is natural that actual entities using it will not implement everything the protocol can mediate. Not everyone is interested in making an engine that can do analysis, let alone one that does multi-PV or can exclude moves from analysis. Not everyone wants to implement Suicide in addition to orthodox Chess. Not everyone wants to use tablebases in his engine. Not every engine is SMP. Some engines cannot even ponder, or have no hash table. And it is very desirable that a GUI would know what an engine can or cannot do. So letting the GUI know which command will or will not work on the engine at hand is in principle a very good idea, and prevents situations where the user would see: when I try such and such,everything hangs.

[hgm]

Poor logic. If that were true, then Windows must be the work of a genius and be better than any option. Give me Linux/Unix EVERY last time. The only virus I worry about is the Flu virus...

Indeed. It is pretty common in technology that the poorest system conquers the market. In our area of expertise of course Windows sticks out as an example. But it was also true for VCRs, and internal combustion engines are intrinsically inferior to Stirling engines, but virtually all cars still use them.

Technical quality hardly counts, it is all marketing. Almost to the point where the correlation becomes negative: "Almost everyone uses this, so it must be crap!"

[stegemma]

Yes, I know about "illegal move" response but this could solve only the validation problem. I've missed the "list" command... and I think that many engines doesn't implement it at all (mine doesn't). This would not be a problem, because I talk about a "reference engine", so the interface programmer could choose the one that implement both commands.

I don't agree when you talk about returning the FEN and saying that would be more simple to return just from-to square. The interface must already have a function to convert the FEN (or any other board representation) to its graphical board view, so converting the FEN returned from the engine would be a one-line instruction, for the interface programmer point of view. Something like this pseudo C++ code:

Code: Select all

while(im_not_bored_to_watch_this_engines_playing)
{
  string move = engineA.GetMove();
  string fen = engineX.Validate(move);
  if(fen=="false") break;
  Show(fen);
  exchange engineA <-> engineB
  engineA.MakeMoveAndThink&#40;move&#41;;
&#125;

I think that almost nothing could compare with this simplicity. The only drawback is that you still need a "list" command or something similar, if you want to show the user all the valid moves from a piece/square but this doesn't augment complexity.

As you and Bob say, winboard is not stateless so as chess isn't. If this is true (and it is really TRUE!) then why not to implement a "get actual state" command?

I take this opportunity to ask why someone think that UCI is a better protocol, well designed by a programmer for programmers. That's not true: UCI isn't a better protocol than winboard, just it is a different protocol. WINBOARD is think as a state-machine while UCI is a state-less-machine. Two different paradigma and anybody could choose the one he/she prefers or implement both. My one coin goes to Bob, because choosing a state-machine program to handle state-full games is the more intelligent choice (IMHO). of course WinBoard is an old protocol... but most of us are old programmers!