Aquarium (other GUIs too?) and WB support => I am shocked

[bob]

Why can't _I_ decide how long to search, when to "deep think", when to "move quickly", decide to not use EGTBs at the root in drawn positions so that my "swindle mode" will work? Etc.

It's not clear to me why you think a UCI engine can't do these things. Nothing in the uci spec prevents any of this, and if a particular GUI usurps your engine's ability to choose how long to think or whether or not to use EGTBs, your complaint should be with the GUI and not with UCI.

You can't ponder when you want. All the UCI GUIs seem to handle books (although you can turn this off) and endgame tables for root positions that are in the tables. They tell you what to ponder, when to ponder, etc...

[bob]

Good point. We UCI programmers are either idiots or insane, no one knows which (maybe some of us are both). Fortunately there are still plenty of Winboard programmers to move the state of the art in computer chess forward.

Well, I would not put it quite in the same words as you or Bob, but it does indeed strike me as odd to prefer the awfully inefficient and verbose UCI prototocol over WinBoard protocol, which is almost trivially to implement in comparison. I cannot see any argument in favor of UCI; there only seem to be downsides to this.

When I started actively developing my chess program I chose UCI because it was very nicely specified. The docs were crystal clear, I had it up and running in no time and it even handles thinking on the opponents time for you. Not that this is a big deal, but it was nice to have the protocol and GUI handle this in such a nice way.

I think I can sum up the differences by just making the observation (which is my opinion) that there seems to be 2 different philosophies with winboard vs UCI.

Winboard seems more like just a simple communication protocol and UCI seems like it was designed to take some burden off the chess programmer by taking over some of the functions you (as a programmer) would normally have to worry about yourself.

I'll give what I think is the primary example. Thinking on the opponents time or pondering. With UCI you don't have to implement pondering, the protocol manages this for you. When the engine makes a move, the GUI will immediately send the engine the position to begin pondering on. If the move is not made, the GUI will stop your engine and restart it with the correct position. UCI (or more properly put the user inteface) handles all the state tracking for you and the engine is relegated to just following simple orders.

Another way to view this is that winboard shifts more responsibility to the engine and UCI shifts more responsibility to the user interface. UCI tracks state for you (from the point of view of the engine author) and winboard doesn't.

Which is better? It's totally a matter of personal preference as far as I'm concerned. I am not a religious zealot on this issue and I believe the top programs would be just as strong had they used winboard instead of UCI. But I do prefer UCI simply because I believe it allows you to focus more on the game playing engine and isolates you from some of the crufty details of the user interface, and I'm an old fashioned programmer who believes that functional parts of systems should be modular and separated. I don't like the idea of a monolithic engine that do it all.

My guess is that over time people will move towards UCI for these same reasons. UCI is more modern in the sense that it simplifies and separates functionality. It makes the chess engine simpler by taking away some of the burden. On the other hand, it could be argued that this is a weakness and that the engine SHOULD be tracking state, fully in control of pondering, etc. I cannot argue with that either, as I say it's a matter or personal preference.

I can tell you one thing however. In the past, before UCI, my program essentially implemented a separate user interface that was compiled into the program. It was relatively simple, but it had to be there. It did what UCI does now so UCI allows me to throw all of that away. If I implement winboard, which I plan to do as an option to Komodo, I will have to essentially build a simple user interface (which would be compiled into the chess program) to get the functionality that winboard does not provide.

None of this is that big a deal and it's not worthy of a religious war but it's how I see it. I respect the arguments of the winboard folks who do not want the GUI to have control of their engines. In my younger days I was more of a control freak that way too and there are good arguments for that.

Anyway, I have not tracked the development of winboard all that well, do I have it wrong? Am I missing something here?

What you described is the very thing I _don't_ like about UCI. Why can't _I_ choose the move to ponder? Or if something unusual happens, why can't _I_ decide to stop and ponder something different? Why can't _I_ decide how long to search, when to "deep think", when to "move quickly", decide to not use EGTBs at the root in drawn positions so that my "swindle mode" will work? Etc.

GUI -> Graphical User Interface. Not "part of chess engine". Yet that is what most UCI interfaces turn into...

I think your characterization is correct and I think we have identified what characteristics makes one choice more appealing for a given person. winboard sees the engine as the complete master and UCI views the interface as grand central station and the engine as a kind of slave device.

I would like to point out however that I can still implement thinking on the opponents time any way I choose as a UCI engine author and it has no impact on the protocol. The engine does not have to send a ponder move to the interface for instance.

I think it's probably the case that EITHER protocol can implement almost anything.

There is one serious shortcoming that winboard does have, unless something has been done to address this - I have not looked at the protocol in a long time. With UCI I can give the user interface a list of things that can be changed in a relatively flexible way, and it looks natural to the end user. And it's still the engines choice about what those things are. For example if my engine has an option to set the contempt factor I can publish that to the user interface. The last time I had a winboard style program I could not set anything directly with the user interface, not even the hash table size. I could do it with command line options and such using scripts with winboard, but I don't think it would be so easy to a naive user.

Has those things been improved upon?

I believe HGM has added some tunable parameters, I have not followed that discussion closely. One significant advantage for winboard is offering and accepting draws... Again, something the engine (in my case) needs to handle because of the way I chose to implement accepting draws (I do a normal search _after_ receiving a draw offer and move, and then use the resulting score to choose whether to play the move returned by my search, or accept the draw.

[Aaron Becker]

You can't ponder when you want. All the UCI GUIs seem to handle books (although you can turn this off) and endgame tables for root positions that are in the tables. They tell you what to ponder, when to ponder, etc...

Again, this is a GUI problem, not an inherent problem with UCI. Don also pointed out that it's entirely possible to use a custom pondering scheme while maintaining UCI compliance. I'm sympathetic to the idea that GUIs shouldn't insist on taking over tasks that engines might want to handle, but that's an argument against overbearing GUIs, not against UCI.

[hgm]

There is one serious shortcoming that winboard does have, unless something has been done to address this - I have not looked at the protocol in a long time. With UCI I can give the user interface a list of things that can be changed in a relatively flexible way, and it looks natural to the end user. And it's still the engines choice about what those things are. For example if my engine has an option to set the contempt factor I can publish that to the user interface. The last time I had a winboard style program I could not set anything directly with the user interface, not even the hash table size. I could do it with command line options and such using scripts with winboard, but I don't think it would be so easy to a naive user.

Has those things been improved upon?

Oh, sure. Engine-defined options are not only supported by the protocol, they are actually implemented in the WinBoard and XBoard GUI. And the hash-table size is set from the general engine-settings menu, through a standard protocol command, just like the EGTB path.

Also in these respects I believe WB protocol to be superior to UCI: in WB protocol, for instance, the number of CPUs an SMP engine can use has a standard command, so it can be centrally set from the GUI. In UCI every engine defines its own command for this, so that the corresponding control would appear in the dialog of engine-defined options, and would have to be set for every engine separately. (Which would be very annoying if you wanted to do a large tuornament.) Of course there are work-arounds for this, (like installing several copies of the same engine, set for using different number of CPUs), but they are not very elegant. Another difference is that WB protocol has provisions to support an arbitrary number of EGT formats, while UCI officially only supports Nalimov. So idf a UCI engine wants to use bitbases, and needs to know where they are installed, it has no choice but to use an engine0defined option for it, with similar disadvantages as with the max-CPU option.


WinBoard dialog for Fruit

(Of course I know that Fruit is a UCI engine, but Fruit+Polyglot is a WinBoard engine, and native WinBoard engines could cause display of exactly that same dialog, just like Polyglot can. In fact Gaviota does, but I did not have the screenshot handy. I post the pictures only to show how the user interface looks, not to illustrate any difference between UCI or WB protocol.)


XBoard engine-option dialog for Glaurung

[Don]

There is one serious shortcoming that winboard does have, unless something has been done to address this - I have not looked at the protocol in a long time. With UCI I can give the user interface a list of things that can be changed in a relatively flexible way, and it looks natural to the end user. And it's still the engines choice about what those things are. For example if my engine has an option to set the contempt factor I can publish that to the user interface. The last time I had a winboard style program I could not set anything directly with the user interface, not even the hash table size. I could do it with command line options and such using scripts with winboard, but I don't think it would be so easy to a naive user.

Has those things been improved upon?

Oh, sure. Engine-defined options are not only supported by the protocol, they are actually implemented in the WinBoard and XBoard GUI. And the hash-table size is set from the general engine-settings menu, through a standard protocol command, just like the EGTB path.

Also in these respects I believe WB protocol to be superior to UCI: in WB protocol, for instance, the number of CPUs an SMP engine can use has a standard command, so it can be centrally set from the GUI. In UCI every engine defines its own command for this, so that the corresponding control would appear in the dialog of engine-defined options, and would have to be set for every engine separately.

So you are arguing that winboard imposes standard command names on the controls. That is a good thing - but I don't think it is very fundamental to determining whether one protocol is superior or not. However I do wish that UCI had standardized a few more of the things that appear in virtually every engine.

(Which would be very annoying if you wanted to do a large tuornament.) Of course there are work-arounds for this, (like installing several copies of the same engine, set for using different number of CPUs), but they are not very elegant.

Another difference is that WB protocol has provisions to support an arbitrary number of EGT formats, while UCI officially only supports Nalimov. So idf a UCI engine wants to use bitbases, and needs to know where they are installed, it has no choice but to use an engine0defined option for it, with similar disadvantages as with the max-CPU option.


WinBoard dialog for Fruit

(Of course I know that Fruit is a UCI engine, but Fruit+Polyglot is a WinBoard engine, and native WinBoard engines could cause display of exactly that same dialog, just like Polyglot can. In fact Gaviota does, but I did not have the screenshot handy. I post the pictures only to show how the user interface looks, not to illustrate any difference between UCI or WB protocol.)


XBoard engine-option dialog for Glaurung

[hgm]

Sure, they are just minor details. The only point I w\ant to make is that they most certainly cannot be used to argue that UCI is superior. To speak in boxing terms: there is no knockout, and WB protocol merely beats UCI on points. But it does so in every round...

[wgarvin]

Yes, I believe in separation of tasks, but the philosophical problem is that UCI separate things that should not be separated.

Yes, I knew this would be argument and it's a fully legitimate concern - it's just one that I do not worry about. I take the point of view that this is largely philosophical. Altogether the user interface, chess engine, book and endgame databases together make up what we are calling a chess playing entity. I personally prefer the model where the user interface is the manager, not the chess program. It just seems a lot cleaner to me.

If you compare Crafty to a typical UCI engine, you get the full picture of the differences. Crafty is a complete chess playing entity on it's own - it does not really need an external user interface except as a convenience.

On the other hand a typical UCI program is not much use without an external and separate user interface. This is by design and is based on the philosophy of not re-inventing the wheel and is very clearly more economical in some sense. As I mentioned, I cannot add winboard to my chess program without first building a user interface and it would have to be more or less a complete chess playing entity.

I would strongly disagree with Don here, and agree with Miguel.

The purpose of a "chess engine" is to play chess. It should be able to play a complete game of chess, including the opening, middlegame, endgames, offering draws, and resigning. If an engine can't even play an opening without relying on a GUI to handle an opening book, I wouldn't even consider it a "chess engine".

Engines also can and should implement other features which players might want to use (such as analysis or undo), and those would then be exposed by the GUI. But all decision making required to play a complete game of chess (including book moves, when to switch out of book or into a tablebase, etc.) belongs in the chess engine, not in the GUI.

The purpose of the "GUI" should only be to let the player interact with the chess engine in a nice way. It can track the progress of the game, help the player enter their moves, help display what the engine is doing -- but the GUI should not be making decisions that affect the game being played. Having the GUI handle opening books is a totally wrong design, IMO.

In fact, I would go so far as to say that the main benefit of separating the chess engine and the GUI into two separate pieces, comes from being able to use several different engines with the same GUI. That way, a good existing GUI can be re-used with any engine, and engine authors do not have to concern themselves much with user interface minutiae.

However, this main benefit is totally defeated if we take decision-making responsibility for certain parts of the game out of the engine, and stick it in the GUI. Which is what SMK did when he wrote the first engines to use the UCI protocol. Note that they were all packaged together with the same proprietary GUI as part of a commercial package; even so I think it was a lazy decision and a bad design. It might have had some benefits for them, but I think it was a disservice to computer chess in general to allow UCI to spread at all.

The Winboard protocol definitely has its own quirks, but at least it gets the correct division of labor between the engine and the GUI!

I wish authors would stop writing their engines for UCI and let it die a much-deserved death. I'm not sure why they keep choosing UCI though. Maybe we need more decent GUIs to be written with full and proper Winboard 2 support, to convince engine authors to use that instead of UCI.

[Don]

Yes, I believe in separation of tasks, but the philosophical problem is that UCI separate things that should not be separated.

Yes, I knew this would be argument and it's a fully legitimate concern - it's just one that I do not worry about. I take the point of view that this is largely philosophical. Altogether the user interface, chess engine, book and endgame databases together make up what we are calling a chess playing entity. I personally prefer the model where the user interface is the manager, not the chess program. It just seems a lot cleaner to me.

If you compare Crafty to a typical UCI engine, you get the full picture of the differences. Crafty is a complete chess playing entity on it's own - it does not really need an external user interface except as a convenience.

On the other hand a typical UCI program is not much use without an external and separate user interface. This is by design and is based on the philosophy of not re-inventing the wheel and is very clearly more economical in some sense. As I mentioned, I cannot add winboard to my chess program without first building a user interface and it would have to be more or less a complete chess playing entity.

I would strongly disagree with Don here, and agree with Miguel.

The purpose of a "chess engine" is to play chess. It should be able to play a complete game of chess, including the opening, middlegame, endgames, offering draws, and resigning.

Because you say so? I think you are merely asserting what your preferences are. I prefer to view a chess engine like an engine in a vehicle - it does not control the entire vehicle, it is merely the part that provides the horsepower to go. And you can take it out and plug a different one in if you want to.

If an engine can't even play an opening without relying on a GUI to handle an opening book, I wouldn't even consider it a "chess engine".

Engines also can and should implement other features which players might want to use (such as analysis or undo), and those would then be exposed by the GUI. But all decision making required to play a complete game of chess (including book moves, when to switch out of book or into a tablebase, etc.) belongs in the chess engine, not in the GUI.

The purpose of the "GUI" should only be to let the player interact with the chess engine in a nice way. It can track the progress of the game, help the player enter their moves, help display what the engine is doing -- but the GUI should not be making decisions that affect the game being played. Having the GUI handle opening books is a totally wrong design, IMO.

In fact, I would go so far as to say that the main benefit of separating the chess engine and the GUI into two separate pieces, comes from being able to use several different engines with the same GUI. That way, a good existing GUI can be re-used with any engine, and engine authors do not have to concern themselves much with user interface minutiae.

However, this main benefit is totally defeated if we take decision-making responsibility for certain parts of the game out of the engine, and stick it in the GUI. Which is what SMK did when he wrote the first engines to use the UCI protocol. Note that they were all packaged together with the same proprietary GUI as part of a commercial package; even so I think it was a lazy decision and a bad design. It might have had some benefits for them, but I think it was a disservice to computer chess in general to allow UCI to spread at all.

The Winboard protocol definitely has its own quirks, but at least it gets the correct division of labor between the engine and the GUI!

I wish authors would stop writing their engines for UCI and let it die a much-deserved death. I'm not sure why they keep choosing UCI though. Maybe we need more decent GUIs to be written with full and proper Winboard 2 support, to convince engine authors to use that instead of UCI.

[hgm]

On the other hand a typical UCI program is not much use without an external and separate user interface. This is by design and is based on the philosophy of not re-inventing the wheel and is very clearly more economical in some sense. As I mentioned, I cannot add winboard to my chess program without first building a user interface and it would have to be more or less a complete chess playing entity.

I don't understand at all what you are referring to by this last sentence. If you want to outsource probing the opening book or end-game tables to the GUI... Then that would be a matter of GUI design, that has absolutely nothing to do with the communication protocol. WinBoard and XBoard do allow engines to use a GUI book. They do not probe EGTs on behalf of the engines, although they easily could, because I don't think it would be worth it: the main importance of EGTs is probing them during the search, which a GUI could never do for you. So engines, whether WB or UCI, need to have interface code to consult the EGT, and when they have it, they can jsut as easily probe it in the root. But again, it is a matter of GUI design if you want that implemented or not.

For me, the main problem of pondering (say 99% of the implementation) has always been the need to know if there is input without blocking if there is none. That is not any different in UCI then it is in WB protocol. Once you can do that, the rest is totally trivial.

I don't see how a UCI interface would be anything less a 'user interface' than a WinBoard interface.

[bob]

You can't ponder when you want. All the UCI GUIs seem to handle books (although you can turn this off) and endgame tables for root positions that are in the tables. They tell you what to ponder, when to ponder, etc...

Again, this is a GUI problem, not an inherent problem with UCI. Don also pointed out that it's entirely possible to use a custom pondering scheme while maintaining UCI compliance. I'm sympathetic to the idea that GUIs shouldn't insist on taking over tasks that engines might want to handle, but that's an argument against overbearing GUIs, not against UCI.

Unless things have changed since I first looked at UCI, the protocol gives precise commands that tell you when you can ponder and when you can not do anything at all. If you can violate that, that doesn't make the protocol better, IMHO, it makes it worse.

For example, check the "ponder" command, which pretty well forces you to ponder that move. Otherwise you can't provide analysis since the GUI will think you are pondering as instructed. Good protocol?

As far as the GUI vs UCI argument goes, it doesn't matter what the UCI protocol says, once all the available GUIs usurp the engine's responsibilities. It does little good, in an argument, to say "UCI doesn't require this" while all existing UCI GUIs do, and the commercial GUIs are the thing that attract most to UCI in the first place...