What should I support, UCI or Winboard?

[hgm]

I disagree completely. What the editor does internally is a hidden implementation detail than need not concern the person doing the editing. As long as the user can press backspace and get expected behavior that is what matters.

You discard work done by the computer like it is free, so that internally only elegance counts, and not performance. But that is a mistake. Chess computations are far from free. People spend many CPU days on it. And in an editor it is already annoying when you would have to wait 0.5 sec to see the effect of a backspace be displayed after you type one. (Try to edit backend.c from the XBoard sources with MS NotePad, and try to add or delete a line, and you will see what I mean...)

So when it comes to "exclude" and "include" the user interface SHOULD provide both. Basic software engineering principles tell us that we should not duplicate functionality, we provide the tools to do whatever we need to by construction and no more, at least within reason. I do violate that principle some in Komodo for reasons of performance, but as I will comment later that is not an issue here.

I think I showed in the previous post it is a huge issue. When someone uses Komodo for interactive analysis, and after 30 min of analysis on a crucial position decides he wants to exclude all 'tail moves' in the next hour of analysis on that same position (keeping only the two moves that on previous iterations alternated as best). How do you implement that in Komodo? Would the user lose the 30 min of previous analysis, or would the search just continue uninterrupted. If the latter is the case, how did you implement that? And is that really simpler for the engine than the implementation in WB protocol, where you just would let the input thread toggle the 'exclude flag' for each of the tail moves?

Again, I don't see why you even mention that. Why would any protocol need to require the root moves to be sent when they can generate them on their own?

Because this is what the UCI searchmoves command requires. The engine cannot generate the searchmoves on its own. It has absolutely no way of knowing which moves the user wants searched.

But even if the root move list WAS sent it would not be a performance issue. I don't see why everyone obsesses over the amount of data being sent over a pipe in a chess program. It's just not a big deal. As I have mentioned before I can play several COMPLETE games per second even on 1 core with UCI sending complete moves lists, PV's going back and forth, current move numbers and all sorts of other crap. The issue is only in the GUI when you try to put all that information on the display using graphics calls and such and that has nothing to do with the protocol. With a graphical user interface I doubt I could play more than 1 game every 5 or 10 seconds even if both programs were playing instantly. That's where the overhead and drain is.

Just for fun I took a file that is 8.5 MB and piped it through a utility to count the number of characters in the file. A pipe is the same thing that happens when a chess program is connected to a user interface. It took about 0.2 of a second to send 8.5 MB and the data had to first be read from disk which is ridiculously expensive compared to just spitting out data already available to a chess program. And then it had to also be processed and counted and a program loaded up to do that! But 8.5 MB is orders of magnitude more data than a chess program will send even for the entire game. That would be the overhead of several games. This obsession with "too much data" has no place in this discussion.

I think we are talking completely past each other. The issue is NOT communication. The issue is CPU time spent on search, that by (UCI) design must be lost in order to change the list of excluded moves.

There is no appreciable burden except perhaps in the programming of the GUI, but as stated I very strongly believe that is where the work should be focused.

Well, apart from the fact that we do not agree on that, it would still not be an argument for heaping as much extra, completely unnecessary work on the GUI author as possible.

I don't believe the engine author should writing low level crufty code designed to accommodate things the GUI could be doing. Like mentioned above, the idea of sending a move list to the GUI, we both agree that is complete nonsense because the GUI can do that.

Well, it was NOT mentioned above, but now that you mention it, I don't agree that it is complete nonsense. It would make the GUI unsuitable for use with any variant except the finite number it happens to know the rule of. Rather than being able to handle the infinite number of variants it could handle otherwise. So it really gets infinitely better by what you call 'nonsense'... On top of that, by its very nature an engine will always have a move list, and the move list will be of interest to the average user at a time when iterations get so slow that he is wondering where in the move list the engine is currently working. So all that 'crufty code' is a necessary part of the engine anyway, and putting that code to work in a GUI-friendly manner is basically zero effort on the part of the engine author.

There was an issue that came up with GTP protocol for computer go which is eerily similar to the backspace editor example you mentioned. The protocol calls for an undo command. But it was possible for a GUI to simulate the same functionality without the undo command, simply by resetting the engine to the start position and forcing the moves.

This is actually how all my engines implement the WB 'undo' command! Even the matchbox did it that way!

I was a reasonable decision to support and explicit undo command in my opinion but not strictly necessary. I don't believe we have to be completely unreasonable about things like that when there is an obvious shortcut, but imagine the same protocol needing to have a way to say, "take back 2 moves to get to the same side's turn" and then adding even more variations of the undo command. And the go engine author having to support every one of them. It would just be silly.

Well, 'undo N' would not be anymore difficult to implement for variable N than for fixed N=1. I agree that WB protocol is rather in-elegant in this respect.

Of course I am, but your heart and soul is in the GUI and that is where your primary focus is.

That could be true, but that doesn't mean I have a closed eye for the interest of engine developers. I see the GUI as a tool. I want it to be a great tool, but the quality of a tool is determined for a large part by how easy it is to use it.

It is just that I cater to a difference audience than you want me to cater to. I don't give a hoot how easy it is for people to write Chess engines. The world is already flooded with Chess engines to the point that we are nearly suffocated by them. And if there are people that want to make even more... They can use any of a dozen or so different GUIs made espeially for the purpose, and capable of doing little else. (ChessGUI is a notable exception!)

So what I am interested in is how life can be made as easy as possible for people that want to write unique engines, for games that no other engine played before. Such as Burmese Chess, Chieftain Chess, Grasshopper Chess, Twilight Chess, Camaratti Chess...

Well that is just plain ridiculous. There are hundreds of engines that can run with xboard and UCI, there are probably 4 or 5 GUI's that comprise probably 99% of all GUI use. So to optimize man-hours of effort you optimize the protocol for the engine author, not the GUI author. I hope you are not saying that hundreds of engine authors should work extra hard to make it easy for those 4 or 5 GUI programmers.

Well, it also does not mean that engine authors should go out of their way in disrecarding protocol specs and recommendation just to make life impossible for GUI programmers. That there are already far too many engines, and very few GUIs could be seen as a very good reason to make life easier for GUI developers, to stimulate more people to develop a GUI.

I am only talking about western chess, not a million variants and the context of the discussion concerns the 2 major protocols in common use.

I agree things change when you are building a GUI to support any number of unknown new games that may come along. Then it's reasonable that the authors of these games and engines should have to work harder to build a product with a compatible interface, like you and I are doing together with camchess and schess.

Well, that explains most of why we see things differently. The only reason I work on WinBoard at all is because I need a variant-capable GUI. That the requirements for a good variant GUI are largely coinciding with those for a Chess GUI is just the good luck of those wanting to use WinBoard for Chess.

We are indeed drifting a bit away from the original topic, whether it would be better to implement WB protocol or UCI in a GUI. But all I said about that was that if you implement WB protocol, or even just a modern subset of it, you get UCI with it for free, because of Polyglot. And I am not so sure the opposite would be true. So I think that really says it all.

[hgm]

Do you want to communicate, or are you just here to show that you're smarter than everyone else? Because really, I have better things to do than play word games with someone who does not want to listen.

Communication is difficult with those that do not recognize the validity of ordinary logic, but dismiss it as 'word games'...

Yes I know that I should give up on xboard, or rather, that a fork is in order.

Do you even know what XBoard is? The fact that you say this, makes one suspect not. If you would have any real issue with XBoard, rather than just imagined ones, and it would likely be fixed before you even could say 'fork'. But, by all means, fork as you please. I am very curious as to what you would feel the need to 'improve'. (And if it was any good, we would copy it into the main line, of course... So let's hope these was not idle bluff.)

[Daniel Mehrmann]

Well, you should look around which protocol is mainly used by top engines, because the people like, or better say prefer, to play and analyze with the strongest one. So, my prediction and suggestion is UCI.

@all: Stay away from a protocol war. It doesn't matter which protocol is better.

[tmokonen]

Well if Winboard protocol is really better than UCI, why wouldn't the top and new engines use it? Its not as common as UCI, there must be a reason. Can you explain?

Many top engines are also commercial engines, and the most popular commercial GUIs (Fritz, Chessbase, Aquarium) only support native Chessbase format or UCI, or in the case of Aquarium provide only incomplete support of Winboard.

In other words, it's mostly about reaching the largest possible audience, especially if one has commercial aspirations.

[hgm]

@all: Stay away from a protocol war. It doesn't matter which protocol is better.

It is not at all my intention to claim that any of the two is better. What I said is that I suspected UCI2WB adapters (and in particular Polyglot) give more complete support of UCI than available WB2UCI adapters would give of WB protocol. That in itself would be an argument for implementing WB protocol natively.

Note further that the philosophy of UCI is to dump workload onto the GUI (in this case Polyglot), while WB protocol tends to dump it on the engine (in this case Polyglot). So by using Polyglot, you have the best of both worlds!

[Daniel Mehrmann]

Note further that the philosophy of UCI is to dump workload onto the GUI (in this case Polyglot), while WB protocol tends to dump it on the engine (in this case Polyglot). So by using Polyglot, you have the best of both worlds!

Well, it doesn't count, because we're talking about the android plattform and not a x86 computer. So, basicly the environment is completly different and you can't compare them.

Just for example, we're talking about a Java UI which runs in a special VM - Called Dalvik. There are importent system states, which only send to the App (in our case the chess GUI). So, basicly we need a protocol where the UI is the master.
Even if wb could handle this, you planing to run a C based adapter on a Java environment ? Well, you could do a Java rewrite of course or support both protocols on your own way (like a Java adapter/controller).

Well, it's all a question of time and how many hours do you wanna spent on interface stuff. If we're looking deeper and using modern design pattern, classical view - model - controller, it makes no sense to write the same stuff two times (based on your adapter idea).

[Elorejano]

Please, implement both.
WB protocoll is more better, but UCI are implemented in ChessBase gui, seems that this are the important for much people here.

Smart comment. We cannot be sure. Both do the same thing......in different ways and to different degrees.

No. dont do the same. An engine of UCI its not a complete engine. Its gui dependant.
Under winboard you have ALL with o without a gui..i imagine that a programer dont want to develop an engine "under the orders" of a "board"

[jdart]

IMO UCI is simpler to implement. Winboard can be tricky, especially when pondering is supported. But there are also some ambiguities in UCI and differences across interfaces in how they handle it.

I don't like UCI because it gives minimal information to the engine and assumes the GUI does a lot of functions the engine might want to do. But it is widely used, so I support it.

--Jon

[hgm]

Just for example, we're talking about a Java UI which runs in a special VM - Called Dalvik. There are importent system states, which only send to the App (in our case the chess GUI). So, basicly we need a protocol where the UI is the master.
Even if wb could handle this, you planing to run a C based adapter on a Java environment ? Well, you could do a Java rewrite of course or support both protocols on your own way (like a Java adapter/controller).

Of course no Java rewrite is needed. The adapter runs as an independent process,like the engine. In fact, seen from the GUI, an adapter is the engine. Are you claiming that all engines would hav to be re-written in Java before they can be used on Android? If so, the whole idea of having a GUI there seems dead from the beginning.

As I understood it, Android is based on a regular Linux kernel, able to run normal Linux executables, and it doesn't matter which compiler or assembler generated such executables: they all look the same. The Dalvik stuff is only important when you want to interact with the UI, which adapters and engines don't.

[hgm]

IMO UCI is simpler to implement. Winboard can be tricky, especially when pondering is supported.

I would say pondering is completely trivial in WB protocol. You just send 'easy' or 'hard' at the beginning of the game, and that's it. In UCI you will have to get the ponder move, send it back, remember it for later comparison with the actual move, explicitly stop the search if it was a ponder miss, possibly delay all subsequent comands until you get confirmation because some UCI engines croak if the get commands during this time interval. You would have to do that every move, as well as worry about setting a global 'Ponder' option. Doesn't sound simple to me at all...