What's the role of the GUI?

[Guetti]

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.

[Tord Romstad]

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

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

I also would like to someday implement a specialized pondering algorithm and a "swindle mode".

So would I, but again, driving it from the GUI would work just as well.

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.

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.

I don't like my engine to require a GUI to play with.

Neither do I, but it doesn't.

Tord

[Tord Romstad]

I think the problem is that your GUI plays chess for him, even if his engine doesn't know how to move.

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.

Tord

[CThinker]

What's the rule of the GUI? Does the GUI improve the program's playing strength?

No! I hate GUIs that resign, use opening books, tablebases, etc. That is the engine's job...

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.

Tord

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.

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!

[Tord Romstad]

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.

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.

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.

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.

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.

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?

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.

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.

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.

Resign? Why would I let others (the UI, that is), resign for my engine?

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

If my opponent is out of time, the engine could play on and perhaps win. People do that, why can't the engine?

Why can't the GUI?

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.

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.

Tord

[hgm]

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?

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?

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 Romstad]

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?

Of course not! Making this possible is one of the main purposes of free software like Fruit. It's a feature, not 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.

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.

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.

Tord

[Zach Wegner]

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

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.

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

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.

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.

That's pretty cool. And it's rather similar to what I do, but I take the "masochistic" route.

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.

I don't like my engine to require a GUI to play with.

Neither do I, but it doesn't.

Well, you got me there on a technicality...

Zach

[hgm]

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.

Very true.

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.

[CThinker]

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.

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.

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.

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.

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.