What's the role of the GUI?
Moderators: hgm, Rebel, chrisw
Re: What's the role of the GUI?
I think the problem is that your GUI plays chess for him, even if his engine doesn't know how to move. At least in the opening and the endgame.
-
- Posts: 1808
- Joined: Wed Mar 08, 2006 9:19 pm
- Location: Oslo, Norway
Re: What's the role of the GUI?
I'm not sure it's only that. Even if I were sufficiently masochistic to write my interface in plain C, I would prefer to let my engine do nothing more than computing the moves. It's just a far cleaner design, IMHO. I want to keep my engine code as simple and uncluttered as possible (although pressure from users has unfortunately forced me to pollute it with a few things like book code and a benchmark function).Zach Wegner wrote:I know what you are saying. Maybe it is because you are a high-level language guy, and I'm a low level language guy.
So do I, and I have just as much control over it when I do it from the GUI. In a certain sense, I have even more control, because both the development time and the risk of bugs are an order of magnitude smaller.Really, I just like having as much control as possible over the strength of my engine, whether it's a good thing or not. I like to have my own book formats, book-move selection algorithms, resigning, drawing, etc.
So would I, but again, driving it from the GUI would work just as well.I also would like to someday implement a specialized pondering algorithm and a "swindle mode".
I do that, to -- more specifically from the Lisp prompt, with various functions for interacting with the engine and instructing it to do different tasks. The main difference compared to interacting directly with the engine is that instead of just having access to the few lame commands I have implemented in the engine, I have access to a full, powerful interactive programming language, extended with functions for running matches, tournaments and test suites, for pretty-printing PVs, for reading and writing PGN games, for opening a window with a graphical chess board, and so on.Keeping track of clocks and loading PGNs, that's something else. I have those implemented in my engine firstly as a programming exercise--it's fun--and because I normally use my engine (when not running tournaments) on the command line.
Neither do I, but it doesn't.I don't like my engine to require a GUI to play with.
Tord
-
- Posts: 1808
- Joined: Wed Mar 08, 2006 9:19 pm
- Location: Oslo, Norway
Re: What's the role of the GUI?
I still don't get it. Obviously, using somebody else's GUI forces you to live with the limitations and design decisions in that GUI, but nobody forces you to use that particular GUI. It's entirely your choice.Guetti wrote:I think the problem is that your GUI plays chess for him, even if his engine doesn't know how to move.
Tord
-
- Posts: 388
- Joined: Wed Mar 08, 2006 10:08 pm
Re: What's the role of the GUI?
I have a version of Thinker that ponders on multiple moves simultaneously (in parallel). How do you handle that in UCI? You can't. UCI tells you to ponder on only one move. That's how busted that protocol is. For me, pondering is the job of the engine. It should be free to decide on how best it could be done.Tord Romstad wrote:I have never understood this opinion, which seems to be very commonly held. Because my engine is written in a low-level language, I prefer to let it handle only the task of computing moves, and do everything else (keeping track of the clocks and the game state, looking up book moves, resign, offer or announce draws, loading and saving games, etc.) in the GUI, where I can use some higher-level language. Why should I handle this kind of tasks in the engine? It would cost me a lot in terms of time and frustration, and I don't see what benefits it would offer to the users.Zach Wegner wrote:No! I hate GUIs that resign, use opening books, tablebases, etc. That is the engine's job...Uri wrote:What's the rule of the GUI? Does the GUI improve the program's playing strength?
Tord
Thinker also performs a shallow search on every candidate book move, to verify that they are reasonable. Can any UI do that for me? Even if it can, would its search be better than mine? If that UI can actually search better than mine, then why even bother calling my engine? That UI should just do all the search. Again, for me, picking the move is the job of the engine, from the first move of the game, to the last.
Resign? Why would I let others (the UI, that is), resign for my engine? If my opponent is out of time, the engine could play on and perhaps win. People do that, why can't the engine?
The same goes for time management. If my engine decides to use-up 90% of the clock on the first move, then so be it. I've seen humans do that.
But, that's just me. To each, his own.
Cheers!
-
- Posts: 1808
- Joined: Wed Mar 08, 2006 9:19 pm
- Location: Oslo, Norway
Re: What's the role of the GUI?
It does, but the protocol explicitly states that the ponder move is just advice to the engine, and that the engine is free to ignore it and spend the time doing whatever else it wants to do.CThinker wrote:I have a version of Thinker that ponders on multiple moves simultaneously (in parallel). How do you handle that in UCI? You can't. UCI tells you to ponder on only one move.
In any case, I don't see what you are arguing against. I didn't say that UCI was perfect; in fact I didn't mention UCI at all. I just said that I don't see why it matters how the tasks my chess program do are divided between the engine and the UI parts.
And it is, regardless of whether you are using the UCI or the xboard protocol. But again, this is not a discussion of the relative merits of the UCI and xboard protocols.That's how busted that protocol is. For me, pondering is the job of the engine. It should be free to decide on how best it could be done.
Simple: If you think some part is better or more easily done in the engine, do it there. If you think some part is better or more easily done in the UI, do it there. I don't do a shallow search of candidate book moves, like you do, but if I wanted to do it, I would let the UI tell the engine "these are your book moves, please check which among them are reasonable". After all, my UI instructs the engine to search in the first place, just supplying a (possibly empty) list of candidate book moves in addition to the position to search would be trivial.Thinker also performs a shallow search on every candidate book move, to verify that they are reasonable. Can any UI do that for me? Even if it can, would its search be better than mine? If that UI can actually search better than mine, then why even bother calling my engine?
Why does it matter? It is likely that no user would even notice what is done by the engine and what is done by the UI.That UI should just do all the search. Again, for me, picking the move is the job of the engine, from the first move of the game, to the last.
In what sense is the UI "others"? I am not playing, my chess program, which consists of an engine and an UI part. They are both essential. You could just as well ask: "Why would I let others (the engine, that is) do the work of searching for my UI?"Resign? Why would I let others (the UI, that is), resign for my engine?
Why can't the GUI?If my opponent is out of time, the engine could play on and perhaps win. People do that, why can't the engine?
Again, I don't understand how this relates to anything in the discussion. In my program, the engine is told how much time it has left, and can choose to use it however it likes.The same goes for time management. If my engine decides to use-up 90% of the clock on the first move, then so be it. I've seen humans do that.
Tord
-
- Posts: 27894
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: What's the role of the GUI?
If a hypothetical engine autor is happy with the way Fruit does its search, and just plugs in his own evaluation, to save him some work, would that be a problem?Tord Romstad wrote:I still don't see the problem. If the hypothetical other engine author is happy with the way my GUI does this, he can use it as it is, and save himself some work. If he is not happy about it, he'll just use some other GUI, or make his own. Where's the problem?
GUIs that involve themselves in the decision of move selection are not GUIs. They are front-ends of engines.
UCI is not an engine-GUI communication protocol. It is an engine front-end to back-end communication protocol.
-
- Posts: 1808
- Joined: Wed Mar 08, 2006 9:19 pm
- Location: Oslo, Norway
Re: What's the role of the GUI?
Of course not! Making this possible is one of the main purposes of free software like Fruit. It's a feature, not a problem.hgm wrote:If a hypothetical engine autor is happy with the way Fruit does its search, and just plugs in his own evaluation, to save him some work, would that be a problem?
The conditions of the GNU Public License and the rules of most computer chess tournaments impose some limitations about what the author would be allowed to do with the program, of course, but that's another discussion.
Feel free to use those words instead, if you prefer. I don't see how it makes any difference. My point remains: It shouldn't matter to anyone how I divide tasks between the front-end and the back-end of my chess program.GUIs that involve themselves in the decision of move selection are not GUIs. They are front-ends of engines.
UCI is not an engine-GUI communication protocol. It is an engine front-end to back-end communication protocol.
Tord
-
- Posts: 1922
- Joined: Thu Mar 09, 2006 12:51 am
- Location: Earth
Re: What's the role of the GUI?
I don't think we are disagreeing so much here. I think modularity is definitely a good design decision, and I've done that as much as I could (though I could make it moreso, especially with the addition of UCI support). The difference is that I've programmed my "front-end" functions in C, while yours are in Lisp. And this means that your front end and back end end up being two separate programs.Tord Romstad wrote:I'm not sure it's only that. Even if I were sufficiently masochistic to write my interface in plain C, I would prefer to let my engine do nothing more than computing the moves. It's just a far cleaner design, IMHO. I want to keep my engine code as simple and uncluttered as possible (although pressure from users has unfortunately forced me to pollute it with a few things like book code and a benchmark function).Zach Wegner wrote:I know what you are saying. Maybe it is because you are a high-level language guy, and I'm a low level language guy.
I guess that's true. You are going from the angle of writing your own engine+GUI package though. Whenever someone uses your engine in a tournament, it loses that control as you don't work under your GUI.So do I, and I have just as much control over it when I do it from the GUI. In a certain sense, I have even more control, because both the development time and the risk of bugs are an order of magnitude smaller.Really, I just like having as much control as possible over the strength of my engine, whether it's a good thing or not. I like to have my own book formats, book-move selection algorithms, resigning, drawing, etc.
That's pretty cool. And it's rather similar to what I do, but I take the "masochistic" route.I do that, to -- more specifically from the Lisp prompt, with various functions for interacting with the engine and instructing it to do different tasks. The main difference compared to interacting directly with the engine is that instead of just having access to the few lame commands I have implemented in the engine, I have access to a full, powerful interactive programming language, extended with functions for running matches, tournaments and test suites, for pretty-printing PVs, for reading and writing PGN games, for opening a window with a graphical chess board, and so on.
To demostrate how masochistic I am, I am considering building a macro language into my engine so that I can build custom commands, and maybe even support variables. It's pretty much pointless (and a poor substitute for a Lisp REPL), but again it would be fun to do.
Also things like my integrated in-search debugger are pretty hard to do with a separate program (and a recursive search, for that matter). I really need to work more on that. I envision a gdb-like interface that the user can dynamically control the search in. (I should say that I really have no idea whether you've used gdb or not. ) One thing I'm considering is to make a tree-viewer/XML parser in addition to it, as I would like to just click around and look at the tree. I could also construct a tree of the hash table, even for just a part below a certain node. This is getting rather OT, so I'll stop rambling. I just like to discuss the weird stuff bouncing around in my head sometimes.
Well, you got me there on a technicality...Neither do I, but it doesn't.I don't like my engine to require a GUI to play with.
Zach
-
- Posts: 27894
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: What's the role of the GUI?
Very true.Tord Romstad wrote:Feel free to use those words instead, if you prefer. I don't see how it makes any difference. My point remains: It shouldn't matter to anyone how I divide tasks between the front-end and the back-end of my chess program.
But as soon as others start to use parts of your Chess engine inside their own, it raises the issue of originality. It is no violation of the GPL to 'make' an engine by changing the PrintPV routine so that it is somewhat more informative. Yet, most tournament organizers do not want such engines to populate their tournaments.
Using the front-end of another engine because it saves time is like using anabolic steroids in weight lifting because it saves you hard training labor.
-
- Posts: 388
- Joined: Wed Mar 08, 2006 10:08 pm
Re: What's the role of the GUI?
I'm simply stating there is a good value in separating the UI role from the engine role. The UI to display, and the engine to decide on the move.
You seem to be talking about the GUI having a built-in engine. That idea can also be extended to the GUI having a networking stack, and memory manager, and file system.
You rarely see these types of integration because its just bad design.
The compiler you are using, is it built in to the IDE? There is a reason why almost all modern IDEs don't have built-in compilers. Its the same reason why almost all modern interfaces rely on plug-ins to do any useful job.
You seem to be talking about the GUI having a built-in engine. That idea can also be extended to the GUI having a networking stack, and memory manager, and file system.
You rarely see these types of integration because its just bad design.
The compiler you are using, is it built in to the IDE? There is a reason why almost all modern IDEs don't have built-in compilers. Its the same reason why almost all modern interfaces rely on plug-ins to do any useful job.
It matters from a software engineering point of view. Nobody does monolithic designs these days. Users don't know that windowing system of an OS is different from the kernel. But the programmers make that distinction.Tord Romstad wrote: Why does it matter? It is likely that no user would even notice what is done by the engine and what is done by the UI.
I'm just pointing out that all that the UI should just tell me is how much time there is, and not how much I should spend. I'm using that as an example of the separation of roles.Tord Romstad wrote: Again, I don't understand how this relates to anything in the discussion. In my program, the engine is told how much time it has left, and can choose to use it however it likes.