ChessUSA.com TalkChess.com
Hosted by Your Move Chess & Games
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

What should I support, UCI or Winboard?
Post new topic    TalkChess.com Forum Index -> Computer Chess Club: General Topics Flat
View previous topic :: View next topic  
Author Message
Don Dailey



Joined: 29 Apr 2008
Posts: 4323
PostPost subject: Re: What should I support, UCI or Winboard?    Posted: Mon Apr 23, 2012 7:34 pm Reply to topic Reply with quote
Just a couple of points highlighted below. I don't want to go any farther after this because you get upset quickly when anything other than glowing praise for winboard is discussed but of course you can feel free to respond. I wold like to mention that I don't have any problem with winboard and in fact it has some impressive features that I would probably even give glowing praise too except that you always push back so hard unless it's completely unqualified praise. I just like UCI better and I'm sorry that I cannot say that without upsetting you.

hgm wrote:
Don wrote:
I think this illustrates why no matter what you do, not everyone will be pleased. I am a strong believer that you should not duplicated functionality that can be derived from other functionality unless there is a pretty good reason. So for example "include" or "exclude" in my way of thinking is the same command. I would not wish to require the engine author be required to implement BOTH.


Well, they are not the same functionality, but actually opposite functionality. I guess your thinking is affected by the notion that commands that undo each others effect are not needed, because of the idea of statelessness: there is one single command that resets everything at once, and thus makes the individual resets unnecessary. And then you simply set everything again that was reset as 'collateral damage', feeding the complete state to the engine again by 'unidirectional' commands.

But in practice the collateral damage can be very real, even huge. Resetting the state of the exclude map in UCI can only be done by terminating the seach, because they are both coupled to this same giant 'reset switch'. This could make you lose hours of analysis work, for no reason. It is a bit like having a text editor without backspace command. Because you can get back in the state with the last-typed character deleted by simply clearing the page, and retype all preceding characters. This operation is logically equivalent to pressing backspace, so backspace really 'duplicates functionality'.

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.

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



Requiring the root move set to be sent at the beginning of a search is simply a very bad, counterproductive idea, which in many cases severely decrades performance.


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?

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.

Quote:

In most cases it would be perfectly possible to exclude moves, or re-include them, without disturbing the search in progress. This cannot be written off as a simple preference matter for stateless versus incremental protocols.

But even within the concept of statelessness the UCI 'searchmoves' command is badly designed. Because it requires the engine to receive exactly the opposite info from what the user typically supplies. As the default situation is that an engine searches all legal moves, he will start indicating a number of moves to be excluded from the search. While the engine needs to be sent the moves that should be included. This puts a totally unnecessary burdon on the GUI.

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

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

Quote:


Quote:
I think you tend to see things from the point of view of the GUI designer, so you prefer things that make your life easier just as I prefer to make it as easy as possible for the engine author.


You are aware that I wrote 5 engines, plus the protocol driver for 5 engines from other authors, (SMIRF, ChessV, GNU Shogi, Bonanza, TSIO) and only a small part of a single GUI? Shocked


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

Quote:


Quote:
But this is justified, because one GUI can serve an infinite number of programs. In other words the GUI designer will have to put extra time into it, but it's a positive tradeoff if it saves a million chess authors even a few minutes each. And it makes it much more likely that will be able to produce bug-free implementations which also benefits the GUI designer.

This logic seems severely flawed. A single engine can also run on a million different GUIs, so with this line of reasoning you could also 'prove' the exact opposite.

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.

Quote:


The real trade-off to consider is this one: should we require from everyone that programs an engine for a new game that he would write his own GUI with it from scratch (knowing that this multiplies the amount of work he needs to do by a factor 10 to 100), or would we allow him to connect his engine to an existing GUI, that without any modification then can run his engine 'out of the box'. Because it does not need to know details of the game rules to provide the user with a fully functional interface. The overwhelming majority of games is only supported by a single engine, occasionally by 2 or 3. To have 10 or more engines is a rare exception. You should know this better than anyone! How many C-Chess engines are there, for instance?

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.

Quote:


Quote:
If I design my protocol it will be minimalistic and provide the lowest barrier of entry possible for an engine author.


Well, that seems to describe the actual situation w.r.t. WB protocol pretty well. Frequently new people report here that have written an engine using some custom interface. I advice them to implement the WB "new" & "go" command, (usually their engine already contains that functionality under another name), prefix the move they print with "move ", and 5 min later they are playing automated matches with other WB engines. This is no theory. It has happened many times in the past.

When they later want to have a more complete implementation of WB protocol, they simply grab my 'model WB protocol driver' from WinBoard forum, and they have a fully compliant WB engine. The most common problem that requires them to work on it is that they usually do not support the required time-control types, but think fixed depth. Otherwise it is really nearly a 'zero-effort' job.

_________________
"Your superior intellect is no match for our puny weapons." -Kang and Kodos
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Subject Author Date/Time
What should I support, UCI or Winboard? Asim Pereira Sun Apr 22, 2012 5:28 am
      Re: What should I support, UCI or Winboard? Ted Wong Sun Apr 22, 2012 6:26 am
            Re: What should I support, UCI or Winboard? Asim Pereira Sun Apr 22, 2012 7:39 am
                  Re: What should I support, UCI or Winboard? Ted Wong Sun Apr 22, 2012 9:14 am
                        Re: What should I support, UCI or Winboard? H.G.Muller Sun Apr 22, 2012 9:32 am
      Re: What should I support, UCI or Winboard? H.G.Muller Sun Apr 22, 2012 8:27 am
            Re: What should I support, UCI or Winboard? Aart Bik Tue Apr 24, 2012 9:54 pm
                  Re: What should I support, UCI or Winboard? Daniel Mehrmann Wed Apr 25, 2012 6:17 am
                        Re: What should I support, UCI or Winboard? H.G.Muller Wed Apr 25, 2012 8:55 am
                              Re: What should I support, UCI or Winboard? Daniel Mehrmann Wed Apr 25, 2012 5:57 pm
      Re: What should I support, UCI or Winboard? Matthias Gemuh Sun Apr 22, 2012 3:04 pm
            Re: What should I support, UCI or Winboard? H.G.Muller Sun Apr 22, 2012 6:48 pm
                  Re: What should I support, UCI or Winboard? Matthias Gemuh Sun Apr 22, 2012 8:14 pm
                        Re: What should I support, UCI or Winboard? H.G.Muller Sun Apr 22, 2012 9:10 pm
                              Re: What should I support, UCI or Winboard? Miguel A. Ballicora Sun Apr 22, 2012 9:19 pm
                                    Re: What should I support, UCI or Winboard? Evert Glebbeek Mon Apr 23, 2012 5:25 am
                                          Re: What should I support, UCI or Winboard? H.G.Muller Mon Apr 23, 2012 6:54 am
                                                Re: What should I support, UCI or Winboard? Evert Glebbeek Mon Apr 23, 2012 8:50 am
                              Re: What should I support, UCI or Winboard? Ronald de Man Sun Apr 22, 2012 11:23 pm
                                    Re: What should I support, UCI or Winboard? Carlos Pesce Sun Apr 22, 2012 11:34 pm
                                          Re: What should I support, UCI or Winboard? Christopher Conkie Mon Apr 23, 2012 12:11 am
                                                Re: What should I support, UCI or Winboard? Carlos Pesce Tue Apr 24, 2012 12:12 am
                                                      Re: What should I support, UCI or Winboard? Christopher Conkie Tue Apr 24, 2012 1:18 pm
                                                            Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 1:25 pm
                                                                  Re: What should I support, UCI or Winboard? Christopher Conkie Tue Apr 24, 2012 1:34 pm
                                                                        Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 1:37 pm
                                                                              Re: What should I support, UCI or Winboard? Christopher Conkie Tue Apr 24, 2012 1:45 pm
                                                                                    Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 1:53 pm
                                                                                          Re: What should I support, UCI or Winboard? Christopher Conkie Tue Apr 24, 2012 2:27 pm
      Re: What should I support, UCI or Winboard? Christopher Conkie Sun Apr 22, 2012 10:42 pm
            Re: What should I support, UCI or Winboard? H.G.Muller Mon Apr 23, 2012 8:07 am
                  Re: What should I support, UCI or Winboard? Ted Wong Mon Apr 23, 2012 10:43 am
                        Re: What should I support, UCI or Winboard? H.G.Muller Mon Apr 23, 2012 11:16 am
                              Re: What should I support, UCI or Winboard? Christopher Conkie Tue Apr 24, 2012 1:00 pm
                                    Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 1:04 pm
                                          Re: What should I support, UCI or Winboard? Christopher Conkie Tue Apr 24, 2012 3:09 pm
                                                Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 4:50 pm
                                                      Re: What should I support, UCI or Winboard? Asim Pereira Tue Apr 24, 2012 5:29 pm
                                                            Re: What should I support, UCI or Winboard? Michel Van den Bergh Tue Apr 24, 2012 6:07 pm
                                                            Re: What should I support, UCI or Winboard? Miguel A. Ballicora Tue Apr 24, 2012 6:16 pm
                        Re: What should I support, UCI or Winboard? Evert Glebbeek Mon Apr 23, 2012 11:25 am
                        Re: What should I support, UCI or Winboard? Tony Mokonen Mon Apr 23, 2012 10:00 pm
      Re: What should I support, UCI or Winboard? Don Dailey Mon Apr 23, 2012 1:44 pm
            Re: What should I support, UCI or Winboard? H.G.Muller Mon Apr 23, 2012 2:11 pm
                  Re: What should I support, UCI or Winboard? Don Dailey Mon Apr 23, 2012 2:51 pm
                        Re: What should I support, UCI or Winboard? H.G.Muller Mon Apr 23, 2012 6:01 pm
                              Re: What should I support, UCI or Winboard? Ronald de Man Mon Apr 23, 2012 7:33 pm
                                    Re: What should I support, UCI or Winboard? H.G.Muller Mon Apr 23, 2012 7:49 pm
                                          Re: What should I support, UCI or Winboard? Ronald de Man Mon Apr 23, 2012 9:03 pm
                                                Re: What should I support, UCI or Winboard? H.G.Muller Mon Apr 23, 2012 9:31 pm
                              Re: What should I support, UCI or Winboard? Don Dailey Mon Apr 23, 2012 7:34 pm
                                    Re: What should I support, UCI or Winboard? H.G.Muller Mon Apr 23, 2012 9:15 pm
                                    Re: What should I support, UCI or Winboard? Michel Van den Bergh Tue Apr 24, 2012 6:23 am
                                          Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 8:19 am
                                                Re: What should I support, UCI or Winboard? Evert Glebbeek Tue Apr 24, 2012 8:39 am
      Re: What should I support, UCI or Winboard? Daniel Mehrmann Mon Apr 23, 2012 9:49 pm
            Re: What should I support, UCI or Winboard? H.G.Muller Mon Apr 23, 2012 10:08 pm
                  Re: What should I support, UCI or Winboard? Daniel Mehrmann Mon Apr 23, 2012 10:42 pm
                        Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 5:36 am
                              Re: What should I support, UCI or Winboard? Daniel Mehrmann Tue Apr 24, 2012 6:50 am
                                    Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 7:17 am
                                          Re: What should I support, UCI or Winboard? Daniel Mehrmann Tue Apr 24, 2012 7:42 am
                                                Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 7:49 am
                                                      Re: What should I support, UCI or Winboard? Daniel Mehrmann Tue Apr 24, 2012 8:16 am
                                                            Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 8:35 am
                                                                  Re: What should I support, UCI or Winboard? Daniel Mehrmann Tue Apr 24, 2012 8:50 am
                                                                        Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 9:08 am
                                                                              Re: What should I support, UCI or Winboard? Ed Schroder Tue Apr 24, 2012 10:16 am
                                                                                    Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 11:57 am
                                                                              Re: What should I support, UCI or Winboard? Daniel Mehrmann Tue Apr 24, 2012 7:45 pm
                                                                                    Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 8:06 pm
      Re: What should I support, UCI or Winboard? Jon Dart Tue Apr 24, 2012 1:45 am
            Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 5:44 am
                  Re: What should I support, UCI or Winboard? Jon Dart Tue Apr 24, 2012 11:15 am
                        Re: What should I support, UCI or Winboard? H.G.Muller Tue Apr 24, 2012 12:32 pm
      Winboard ftw Daniel Shawul Wed Apr 25, 2012 2:10 pm
            Re: Winboard ftw H.G.Muller Wed Apr 25, 2012 2:45 pm
                  Re: Winboard ftw Daniel Shawul Wed Apr 25, 2012 3:21 pm
Post new topic    TalkChess.com Forum Index -> Computer Chess Club: General Topics

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum




Powered by phpBB © 2001, 2005 phpBB Group
Enhanced with Moby Threads