What's the role of the GUI?

[Tord Romstad]

I think this is similar to objections about opening books. For some, a program isn't allowed to have implanted memories of openings (and presumably also endings). Do you see any difference in these arguments? Are openings OK because it isn't so much code as it is a "table", but the endings are also tables, but also significant amounts of code?

I agree, opening books and EGTB code is more or less the same in this respect. Using opening books or EGTBs is OK, if you have written the book code and tablebase probing code yourself. Using somebody else's code is uncomfortably close to cheating, in both cases.

Tord

[Guetti]

I think this is similar to objections about opening books. For some, a program isn't allowed to have implanted memories of openings (and presumably also endings). Do you see any difference in these arguments? Are openings OK because it isn't so much code as it is a "table", but the endings are also tables, but also significant amounts of code?

I agree, opening books and EGTB code is more or less the same in this respect. Using opening books or EGTBs is OK, if you have written the book code and tablebase probing code yourself. Using somebody else's code is uncomfortably close to cheating, in both cases.

Tord

But what if one wanted to support a common opening book format, like i.e. book files created with polyglot. He would have to type in the book code himself, using Fruit/polyglot functions as a reference?

[mhull]

I think this is similar to objections about opening books. For some, a program isn't allowed to have implanted memories of openings (and presumably also endings). Do you see any difference in these arguments? Are openings OK because it isn't so much code as it is a "table", but the endings are also tables, but also significant amounts of code?

I agree, opening books and EGTB code is more or less the same in this respect. Using opening books or EGTBs is OK, if you have written the book code and tablebase probing code yourself. Using somebody else's code is uncomfortably close to cheating, in both cases.

Tord

So the Nalimov EGTBs would be OK in an official tournament as long as the engine programmer writes his own probing code. That would mirror an identical opening book policy where lots of books are already composed of a lot of public domain openings, but the "probing" code would be supplied by each programmer.

[Dann Corbit]

I think this is similar to objections about opening books. For some, a program isn't allowed to have implanted memories of openings (and presumably also endings). Do you see any difference in these arguments? Are openings OK because it isn't so much code as it is a "table", but the endings are also tables, but also significant amounts of code?

I agree, opening books and EGTB code is more or less the same in this respect. Using opening books or EGTBs is OK, if you have written the book code and tablebase probing code yourself. Using somebody else's code is uncomfortably close to cheating, in both cases.

Tord

Since we have nice examples and tutorials about how to write EGTB probing interfaces, writing that bit is trivial. It is the generation of the data that is non-trivial.

To a lesser extent, I think the same thing is true for opening books and certainly in the case of professional book builders.

[wgarvin]

No, no no no! The engine's job is to play chess. The GUI's job is to display a pretty picture of the board. Resigning, using opening books, tablebases etc. is a part of playing chess and should be entirely the engine's job.

Huge snip

Maybe there should be common libraries for accessing tablebase files that are in a standard format? Each engine can then load them from the same place on disk through this standard library.

It seems to me that you are saying that using a dynamically loaded library written by somebody else to help the program select its moves is OK, but that using a separate program written by somebody else to help it select its moves is not OK? This seems absurd to me. The difference is purely technical. The only thing that should matter is to what extent you use code by others to select your moves, not whether the code is copied into your source code, is loaded as a library, or is running as a separate program.

It's also annoying that people tend to assume that everybody who wants to do non-trivial things on the GUI end intends to use somebody else's GUI. Some of us write complete chess programs, you know.

Tord

I don't care if two or more engines want to share the same DLLs that access tablebases. That is up to the author of each engine, the author(s) of these potentially-shared DLLs, and whether tournament rules permit it or not.

However, I DON'T want the GUI to use those (at least, not in any way that helps the engine).

A chess engine should not require a GUI to be fully functional at playing chess. You can provide your own GUI if you want to, maybe even with extra functionality for the user that other GUIs don't have---but *please* don't cripple your engine by putting stuff it needs to play chess into the GUI instead of the engine. All that does is prevent people from using your engine fully with other GUIs or without the GUI, in which case, why did you make your engine and your GUI two separate programs in the first place? The major benefit of modularity between GUI and engine is that we can mix and match them.

That's the whole point of having common communication protocols like Winboard too! I should be able to take two *engines* that speak "Winboard" and put a tournament director or something between them, and they should be fully capable of playing games at full strength, through the Winboard interface rather than some external GUI program. If we can't mix and match them, I claim you are doing us a disservice by making them separate programs. I guess my beef with UCI is that it encourages this wrongful division of labor between engine and GUI, in effect making the GUI a "front end part" of the engine. But this is wrong and harmful and bad. Just don't do it.

Okay. I've said my piece. Sorry if I hurt anybody's feelings.

[Dann Corbit]

No, no no no! The engine's job is to play chess. The GUI's job is to display a pretty picture of the board. Resigning, using opening books, tablebases etc. is a part of playing chess and should be entirely the engine's job.

Huge snip

Maybe there should be common libraries for accessing tablebase files that are in a standard format? Each engine can then load them from the same place on disk through this standard library.

It seems to me that you are saying that using a dynamically loaded library written by somebody else to help the program select its moves is OK, but that using a separate program written by somebody else to help it select its moves is not OK? This seems absurd to me. The difference is purely technical. The only thing that should matter is to what extent you use code by others to select your moves, not whether the code is copied into your source code, is loaded as a library, or is running as a separate program.

It's also annoying that people tend to assume that everybody who wants to do non-trivial things on the GUI end intends to use somebody else's GUI. Some of us write complete chess programs, you know.

Tord

I don't care if two or more engines want to share the same DLLs that access tablebases. That is up to the author of each engine, the author(s) of these potentially-shared DLLs, and whether tournament rules permit it or not.

However, I DON'T want the GUI to use those (at least, not in any way that helps the engine).

A chess engine should not require a GUI to be fully functional at playing chess. You can provide your own GUI if you want to, maybe even with extra functionality for the user that other GUIs don't have---but *please* don't cripple your engine by putting stuff it needs to play chess into the GUI instead of the engine. All that does is prevent people from using your engine fully with other GUIs or without the GUI, in which case, why did you make your engine and your GUI two separate programs in the first place? The major benefit of modularity between GUI and engine is that we can mix and match them.

That's the whole point of having common communication protocols like Winboard too! I should be able to take two *engines* that speak "Winboard" and put a tournament director or something between them, and they should be fully capable of playing games at full strength, through the Winboard interface rather than some external GUI program. If we can't mix and match them, I claim you are doing us a disservice by making them separate programs. I guess my beef with UCI is that it encourages this wrongful division of labor between engine and GUI, in effect making the GUI a "front end part" of the engine. But this is wrong and harmful and bad. Just don't do it.

Okay. I've said my piece. Sorry if I hurt anybody's feelings.

Actually, I think that the differences of opinion on this subect are very interesting.

I think that the tool vendors are not thinking about the tool users, though.

Also keep in mind that there has never been any experiment that shows EGTB files increase playing strength (though Bitbase files have shown an increase of ~50 Elo in some experiments).

EGTB files seem to be a wash. Probably this is due to most games finishing before the board is fairly empty, but the reason is not certain.

[bob]

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

When I enter a tournament, I don't want to play the _same_ opponent every round. With this shared GUI approach where the GUI can be responsible for the first 20+ moves played, not to mention timing decisions and what to ponder.

I also dislike having to play against the same opening book for more than one game, as has happened multiple times in the past at WCCC events...

If they want to use xboard, that is fine by me, xboard is just a GUI. But if xboard starts making decisions that affect the game, then it ought not be used by other than the author.

[bob]

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

What if I choose to use the ChessBase GUI which just happens to use (say) Rybka to choose part of the moves? My code will be called to play once we reach move 40.

[bob]

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.

As per past rules, it would be a problem. The search of each engine is pretty unique in how it works. Ditto for the evaluation. The parts that actually choose moves or make decisions that would affect how the engine chooses moves do not belong in the GUI. One reason I do not use UCI.

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

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

I'm not mixing things at all. This has been discussed ad nauseum in the past, with no real resolution. If a GUI is going to participate in the game itself, rather than just being a "User Interface" (the UI part) then only one such instance should be allowed in a tournament. Time allocation is a tricky and interesting part of the game. Programmers should not be able to use an existing piece of code to handle that. Ditto for opening book move selection which is another very tricky and complex issue.

GUI does _not_ imply all of those things. A user interface is simply an interface that sits between a user and some application, in this case a chess engine. The interface "connects" the two, no more, no less. Xboard/Winboard is a classic example. It does nothing but relay moves between the user and the engine, and display the board... That is a traditional GUI.