What's the role of the GUI?
Posted: Thu May 15, 2008 4:47 pm
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...Uri wrote:What's the rule of the GUI? Does the GUI improve the program's playing strength?
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?
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.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.
Tord
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.Uri wrote:What's the rule of the GUI? Does the GUI improve the program's playing strength?
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...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
So in summary the GUI features should be able to be set on a per engine basis?bob wrote: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...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
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?bob wrote: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...
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.bob wrote: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.Uri wrote:What's the rule of the GUI? Does the GUI improve the program's playing strength?
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.