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

[hgm]

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.

[Aaron Becker]

I don't have anything against Winboard; it seems to be a fine protocol now that I've gotten to know it. To explain why I chose UCI for my own engine: when I was brand new to all this, I looked at the best description I could find for each protocol: Winboard and UCI. Just browsing through these (remember, right now I just want to get going with my engine as quickly as possible), UCI looks simple and well-specified compared to Winboard, which is why I chose it. As for inefficiency and verbosity, I had a very easy time implementing my UCI parser, and my engine spends an absolutely trivial amount of time in its protocol code, so I can't say it bothers me one iota.

[hgm]

I guess the lesson is that the document describing the protocol definition is poor, and needs to be re-written... A staged introduction of the commands (basic / common / advanced) could help a lot to avoid the false impression that WB protocol is anything but trivial, but yet more powerful than UCI, and the obvious choice for any new engine.

It did seem to bother you that there is no formalized way for UCI engines to kibitz, while it would bother me that there is no way for them to offer or accept draws.

[michiguel]

I guess the lesson is that the document describing the protocol definition is poor, and needs to be re-written...

Absolutely!
For WB/XB, backward compatibility is important, but it the main document does not have to be. In other words, any reference to gnuchess and obsolete behaviors or commands should go to an appendix.

Miguel

A staged introduction of the commands (basic / common / advanced) could help a lot to avoid the false impression that WB protocol is anything but trivial, but yet more powerful than UCI, and the obvious choice for any new engine.

It did seem to bother you that there is no formalized way for UCI engines to kibitz, while it would bother me that there is no way for them to offer or accept draws.

[Aaron Becker]

It did seem to bother you that there is no formalized way for UCI engines to kibitz, while it would bother me that there is no way for them to offer or accept draws.

Yes, I think these are both annoying deficiencies of UCI. Some of the commands are also uglier than I think they need to be. It does have some good points as well, though. The biggest for me is support for very fast time controls. I lean very heavily on games played at 1s+0.1s for testing, which as far as I know isn't possible under Winboard. I also prefer UCI's ponder implementation to Winboard's, although I gather that this is something of a contentious issue. Fortunately Polyglot which mitigates a lot of these incompatibility issues.

[Don]

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?

[michiguel]

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.

Yes, I believe in separation of tasks, but the philosophical problem is that UCI separate things that should not be separated. If we assume that the engine is the "brain" of the chess entity, it should be making the decisions that concerns to the game. Offering/accepting draws, learning, playing moves in the opening and the endgame, etc. are all chess decisions. The interface is not "just" an interface anymore. For a user, this is really no big deal, but if you have your engine and you want to have some control over these tasks, UCI is not the answer. IMHO, the whole design of UCI is flawed.

So, if I want to summarize it, UCI is for chess analysis, but Winboard is more suitable for competition and development. WB2 is particularly well suited for growing.

I observed that UCI is nicely specified too, but the implementation makes me wonder. You cannot make parameter options with spaces in it?

My guess is that over time people will move towards UCI for these same reasons.

Particulary if commercial GUIs sabotage or do not know how to implement winboard.

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?

The last few things that you could do with UCI and you cannot with WB have been covered.

Miguel

[Aaron Becker]

I observed that UCI is nicely specified too, but the implementation makes me wonder. You cannot make parameter options with spaces in it?

Option names in UCI can definitely have spaces. Even some of the example option names in the protocol document, like "Clear Hash", have spaces. I'm not sure why option names like NalimovPath have the spaces squeezed out (or why the UCI_* options have underscores instead of spaces); I find it sort of annoying.

[Don]

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.

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.

So you have this curious situation where you can only use a winboard based user interface if your program already has a complete working user interface!

Like I say, there is nothing wrong with that, everything works just fine in either case but it's a matter of personal taste and I suspect in most cases there is a bias in favor of one or the other based less on logic than on personal preference or habit. You can generally be sure that if someone has done it a certain way for a long time, their brains are going to view any other way of doing things as broken. However I've done it both ways and do not see any clear superiority of one over the other - I choose UCI because it's a much simpler protocol and saves you a lot of work.

If we assume that the engine is the "brain" of the chess entity, it should be making the decisions that concerns to the game. Offering/accepting draws, learning, playing moves in the opening and the endgame, etc. are all chess decisions. The interface is not "just" an interface anymore. For a user, this is really no big deal, but if you have your engine and you want to have some control over these tasks, UCI is not the answer. IMHO, the whole design of UCI is flawed.

So, if I want to summarize it, UCI is for chess analysis, but Winboard is more suitable for competition and development. WB2 is particularly well suited for growing.

Your arguments in favor of winboard are perfectly valid. If you need to control all aspects then winboard is a good choice - I am not someone who believes winboard is broken or bad or wrong or anything like that, it's just a different protocol. From my point of view as the author of a very strong engine, I am happy to let the user interface decide that king vs king is a draw. I trust that any good interface is configurable anyway, and will get all these annoying and trivial details correct and I don't want to have to worry about that.

I agree with you that winboard does give the engine more of an opportunity to micro-manage the whole process, but see hardly any value in that. I can think of a million ways to improve my program other than constructing an algorithm that decides when to accept a draw offer from a weaker or stronger opponent based on his rating and how much time he has left on his clock. Even so, this (in my view) should be a user configurable option that is relegated to the user interface. (Doesn't winboard make decision on when to end the game early based on user interface configuration options? I think that shows that in principle it's understood that this is really a user decision.)

I observed that UCI is nicely specified too, but the implementation makes me wonder. You cannot make parameter options with spaces in it?

Of course you can. I can make options like "bishop pair endgame" and UCI does not delimit options with spaces but with keywords.

My guess is that over time people will move towards UCI for these same reasons.

Particulary if commercial GUIs sabotage or do not know how to implement winboard.

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?

The last few things that you could do with UCI and you cannot with WB have been covered.

Miguel

[frankp]

I started out before uci so use xboard.
Are there any linux uci gui, or is polyglot the answer.