Organising a computer chess event...

[hgm]

How does your book respond to 1.d4 d5 2.e3,Bg4

Does it play the move Nf3 here, or does it capture the bishop?

Polyglot books do store move-lists per position, so they do not make an effort to return in book. Just when they accidentally do under their own steam, they use the book moves again. So no problem there.

The refutation problem is an interesting one. I had planned to solve it (should I ever become interested in book building, which sms unlikely) by simply mininimaxing the tree of book moves, rather than using frequencies at internal nodes. The latter in fact corresponds to the algorithm

nodeScore = SUM(moveScore);

And we know that a Chess engine based on a search that propagates scores like that will not play very strong (Unless the purpose is to defeat a radom mover s quickly as possible, perhaps.) So we usually propagate scores using minimax:

nodeScore = MAX(moveScore);

A continuous interpolation between taking a maximum or computing the sum would be

nodeScore = (SUM(moveScore^N))^(1/N);

You would somehow want to weight against move that have not been played very often, though.

[Tord Romstad]

The GUI is not an engine and so should not be involved with move selection.

People often say this, and I never understand them. Why shouldn't I let my GUI handle the book moves, if I prefer to do so? It's just a more convenient way to divide the work in my program. The engine does nothing more than search and evaluation, the GUI does everything else, including book move selection. With some work, it would be possible to port my book code to C++ and copy and paste it to my engine source, but what's the point? It's still the same code, and whether it is placed in the engine or in the GUI shouldn't matter to anyone. Without looking at the source code, hardly anyone would even notice the difference.

Tord

[krazyken]

The GUI is not an engine and so should not be involved with move selection.

People often say this, and I never understand them. Why shouldn't I let my GUI handle the book moves, if I prefer to do so? It's just a more convenient way to divide the work in my program. The engine does nothing more than search and evaluation, the GUI does everything else, including book move selection. With some work, it would be possible to port my book code to C++ and copy and paste it to my engine source, but what's the point? It's still the same code, and whether it is placed in the engine or in the GUI shouldn't matter to anyone. Without looking at the source code, hardly anyone would even notice the difference.

Tord

I think your case is special. Most people when they are talking about GUI and engine, the two were written by different people with no relationship to each other at all.

[bhlangonijr]

People often say this, and I never understand them. Why shouldn't I let my GUI handle the book moves, if I prefer to do so? It's just a more convenient way to divide the work in my program. The engine does nothing more than search and evaluation, the GUI does everything else, including book move selection. With some work, it would be possible to port my book code to C++ and copy and paste it to my engine source, but what's the point? It's still the same code, and whether it is placed in the engine or in the GUI shouldn't matter to anyone. Without looking at the source code, hardly anyone would even notice the difference.

Tord

i've tried to understand why people are so against GUI doing book move selection. Now I see that it is more like a "religious" inclination.

What the heck could I do to my engine select a better move from the book that the GUI by itself couldn't?

[Tord Romstad]

I think your case is special. Most people when they are talking about GUI and engine, the two were written by different people with no relationship to each other at all.

Perhaps it is, but if that is what they mean, why don't they just say "you shouldn't use book code written by somebody else"? It isn't that many additional characters to type compared to "you shouldn't let a GUI handle the book", and unlike the latter sentence, it actually makes some sense (in the context of official tournaments). The important thing isn't where the book code is located, but who wrote it.

Tord

[bob]

I am considering to add bitbase-based adjudication to WinBoard, but I am not sure that engines should be allowed to claim a draw. Knowing that some position is a draw is a lot easier than actually salvaging the draw. Suppose Chess has been solved by connecting all supercomputers in the univers for a couple of hundred years in parallel, and the opening position is proven a draw. Should any patzer like me now be allowed to claim a draw when fcing Rybka 3? In Checkers this situation already exists.

It would be very easy to me to make my engine test for KBNK, and claim "tablebase win" when it sees that matrial, without actually having the tablebase and with no idea how to effect the checkmate.

So I think it would be better to give this the status of an adjudication, which it really is. The GUI (by proxy of the user) can declare the game finished when it reaches a stage of a given number of men, irrespective of what the engines think about it. I think it would be very bad to design a protocol tht could allow engines to bluff their way to victory.

But it would be even worse to let the GUI claim a position is won when it can not be won by the official rules of chess.

I don't see anything wrong with having this as an option, so that automated testing can proceed quicker. But it has to be something that can be turned off for _serious_ chess where the real rules have to be followed...

[bob]

The GUI is not an engine and so should not be involved with move selection.

People often say this, and I never understand them. Why shouldn't I let my GUI handle the book moves, if I prefer to do so? It's just a more convenient way to divide the work in my program. The engine does nothing more than search and evaluation, the GUI does everything else, including book move selection. With some work, it would be possible to port my book code to C++ and copy and paste it to my engine source, but what's the point? It's still the same code, and whether it is placed in the engine or in the GUI shouldn't matter to anyone. Without looking at the source code, hardly anyone would even notice the difference.

Tord

So long as _you_ write the code, I don't see a problem if you have 10 different programs, one to play endgames, one to play middlegames, one to play the openings, one to play blitz, etc. And your GUI decides which one to use. But if someone _else_ wants to use your code and just replace the middlegame program with their own, keeping the rest, I do not believe that is reasonable. yet that is exactly what is happening. GUIs handle openings, book learning, opening move selection/rejection, egtb positions, control time usage, tell the program what to ponder, when to ponder, how long to ponder, etc.

Those concepts do not belong, IMHO, unless the same author writes them all. Then I don't care _how_ you split up the modules and write them...

[bob]

People often say this, and I never understand them. Why shouldn't I let my GUI handle the book moves, if I prefer to do so? It's just a more convenient way to divide the work in my program. The engine does nothing more than search and evaluation, the GUI does everything else, including book move selection. With some work, it would be possible to port my book code to C++ and copy and paste it to my engine source, but what's the point? It's still the same code, and whether it is placed in the engine or in the GUI shouldn't matter to anyone. Without looking at the source code, hardly anyone would even notice the difference.

Tord

i've tried to understand why people are so against GUI doing book move selection. Now I see that it is more like a "religious" inclination.

What the heck could I do to my engine select a better move from the book that the GUI by itself couldn't?

Simple answer. _YOU_ should have to write any code that is involved in any way with selecting/playing a move in the game. A GUI is a "User Interface" whose sole purpose is to relay moves from the engine to the user and vice-versa. If you want to use someone else's book learning code, endgame tablebase access code, time control code, I want to use someone else's chess-playing engine...