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?

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

EGTB and bitbase, opening book and resign all belong to the GUI in my mind. I think for the opening book, it makes sense to let the program override the GUI.

For tablebase files, we are looking at tens of gigabytes of disk. There should be one and only one tablebase system on a computer for playing chess. It's lunacy to have five different tablebase systems and five different ways to set up how to access them. Now imagine 1000 chess playing programs (I have at least that many -- for a long time now I can't load all my chess programs into Arena, the arrays are full). Now imagine trying to set up tablebase files for all of these programs. How many use tablebase files? How many want to read the location from the environment? How many from an ini file? How many from the command line and with what syntax? It causes a terrible mess.

Most programs use Nalimov tablebase files and the authors of those programs clearly did not write the nalimov tablebase access code. So why should they object if the tablebase access were move to the GUI so that WE WILL HAVE A SINGLE POINT OF ADMINISTRATION.

The same thing goes for books and bitbases, etc. Now, the book is more personal I think because some program authors spend a lot of effort on their books. So that one I can imagine is perfectly fine to also have an "own book" option.

Also resigning should be controlled by the GUI and I do not want two programs that both have tablebase files to bluff each other for two hours in a tablebase drawn position.

IMO-YMMV.

[hgm]

I do not want two programs that both have tablebase files to bluff each other for two hours in a tablebase drawn position.

According to FIDE rules, it is the engine's right to do just that.

If you don't want it, you can adjudicate such games. And it is OK to delegate that task to the GUI. The GUI can consult bitbases for this.

[Tord Romstad]

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.

This is the point I tried to address in one of my replies to Bob. In my opinion, there are two questions:

1. In a chess program which consists of an engine and a GUI, what tasks should be done by the engine, and what tasks by the GUI?

2. In a computer chess tournament, should it be allowed to use code written by other authors in the decision-making process?

You, Bob and many others seem to think the two questions are closely related. I don't see why. The first question is of purely technical and pragmatic nature, and has no single "right" answer, it depends on the skills and goals of the programmer. The second is a question about how tournament rules should be.

I would happily accept tournament rules which prohibits all use of code written by other authors in the move-selection process. Ironically, I suspect that Bob would be more opposed to such a rule, because he may want to keep using the Nalimov EGTB code.


Tord

[Tord Romstad]

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.

I agree that there is god value in sharing the responsibilities, I have just chosen to share the tasks a bit differently. In a certain sense, I have not just two, but three different component: A chess engine, which does little more than search and evaluate positions, a component which handles games, clocks, opening books, and all other high-level chess-related stuff, and a GUI which displays boards, engine output, clocks, move lists and so on on the screen.

You seem to be talking about the GUI having a built-in engine.

I am not sure why you got that impression. My engine is of course a separate process, just like yours. It just can't do much on its own, apart from searching and evaluating chess positions.

The compiler you are using, is it built in to the IDE?

As a matter of fact: Yes, it is. The compiler, the IDE, the debugger, and the program I am developing are basically all the same thing. I have gotten so use to this style of working that the adjective "integrated" in IDEs for C, C++ or Java sounds almost comical. But I'm a Lisper, and not a real programmer, so it is not surprising that my world looks very different.

When I program in C/C++, my IDE consists of a pen, big amounts of paper, and a stack of classical music CDs, so in that case you are right: There is no built-in compiler, apart from the painfully slow and buggy pseudocode to C compiler in my brain.

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.

The use of the word "me" in the sentence above makes me suspect that we don't quite understand each other. My UI should tell me what the board, the move list and the engine's analysis look like. It should tell my engine how much time it has left. My engine should decide how much time it wants to spend.

Tord

[hgm]

Using Nalimov code in official tournaments is cheating, plain and simple. I cannot imagine why tournament directors allow it.

[Tord Romstad]

Zach, I think we mostly agree.

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.

True, but I don't take a tournament 100% seriously unless I am there and operate my engine myself, and in that case I always use my own GUI (OK, I did use the Shredder GUI in Mainz once a few years back, but that's because I had to use the Windows computers supplied by the sponsors, and had no Windows compatible UI of my own).

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

EGTB and bitbase, opening book and resign all belong to the GUI in my mind. I think for the opening book, it makes sense to let the program override the GUI.

For tablebase files, we are looking at tens of gigabytes of disk. There should be one and only one tablebase system on a computer for playing chess. It's lunacy to have five different tablebase systems and five different ways to set up how to access them. Now imagine 1000 chess playing programs (I have at least that many -- for a long time now I can't load all my chess programs into Arena, the arrays are full). Now imagine trying to set up tablebase files for all of these programs. How many use tablebase files? How many want to read the location from the environment? How many from an ini file? How many from the command line and with what syntax? It causes a terrible mess.

Most programs use Nalimov tablebase files and the authors of those programs clearly did not write the nalimov tablebase access code. So why should they object if the tablebase access were move to the GUI so that WE WILL HAVE A SINGLE POINT OF ADMINISTRATION.

The same thing goes for books and bitbases, etc. Now, the book is more personal I think because some program authors spend a lot of effort on their books. So that one I can imagine is perfectly fine to also have an "own book" option.

Also resigning should be controlled by the GUI and I do not want two programs that both have tablebase files to bluff each other for two hours in a tablebase drawn position.

IMO-YMMV.

The GUI will probably query the EG database before each move. But what if I want my engine to consult the EG database during search (say, at evaluation)?

If I just let the GUI make the query before each move, then its too late. The game has been decided.

I'm OK with having a centralized repository for the EG database. But I still want to have control on when to use it.

[mhull]

Using Nalimov code in official tournaments is cheating, plain and simple. I cannot imagine why tournament directors allow it.

How is it different than using the C standard library?

[wgarvin]

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

EGTB and bitbase, opening book and resign all belong to the GUI in my mind. I think for the opening book, it makes sense to let the program override the GUI.

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.

I think the ideal GUI would be completely engine-agnostic. It should use a simple, clear, unambiguous protocol to communicate with engines, and it should allow engines to reach out and interact with the user if they want to (e.g. by publishing their configurable parameters to the GUI so it can make widgets and sliders for them). But the GUI should not take actions that affect the game state (such as resigning or playing a move), or give advice to the engines (such as telling them what the opening book says).

The GUI should be kind of like a referee or arbitor. It only checks that the rules are followed by the competitors (the engines), it is not allowed to give hints to one competitor or take actions on its behalf. The GUI is not supposed to play chess, its ONLY job should be to display the pretty picture of the board and relay actions back and forth between the competitors. Ideally, playing 2 engines against each other should only require *one* GUI, not two---which means that GUI must not play favorites, or take sides, or interfere in the actual game in any other way.

For tablebase files, we are looking at tens of gigabytes of disk. There should be one and only one tablebase system on a computer for playing chess. It's lunacy to have five different tablebase systems and five different ways to set up how to access them. Now imagine 1000 chess playing programs (I have at least that many -- for a long time now I can't load all my chess programs into Arena, the arrays are full). Now imagine trying to set up tablebase files for all of these programs. How many use tablebase files? How many want to read the location from the environment? How many from an ini file? How many from the command line and with what syntax? It causes a terrible mess.

Most programs use Nalimov tablebase files and the authors of those programs clearly did not write the nalimov tablebase access code. So why should they object if the tablebase access were move to the GUI so that WE WILL HAVE A SINGLE POINT OF ADMINISTRATION.

The same thing goes for books and bitbases, etc. Now, the book is more personal I think because some program authors spend a lot of effort on their books. So that one I can imagine is perfectly fine to also have an "own book" option.

Also resigning should be controlled by the GUI and I do not want two programs that both have tablebase files to bluff each other for two hours in a tablebase drawn position.

IMO-YMMV.

I can see where you're coming from. If you're playing two engines against each other and they both use Nalimov tablebases... should you try and load only one copy of the tablebases into memory and share them between both engines? But how equitable will that be, really? There is no way to know. Much better to have dedicated memory for each engine, even if its kind of wasteful, because then you know with certainty how many resources the engine was given to use. How it uses them--tablebases or whatever---should be entirely up to the engine.

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.

But putting that functionality into the GUI in ways that engines can then depend on the GUI to tell them things or do things for them (like resign or play a tablebase move) is just wrong, wrong, wrong.

IMO, of course! =)

[Tord Romstad]

Using Nalimov code in official tournaments is cheating, plain and simple. I cannot imagine why tournament directors allow it.

How is it different than using the C standard library?

It's very different. The C standard library does not contain functions which directly help you decide which moves to make. Surely you must agree that there is a fundamental difference between calling a function which displays a text string on the screen, and a function which takes a chess position as input and returns the number of moves to mate?

Tord