What's the role of the GUI?

[Dann Corbit]

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.

It also tells you important things like how much time the opponent has left.

[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

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.

What if I choose to paste Crafty's entire source code into my own source code, and let it do all the actual thinking until the game reaches move 40? Would be more or less the same, wouldn't it?

Just as an example to show that it is the use of code written by others which matters, and not whether all the game-playing code is located in the same executable.

Tord

[Tord Romstad]

I'm not mixing things at all.

Yes, you are!

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.

Absolutely. I agree completely. But once again: This is not an argument against letting the GUI doing some of the work in selecting the moves, but only against allowing the use of code written by others in selecting the moves.

I don't understand why this is so hard to understand. I'll try to explain once more, before I give up and go to bed:

Copying book and EGTB code from other programs is not OK. Using a GUI written by somebody else to select some of the game moves is not OK. These two are equivalent, apart from technical matters which are unimportant except to the programmer.

Writing an engine entirely by yourself which does all the work of selecting the moves, including book moves and EGTB access, is OK. Writing an engine which relies on a GUI written by yourself to select some of your moves is OK. These two are equivalent, apart from technical matters which are unimportant except to the programmer.

Tord

[Tord Romstad]

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?

Easy: Just implement support for Polyglot (or whatever) books in the public version of your program for the benefit of your users, but use something else in tournaments.

Tord

[Tord Romstad]

So the Nalimov EGTBs would be OK in an official tournament as long as the engine programmer writes his own probing code.

I wouldn't be comfortable with that either, but it would definitely be better than just copying Nalimov's code without even understanding it.

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.

Yes, in a certain sense it is precisely equivalent to probing somebody else's book format with code written by yourself. I actually do this: Glaurung can read PolyGlot books, using my own code. This troubles me a little, even though the original PolyGlot book code actually was loosely based on the book code in an ancient Glaurung version. Therefore, I don't plan to use a PolyGlot book in Lodz next month.

Tord

[Tord Romstad]

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.

I don't agree: Generating EGTBs is almost trivial; you just need lots of CPU time, disk space and RAM. The tricky part is to find a compression, indexing and caching scheme which is space-efficient and allows very fast lookup.

Tord

[Dann Corbit]

I'm not mixing things at all.

Yes, you are!

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.

Absolutely. I agree completely. But once again: This is not an argument against letting the GUI doing some of the work in selecting the moves, but only against allowing the use of code written by others in selecting the moves.

I don't understand why this is so hard to understand. I'll try to explain once more, before I give up and go to bed:

Copying book and EGTB code from other programs is not OK. Using a GUI written by somebody else to select some of the game moves is not OK. These two are equivalent, apart from technical matters which are unimportant except to the programmer.

Writing an engine entirely by yourself which does all the work of selecting the moves, including book moves and EGTB access, is OK. Writing an engine which relies on a GUI written by yourself to select some of your moves is OK. These two are equivalent, apart from technical matters which are unimportant except to the programmer.

Tord

Pretty much every commercial chess program relies upon a commercial book and interface not written by them. Fruit is the only exception that I can think of, but it also comes with a commercial book besides the one that Fabian wrote for polyglot.

I guess that (for instance) with chess base they just call a dll file to get the moves.

Doesn't glaurung use the fruit/polyglot book code?
By your definition, wouldn't that be disallowed?

[Dann Corbit]

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.

I don't agree: Generating EGTBs is almost trivial; you just need lots of CPU time, disk space and RAM. The tricky part is to find a compression, indexing and caching scheme which is space-efficient and allows very fast lookup.

Tord

I guess really that we agree then, because I consider the indexing, caching and etc. to be part of the EGTB generator.

[Tord Romstad]

OK, one last post before going to bed.

Pretty much every commercial chess program relies upon a commercial book and interface not written by them. Fruit is the only exception that I can think of, but it also comes with a commercial book besides the one that Fabian wrote for polyglot.

Perhaps you are right -- I don't know that many of the commercial engines. The only ones I have on my current computer are Hiarcs, which uses its own internal book, and Shredder, which uses a GUI book, but where the GUI book code was probably written by SMK himself.

I should emphasize, however, that my opinions about this are not really nearly as rigid as they might appear in this thread. I don't really care that much about engines running in third-party GUIs with book support in official tournaments. In principle I am not very fond of it, but it isn't all that important to me.

I exaggerated in order to illustrate a point: That Bob's (among others) "GUI selects book moves == evil" stance doesn't make sense. What he doesn't like (I think) is that not all moves in tournament games are selected using code written by the official author(s) of the programs. Focusing on who has written the code that selects the moves makes some sense. Focusing on whether all the code that is involved in selecting the moves is located in a single executable file does not.

Doesn't glaurung use the fruit/polyglot book code?
By your definition, wouldn't that be disallowed?

I've addressed this elsewhere in the thread.

Tord

[mhull]

So the Nalimov EGTBs would be OK in an official tournament as long as the engine programmer writes his own probing code.

I wouldn't be comfortable with that either, but it would definitely be better than just copying Nalimov's code without even understanding it.

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.

Yes, in a certain sense it is precisely equivalent to probing somebody else's book format with code written by yourself. I actually do this: Glaurung can read PolyGlot books, using my own code. This troubles me a little, even though the original PolyGlot book code actually was loosely based on the book code in an ancient Glaurung version. Therefore, I don't plan to use a PolyGlot book in Lodz next month.

Tord

I suppose the real difference that makes openings and endings not really the same issue is that ending tables are in the category of scientific fact. Openings are more theory and hypothesis, and thus a greater potential for advantage than endings. Therefore, one might consider the factual end-tables to be less of a concern in a competition since they are now available and accessible to all through common tables and probing-code.