What's the role of the GUI?

[Uri]

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

[Zach Wegner]

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

[Edmund]

GUI = Graphical user interface

It's main task is to display the board. The calculation is left to the engines. Though some GUI protocols take over some roles such as time-management (+pondering), opening moves selection or endgame tablebase usage.

The most popular protocols used to communicate between the GUI and the engine are today: xboard and uci

[Tord Romstad]

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

[Zach Wegner]

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 know what you are saying. Maybe it is because you are a high-level language guy, and I'm a low level language guy. 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. I also would like to someday implement a specialized pondering algorithm and a "swindle mode". Only by taking complete control of the moves your engine makes can you get this flexibility. Whether it is worth it or not, it probably isn't (look at ZCT...). But I am doing this mostly for my own amusement, and if anyone else likes my engine it's just a nice side effect.

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 don't like my engine to require a GUI to play with. I was actually very surprised when I was working on Toga to find that there isn't even a function to print the board. Completely different design philosophies...

Zach

[bob]

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

It should not affect strength at all, but many have "forgotten" this. And so we have GUIs that choose opening book moves, GUIs that play endgame database moves if the position starts off in a known EGTB position, GUIs that decide how much time the engine can use, GUIs that decide what/when the engine should ponder something, and probably other things I have forgotten.

All of which represents a large problem IMHO for compute chess events, where the same GUI is used by several different programs, so that they all have the same opening book code, moves, etc, which is similar to having multiple copies of the same program playing. many opening lines go 20 moves deep, many games are over by move 40, meaning the GUI can be responsible for 1/2 the moves played.

It isn't reasonable, but it hasn't been addressed/fixed either.

[bob]

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

If you are the only user of that GUI nobody would care. But if that GUI is used by other programs, then a single author is writing a significant part of another engine's actual chess-playing code. That's the problem with this... It only happens when the GUI is shared...

[krazyken]

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

If you are the only user of that GUI nobody would care. But if that GUI is used by other programs, then a single author is writing a significant part of another engine's actual chess-playing code. That's the problem with this... It only happens when the GUI is shared...

So in summary the GUI features should be able to be set on a per engine basis?

[Tord Romstad]

If you are the only user of that GUI nobody would care. But if that GUI is used by other programs, then a single author is writing a significant part of another engine's actual chess-playing code. That's the problem with this...

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?

Tord

[Tord Romstad]

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

It should not affect strength at all, but many have "forgotten" this. And so we have GUIs that choose opening book moves, GUIs that play endgame database moves if the position starts off in a known EGTB position, GUIs that decide how much time the engine can use, GUIs that decide what/when the engine should ponder something, and probably other things I have forgotten.

All of which represents a large problem IMHO for compute chess events, where the same GUI is used by several different programs, so that they all have the same opening book code, moves, etc, which is similar to having multiple copies of the same program playing. many opening lines go 20 moves deep, many games are over by move 40, meaning the GUI can be responsible for 1/2 the moves played.

You are mixing two entirely unrelated things here. How tasks are divided between the UI and the engine part of a chess program is a purely technical design decision by the author, and is completely irrelevant with regard to computer chess events. To what extent a program should be allowed to use code written by other people than the author(s) to select its moves is an entirely different question.

Tord