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

[Don]

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

I think there is a knockout punch - at least for me.

The knockout punch for me is that with UCI you can focus on the chess playing aspects of the engine and not have to deal with the user interface with all it's gory details. I am happy to let user interface authors handle that part.

I did start to implement winboard as I believe it's always good to let users have options - but I quickly learned why the 2 protocols are different. winboard would have required me to build a user interface into komodo first because winboard assumes that your engine is tracking all state and control flow.

An older program of mine did that and it was conceptually a lot like komodo, it had a separate user interface (which was compiled into the program) and a separate engine that did not know or care about state. The only real difference between komodo and that older program is that now I dont' need to have a user interface compiled into the program - I just have a very simple stateless program. I think this is the HUGE point that nobody ever talks about and for some reason is never stated in arguments for or against one protocol over the other. To me that IS the knockout punch. With UCI the chess engine programmers job is very simple and the code is very clean - if you are willing to let the user interface make the unimportant decisions.

The argument always comes up that with UCI the engine cannot resign on it's own. I do not understand why this is considered so important. Does anyone honestly believe this is something worth losing any sleep over? You can set most any user interface to resign when the score is below some value for some specified number of moves consecutively and I can assure you that I'm not going to spend any time trying to improve on this - you can do this if you want to, but while you do I'll spend my time on the search or the evaluation - things that are more important that this by orders of magnitude. Or I'll just set the program not to resign which is actually a surprisingly good heuristic.

To me these unimportant and trivial details are ones that I am not very interested in - I would rather be actually improving the program. Even my king and pawn database (which is compiled into the program) contributes less than 1 or 2 ELO and I would put that at least 2 orders of magnitude more important than when to resign or offer a draw.

So all this nonsense about having a complete chess playing program is very "anal retentive" from my point of view. If you worry about things like this, then stuff like GHI (Graph History Interaction) is far more worthy of obsessing over and must give people nightmares. Computer chess is a very messy business and I doubt anyone can demonstrate any real advantage of one over the other other than ease of programming (which for me is the knockout punch and why I believe authors will continue to migrate towards UCI.)

I know you are heavily vested in winboard as you have done much good work with winboard and xboard. I don't have any issues against it and it has indeed over the years been a very valuable contribution to computer chess and I consider xboard a good tool that I use myself.

When I hear comments that are too slanted in one direction or the other I will probably say something. I think it's equally unfair to be overly critical of winboard (which is a perfectly usable protocol) and get real religious over either one.

[Don]

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.

[Don]

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.

The primary (and to me the only fundamental) difference in the two is that UCI is stateless from the chess programs point of view. I have built a lot of chess programs that were standalone and I never found pondering and the control flow totally trivial - they were boring details that took a significant amount of time to implement and always had bugs till I ironed them out.

With UCI this is no longer an issue and this part just goes away. My control logic in Komodo is trivially simple, it's just a big switch statement that accepts commands and blindly follows them. I don't care who's turn to move it is, whether I need to retract a move due to pondering, etc. The UCI user interface has all of this logic built into it and tracks this instead. Without UCI, I would essentially just have to build the same functionality into the program - which is what winboard programs must do.

I never said anything about outsourcing the books or endgame databases and I don't understand any of the arguments on either side of this. Isn't it the case that any chess program can have it's own opening book or it's own endgame database, regardless of whether it is UCI or Winboard?

I have a feeling that most people who have an axe to grind against one protocol or the other have not taken the time to understand the other protocol. For example I have not kept up with winboard improvements and I did not know that winboard engines can give the interface a list of options that are supported.

A lot has been made of how much control of things the interface has versus the engine and some of this I started. But the fact of the matter is that in every important detail neither protocol robs you of control over these things. As I argue in my last post (between your post and my response to this post) what little difference there has no impact on the strength of the engines being served.

[hgm]

The knockout punch for me is that with UCI you can focus on the chess playing aspects of the engine and not have to deal with the user interface with all it's gory details. I am happy to let user interface authors handle that part.

That is really weird, as for me that is exactly the same: I want to focus on the Chess playing, and spend as little effort as possible on the interface. So it was immediately obvious that I would have to use WinBoard protocol.

I admit I never understood this business about "stateless". It seems to me you cannot play Chess without knowing the game state, and that UCI uses exctly the same commands (namely moves) to advance the game state as WB protocol does.

But in the end, for me it is the amount of code I would have to write that counts. And for WinBoard that is just a small fraction of what I would need for UCI. The main loop of my program is not a switch, (as oncannot switch on string varables, but a small sequence of if(!strcmp(command, "...."), which IMO is pretty much equivalent.

[Don]

The knockout punch for me is that with UCI you can focus on the chess playing aspects of the engine and not have to deal with the user interface with all it's gory details. I am happy to let user interface authors handle that part.

That is really weird, as for me that is exactly the same: I want to focus on the Chess playing, and spend as little effort as possible on the interface. So it was immediately obvious that I would have to use WinBoard protocol.

I admit I never understood this business about "stateless". It seems to me you cannot play Chess without knowing the game state, and that UCI uses exctly the same commands (namely moves) to advance the game state as WB protocol does.

But in the end, for me it is the amount of code I would have to write that counts. And for WinBoard that is just a small fraction of what I would need for UCI.

I would prefer that there were only a single well accepted protocol and I would use it. But unfortunately there are two.

At some point I will implement winboard so that my engine works with both as a convenience to the end users.

It would work like a built in adapter and I would not touch any of the existing engine code. So internally the engine would remain UCI but the input and output would be translated from and to winboard.

In other words, I would be building the equivalent of polyglot into the program!