Ugly UCI

[Joost Buijs]

What a nonsense!

[Steve Maughan]

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!"

Just to be clear, I did not say UCI is better because it's popular (which I think is implied by Bob's analogy). I said the best engines use it, so it must be "OK" (i.e. they must consider it does not weaken their engines).

- Steve

[hgm]

I've missed the "list" command... and I think that many engines doesn't implement it at all (mine doesn't).

I am not aware of any "list"command. Did you mean to write "lift" command?

Not many engines do implement it, but that is because most engines are Chess engines, and the rule of orthodox Chess are already known to WinBoard. So there is no reason to consult the engine. This feature is purely intended for variants, and in particular variants that the GUI does not know the rules of. Nebiyu, Sjaak II and HaChu are variant engines that implement it.

But the point was that the mechanism you suggest already is provided in WB protocol, for exactly the reason you suggest it: to allow the GUI to be rule-agnostic.

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 did consider addition of a third, 'referee' engine to WinBoard, but performance-wise this was problematic. Especially the need to convert PVs from SAN to coordinate notation or vice versa was just too slow. The problem is that an advanced GUI would want to support features like PV walking on a variation board, and having to request the position after each next PV move from an external entity is just too cumbersome.

This is why I introduced the "piece" commands instead. Through the piece descriptions the GUI can generate all moves without further assistance by any (referee) engine, e.g. for the purpose of SAN parsing or target-square highlighting, even in variants it is totally unaware of. True, it does require a bit more code in the GUI, but in terms of performance that really pays off.

I still think the strategy to let the GUI take as much work as possible out of the hands of the engines is a winner. The trick is to do it such that the code in the GUI can remain general, i.e. work well for orthodox Chess and weird variants alike. Complicating the engine to make the GUI simpler is not a good trade-off.

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;

It doesn't look any simpler than

Code: Select all

while(im_not_bored_to_watch_this_engines_playing)
{
  string move = engineA.GetMove();
  board[TO(move)] = board[FROM(move)]; board[FROM(move]] = EMPTY;
  Show(board);
  exchange engineA <-> engineB
  engineA.MakeMoveAndThink&#40;move&#41;;
&#125;

and if you look what actually must happen for execution of the code (communication between two processes through pipes, versus simple assignment), there is a world of difference.

[stegemma]

[...]
It doesn't look any simpler than

Code: Select all

while(im_not_bored_to_watch_this_engines_playing)
{
  string move = engineA.GetMove();
  board[TO(move)] = board[FROM(move)]; board[FROM(move]] = EMPTY;
  Show(board);
  exchange engineA <-> engineB
  engineA.MakeMoveAndThink&#40;move&#41;;
&#125;

and if you look what actually must happen for execution of the code (communication between two processes through pipes, versus simple assignment), there is a world of difference.

Your code doesn't works for en-passant captures, castling and promotions. Of course you only need to pass back some detail but still the GUI should know the game rules and won't works for any further variant of chess, that does some strange thing while moving pieces.

The problems to handle pipes and so on are still in the interface logic; only speed maybe could be a problem, if you "talk" with an external reference engine. In modern computers this is not really a problem. In my interface of course I don't count the time needed to validate moves with the reference engine (but it is now embedded, not having the new command in the protocol), so I think that it would not be really a problem at all.

Do to madness to implement any variant, I've choose to not implement any variant at all (just standard chess) in my interface. The simple command "validate" as shown would solve almost any problem (for my interface point of view, of course).

[hgm]

Your code doesn't works for en-passant captures, castling and promotions. Of course you only need to pass back some detail but still the GUI should know the game rules and won't works for any further variant of chess, that does some strange thing while moving pieces.

That is what I said all along: for regular Chess moves there is no problem, and the GUI can handle it trivially without knowing how the piece is allowed to move in general. Promotions are also no problem, because the move will contain a promotion suffix, and you can simply replace the piece by that specified by the suffix. For variants where moves have side effects, like Ultima, these can be specified by the engine with parent variant 'alien', which does exactly what you propose (reply to each move with a FEN to indicate the new game state brought about by the move). That the variant has e.p. capture or somewhat normal castling is no reason to resort to this extreme, however, as these fall in the category 'standard side effects known from orthodox Chess', which are handled by the existing MakeMove code for orthodox Chess.

Note that the "piece" commands are perfectly capable of defining moves with modest side effects for a piece (like capture of a single extra piece not on the to-square, or some forms of non-standard castling, e.g. not with the corner piece or not by the King).

My main point was that the existing WB protocol already contains what you propose, in its own way, and that some current versions of WinBoard already implement it.

The problems to handle pipes and so on are still in the interface logic; only speed maybe could be a problem, if you "talk" with an external reference engine. In modern computers this is not really a problem.

Well, we tried it, and it turned out it was a problem. Operation is not nearly as smooth using the "highlight protocol" (which communicates with the engine) as when using the "piece" commands. There is a perceptible sluggishness in the former case. The point is perhaps that Chess applications ten to exercise the hardware to its limits, so that even powerful hardware has little time left to worry about inter-process communication.

[SuneF]

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.

Well you can't get everything right the first time. Over time requirements change and things must evolve.
What you do is version your protocols and negotiate with the GUI which version should be used, e.g. highest supported version from both.
To claim support of a protocol version, you should however support the complete protocol, not a subset!

[mar]

To claim support of a protocol version, you should however support the complete protocol, not a subset!

Why? I don't have to use all the features of a protocol to be able to claim I support it.
I support xboard and don't offer draws. I don't handle feature rejection and I don't see why I should add code to cover 0% of hypothetical cases where this would happen.
Works fine with winboard/xboard/cutechess.

[SuneF]

Just to be clear, I did not say UCI is better because it's popular (which I think is implied by Bob's analogy). I said the best engines use it, so it must be "OK" (i.e. they must consider it does not weaken their engines).

- Steve

UCI is designed with a different usage in mind. It's a protocol that basically puts the GUI in charge and thus ultimately the user.
It seems to me to be designed for flexibility and analysis in mind.
The GUI play the book moves, the GUI does the learning, the GUI decides when you can ponder and if you got a ponder hit etc... The GUI becomes very much part of the game.

The winboard protocol is designed to allow the engine to be a "chess playing entity" of its own. The engine is in charge of everything, the book, the learning, what to ponder and when to ponder. It's all power to the engine.

The reason we don't agree on which protocol is the best is because we want different things. Many of us oldtimers don't want to just write analysis tools, we want to go all out and create battle bots for chess. An analysis feature is just a nice side affect, it's not the goal.

I don't hate the UCI protocol for what it is, I just think it has a different purpose than the winboard protocol. Sure you can work around the UCI protocol to still do some learning and such, but then you are basically working against the protocol and might as well just use winboard, IMHO.

[SuneF]

To claim support of a protocol version, you should however support the complete protocol, not a subset!

Why? I don't have to use all the features of a protocol to be able to claim I support it.
I support xboard and don't offer draws. I don't handle feature rejection and I don't see why I should add code to cover 0% of hypothetical cases where this would happen.
Works fine with winboard/xboard/cutechess.

A protocol is a contract, an interface between the engine and the outside world.
The bottom line is you don't know how the outside world reacts if you start lying to it.

In the case of draw offers, you can still claim support because the protocol doesn't specify you "have to offer draws" it just says you are "allowed to offer draws" so not offering draws is technically not a violation.

[mar]

The bottom line is you don't know how the outside world reacts if you start lying to it.

Lying?! If a GUI claims to support xboard protocol v2 and rejects setboard or time, then it's broken.
I haven't found such a GUI yet.