What's the role of the GUI?

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

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

So if you remove the C standard includes from your code right now, will it continue to choose moves to play?

[michiguel]

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

No kidding.

I think it will benefit Bob because Crafty will be the only engine allowed to use Nalimov code. In other words, the tradition in the rules, AFAIK, it was not that an author cannot use code from another author, but that one author cannot have more than one entry in a tournament. If we consider Nalimov code as part of the the decision making process an as such part of the engine, the engine will be Crafty authors: Hyatt/Nalimov and no other engine will be allowed to use Nalimov code (engine database or anything else) in a given tournament. Bod did not agree with this perspective in the past when it was discussed here. This was Bruce Moreland opinion. In fact, that is the reason why he wrote his own EGTBs.

I agree with Bruce.

Miguel
PS: similar things should apply to book opening makers, but that is even more controversial.

[Tord Romstad]

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

[michiguel]

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

I almost agree.

Nalimov code should be allowed to be used in only one engine.

Miguel

[Tord Romstad]

So if you remove the C standard includes from your code right now, will it continue to choose moves to play?

Nothing in the C standard libraries has anything whatsoever to do with chess. If you don't see that there is a world of difference between calling library functions for doing IO, for allocating memory, for copying data from one place to another, and other low level tasks on one hand, and calling code which gives you perfect game-theoretic knowledge for a non-trivial subset of all possible chess positions on the other hand, I am not sure what I can say to make it clearer to you.

Tord

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

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.

The GUI should run and publish an interface to an EGTB and Bitbase server.

[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

If people are more comfortable with common DLL files for EGTB use and access, then I think that way is just as good. However, I would like to administrate where the DLL files are and how much ram to use, etc. from the GUI.
So it looks just like the GUI is doing it but "wink, wink" the DLLs are doing it.

[Dann Corbit]

So if you remove the C standard includes from your code right now, will it continue to choose moves to play?

Nothing in the C standard libraries has anything whatsoever to do with chess. If you don't see that there is a world of difference between calling library functions for doing IO, for allocating memory, for copying data from one place to another, and other low level tasks on one hand, and calling code which gives you perfect game-theoretic knowledge for a non-trivial subset of all possible chess positions on the other hand, I am not sure what I can say to make it clearer to you.

Tord

To those who think that using someone else's egtb code is cheating, then using Winboard or Xboard or Arena to run the games is also cheating because it is chess specific and they did not write it.

I think it is lunacy to have everyone write their own UCI or Winboard interface.

I think it is lunacy to have everyone write their own EGTB file set and interface.

I think it is lunacy to have everyone write their own Bitbase file set and interface.

But then again, maybe I'm a lunatic.

[mhull]

So if you remove the C standard includes from your code right now, will it continue to choose moves to play?

Nothing in the C standard libraries has anything whatsoever to do with chess. If you don't see that there is a world of difference between calling library functions for doing IO, for allocating memory, for copying data from one place to another, and other low level tasks on one hand, and calling code which gives you perfect game-theoretic knowledge for a non-trivial subset of all possible chess positions on the other hand, I am not sure what I can say to make it clearer to you.

Tord

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?

[Tord Romstad]

To those who think that using someone else's egtb code is cheating, then using Winboard or Xboard or Arena to run the games is also cheating because it is chess specific and they did not write it.

I think using someone else's egtb code is far worse, because Xboard and Arena don't actually help you decide which moves to play (unless Arena has some kind of book and/or EGTB access). But I agree to some extent: I will never use Xboard, Arena or any other interface written by others when I participate in person in an official tournament. This includes tournaments on the CCC.

I think it is lunacy to have everyone write their own UCI or Winboard interface.

Why? Writing a simple command line interface isn't much work.

I think it is lunacy to have everyone write their own EGTB file set and interface.

I think it is lunacy to have everyone write their own Bitbase file set and interface.

I agree to some extent. It would be impractical if all users would have to download a different set of EGTB files for every chess program they wanted to run, so it makes sense to allow all programs to use some form of standardized EGTB format, and perhaps even share the code for probing it. However, I don't think they should write their own bitbase or EGTB code if they want to use it in official tournaments.

But then again, maybe I'm a lunatic.

We all are. Otherwise, we wouldn't be here.


Tord