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

[Don]

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

The state of the art with linux UCI GUI's is not very impressive. There is Jose, which is a bit buggy but somewhat workable. There is Knights, which I have not seen work well with the gnome desktop and I do not know how well it works with KDE.

I will probably be producing a simple TK based GUI for linux but it won't be nearly so full featured as Arena but I hope it to be clean and simple and have adequate functionality.

Other than that, xboard is workable with polyglot, but HGM has versions that do not require polyglot.

Still, there is seems to be nothing that really feels exceptional to me. I am almost to the point where I am even willing to build a full featured cross platform GUI.

[hgm]

Well, XBoard will get there, eventually. There is still a lot of work to be done to close the gap with WinBoard, though, especially on the front-end (menu dialogs), and we put sort of a freeze on that until the gtk+ version is out.

Note that XBoard always needs Polyglot. In the latest versions the user is no longer aware of it, though. It only exists there as part of the back-end, completely invisible to a user that only wants to do standard things (like running and configuring UCI engines)..

[Kurt Utzinger]

Nobody in their right mind will develop UCI programs. The winboard protocol is certainly "old fashioned" since it has been around for 20 years. It is _still_ superior to UCI, however.

Do you indeed believe that Winboard is superior to UCI? If so, I am wondering why almost 100 % of new engines are UCI and not Winboard.
Kurt

[Don]

Nobody in their right mind will develop UCI programs. The winboard protocol is certainly "old fashioned" since it has been around for 20 years. It is _still_ superior to UCI, however.

Do you indeed believe that Winboard is superior to UCI? If so, I am wondering why almost 100 % of new engines are UCI and not Winboard.
Kurt

I'm not sure anyones opinions on these things are very objective. I have hear very little actual evidence to support a claim that either one is clearly superior to the other.

I'll give one example. Someone earlier said something about all the extra state being passed by UCI, but I saw no analysis that shows or proves there is anything wrong with doing this.

I think it comes down to personal preference as both protocols seem to do the job pretty well.

[Roger Brown]

Do you indeed believe that Winboard is superior to UCI? If so, I am wondering why almost 100 % of new engines are UCI and not Winboard.
Kurt

Hello Kurt,

This is a bit lazy of you. I did some casual research for the engines introduced in 2009 according to Guenther Simon's excellent RWBC site (well worth the visit) and these are the statistics I have from the anthology section:

Total new engines for 2009 = 44

UCI only = 18

WB only = 24

WB/UCI = 2


It seems that pattern will hold when 2010 is all counted and accounted for. That is what I see happening when I look at WBEC's newspage - the place for breaking news with respect to new engines appearing on the scene.

Those numbers above hardly support your view about the near extinction of the engines which support the Winboard protocol exclusively. In fact it appears that announcements about the death of the Winboard protocol are (once again) premature.

However I suppose that when one approaches factual matters with a bias it tends to eliminate the need to do any supporting research.

Personally, I have no axe to grind either way, the stuff is free and I can use them all in Winboard as transparently as in any other gui thanks to the exciting progress that has been taking place in Winboard's and Polyglot's development.

I just thought I would confuse the issue with some facts....



Later.

[bob]

Nobody in their right mind will develop UCI programs. The winboard protocol is certainly "old fashioned" since it has been around for 20 years. It is _still_ superior to UCI, however.

Do you indeed believe that Winboard is superior to UCI? If so, I am wondering why almost 100 % of new engines are UCI and not Winboard.
Kurt

I have not noticed this being true. The WB protocol lets the engine play the game. UCI usurps too much control and gives the GUI too much control. It really is that simple.

[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...

[Aaron Becker]

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.

[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?

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?

[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.

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?

Absolutely.

Xboard in Linux:
http://sites.google.com/site/gaviotache ... figuration

In Winboard it looks even nicer (this is independent of the protocol, of course).

Miguel