An idea for a new WCCC format - what do you think?

[bob]

Again, the issue is this: If the GUI "picks" the moves, it is playing chess. If several different programs run on the same GUI, they are sharing a significant piece of code that can often be responsible for playing more moves in a game than the engine plays. This has happened several times, where we had GUI-A, BOOK-A, program-A GUI-A, BOOK-A, program-B, etc. I consider that unreasonable.

I don't mind the same GUI if it is not playing chess. If it chooses moves, then just one copy of GUI-A should be allowed in a single tournament. Xboard is a good example of what a real "GUI" is. If you add a book selection to a GUI, it is no longer a GUI (check definition of "interface" as opposed to "chess playing entity".)

I am not sure where this fixation on GUIs comes from, but it's beginning to get on my nerves. Everything you write above is technically correct, but talking about GUIs all the time is beside the point, and only serves to confuse matters and cast unnecessary suspicion over those of us who prefer to let the GUI handle the book moves. As I have said many times before, the thing that matters is who wrote the book code, not in which executable the book code is found.

We keep getting into this discussion again and again, but I never seem to be able to get the point across. Is it really so hard to write "it should not be allowed for multiple programs to use the same opening book code" without using the word "GUI"?

Tord

OK, let me try to be "very precise" here.

by "GUI" I mean a program that more than one person can use to run their engine in a chess tournament. I don't care about private GUIs written for a specific engine. But if the GUI is used by someone that did not write it, the GUI should be limited to "GUI" functionality, which is to graphically display a chess board, and relay moves between the primary chess engine and the opponent, whatever/wherever that might be. It should not provide _any_ moves, that is the responsibility of the engine. The GUI should be just as passive in the game as the human operators are required to be with respect to WCCC games.

A private GUI can play the entire game for all I care. But nobody else can use it.

[Uri Blass]

<snipped>

Simple. Just provide some code that will characterize _all_ KRP vs KRP endings into "won, lost are drawn." That one is quite hard enough. Without worrying about KQRRPPP vs KQRRPPP and other impossible positions.

some comments:
1)I think that generally it is easier to have good rules for the cases one side has big material advantage and it is harder to find good rules for cases when material is equal.

positions when one side has big material advantage are also part of the tree that programs search and knowing to stop to search because it is sure win can help to save time.

2)I agree that all KRP vs KRP is impossible to characterize but a code that characterize half of them may be possible and code that do it may be useful because before probing the slow tablebases you have probability of 50% to avoid it and get exact result without it except number of moves to mate that is not important.

I agree that it is not easy even to characterize half in this specific case but in other cases it is easy to characterize more than half as win for the better side (for example KRPP vs KP)

Example for some idea for rules about KRP vs KRP.

win for the side to move:
The simple cases is when the side to move can capture the opponent rook in the next move and I guess that we can decide that if the rook of the side to move or the pawn of the side to move is not under threat and the pawn of the opponent is not in the 6th pr the 7th then it is a win for the better side.

If this rule is not correct it is possible to find the examples that it is not correct and correct the rules by the examples.

draw:
if no side has passed pawn and no side can capture the opponent pawn and the pawn or the rook and it is impossible to win the rook by direct check and some more conditions about the kings not to allow cases when one king is too far from the pawns then it is a draw.

[bob]

<snipped>

Simple. Just provide some code that will characterize _all_ KRP vs KRP endings into "won, lost are drawn." That one is quite hard enough. Without worrying about KQRRPPP vs KQRRPPP and other impossible positions.

some comments:
1)I think that generally it is easier to have good rules for the cases one side has big material advantage and it is harder to find good rules for cases when material is equal.

positions when one side has big material advantage are also part of the tree that programs search and knowing to stop to search because it is sure win can help to save time.

2)I agree that all KRP vs KRP is impossible to characterize but a code that characterize half of them may be possible and code that do it may be useful because before probing the slow tablebases you have probability of 50% to avoid it and get exact result without it except number of moves to mate that is not important.

My point was that _this_ is a difference between this idea and the EGTB idea. EGTBs have _no_ holes in them. They don't categorize some positions as won/lost/drawn and fail to do so on others. Given a particular constellation of pieces, standing on specific squares, you get an answer. For all possible constellations of pieces covered by the specific table, standing on all possible squares on the chessboard.

Whether we allow 'em or not in WCCC/CCT/etc tournaments is pretty irrelevant to me since I don't use 'em anyway...

I agree that it is not easy even to characterize half in this specific case but in other cases it is easy to characterize more than half as win for the better side (for example KRPP vs KP)

Example for some idea for rules about KRP vs KRP.

win for the side to move:
The simple cases is when the side to move can capture the opponent rook in the next move and I guess that we can decide that if the rook of the side to move or the pawn of the side to move is not under threat and the pawn of the opponent is not in the 6th pr the 7th then it is a win for the better side.

If this rule is not correct it is possible to find the examples that it is not correct and correct the rules by the examples.

draw:
if no side has passed pawn and no side can capture the opponent pawn and the pawn or the rook and it is impossible to win the rook by direct check and some more conditions about the kings not to allow cases when one king is too far from the pawns then it is a draw.

[Vasik Rajlich]

I would say EGTB code is an obvious 'no'. Especially if it is EGTB code that is not in the public domain, or that could not be used for everyone because of license requirements.

EGTB code is an interesting theoretical case, but in practice it doesn't make any difference. I'm pretty sure that if EGTB usage is disallowed, the tournament won't lose any participants.

Personally, I'd vote for allowing EGTBs, for practical reasons. There is no benefit to the chess world in having me or anyone else roll his own EGTB implementation.

Vas

[Vasik Rajlich]

I propose a hybrid.

The tournament would be online (ICC), but the participants would meet locally.

For example, Bob and others could congregate at UAB (this has been done in the previous ACCL). Dann, Kerwin and me would meet at UW or somewhere in Redmond.

This way, travel cost and travel time is really minimized, while at the same time, you get the eye ball experience of the traditional (read archaic) WCCC.

That could work with a few gatherings in different places. However I would not want to play on any server that stops me using a .ctg book easily. I am happy to use an alternative book for tournaments like CCT but our tournament book is maintained in .ctg format and for the World Championship we would want to use this.

This is the primary reason I have maintained that the GUI should _not_ be handling the book facilities. That should be code inside the engine. Then the GUI one uses has nothing to do with playing the game, choosing book moves, and just serves as a user interface, which is where the "UI" in "GUI" comes from. I also strongly believe that an opening book is every bit as unique and important as the chess engine itself, which means one copy of any author's book is allowed in an event, not the multiple copies we have seen in the past.

For the question about EGTBs I don't care. That is static data everyone has access to, how / when you probe them is an internal engine issue anyway so I could care less about what is used there.

Just to clear, we are not really talking about not allowing the GUI to pick the moves (in most cases, opening moves). In the Thinker case, I also wrote the GUI.

I think what we should be saying is that the participating computer player should not pick moves using code that is written by somebody else. It does not matter whether that code is in the GUI or external DLL or main engine. If you did not write the code, it should not be allowed to decide moves for you.

Here some examples of acceptable systems:

1. UI and engine from the same author
a. The Shredder UI connets to the server.
b. The Shredder UI picks the book moves.
c. The Shredder UI asks the Shredder engine to pick a move.

2. UI from one author, and engine from another author
a. The Winboard UI connets to the server.
b. The Winboard UI asks the Crafty engine to pick moves.
c. The Crafty engine book code picks book moves.
d. The Crafty engine code picks moves using search algorithm.

Here are some examples of non-acceptable systems:

1. UI and engine from the same author, but book code from another author
a. The Fritz UI connets to the server.
b. The Fritz UI asks the Fritz engine to pick a move.
c. The Fritz engine asks Polyglot to pick a book move
d. The Fritz engine use a search algorithm to pick non-book moves.

2. UI from one author, and engine from another author
a. The Fritz UI connets to the server
b. The Fritz UI picks book moves.
c. The Fritz UI asks the Crafty engine to pick a move.

Correct. We often diverge into where the dividing line should be between the GUI and the engine. If you write both, you should decide what goes where. My issue is with a GUI that is used by many. In this case, it should be a UI, and only a UI. Not select book moves. Not deal with learning. Nor with EGTBs. etc...

That's primarily an issue with the commercial guys as they share UIs here and there, and in past WCCC events they shared books which is beyond unreasonable IMHO. Xboard is a perfect example of what a GUI should be. It just relays moves back and forth between the engine and the opponent, and otherwise stays out of the way of how the game is actually played.

In practice, we're going to need to allow opening book and EGTB code. Most engine authors have been operating on the assumption that this is allowed and only a tournament with incredible rewards could entice them to write their own book code.

As far as the theoretical aspect - you could argue this a number of ways. The way to phrase the question is: under what conditions can code written by one person be used by multiple teams in the same tournament?

Compiler/IDE: Obviously yes.
Engine: Obviously no.
Book editing tool: On the border. Like the compiler/IDE, it is (mostly) an offline process. Like the engine, chess-specific logic is involved.

If we could go back several decades and re-design the rules from the ground up, I would still push for allowing teams to share opening book editing tools, for practical reasons. The book tools are separate from the engine - the code base is different, different programming skills are required (book tools are graphical in nature), and having different people write them is a very natural division of labor.

Vas

If tablebases can be used then it is not clear to me that engine is obviously no.

I can imagine that somebody write some function that is part of his engine that get a fen and return one of the following
1)win
2)draw
3)loss
4)do not know.

Practically tablebases do it but it can be extended to non tablebases positions that are draw or win by theory and it can be also more efficient then tablebases because of speed because if the code help to detect fast half of the tablebases positions correctly when in half of the cases the result is do not know then using the code before probing the tablebases may be practically faster.

Suppose the person release his code to decide win or draw or loss or do not know in similiar condition to the nalimov code.

Can people use his code?
If the reply is no then I see no reason that many people can use the nalimov tablebases.
If the reply is yes then the question is if it is not considered as an engine code.

Uri

There are some valid theoretical issues here. All we can really do right now is get some practical guidelines in place which suit the majority of programmers.

Vas

[Vasik Rajlich]

I would say EGTB code is an obvious 'no'. Especially if it is EGTB code that is not in the public domain, or that could not be used for everyone because of license requirements.

I would tend to agree on that. The current ICGA rule here is obviously a nod to the commercial entrants, for whom it would be annoying to redo the work for all the engines they sell, and whose can profit from sharing improvements and code in between.

But it's grossly unfair to someone starting out. The Nalimov code is not free. Just getting the 6-men is impossible for many people. Using .ctg books gives you the advantage of using the heavily tested ChessBase book selection, learning and editors, which ensure that you won't run into bugs with your book code.

Allowing shared book code is actually the democratic choice, anyone can use it.

If book code were treated like engine code, then our team would get permission from Convekta or ChessBase to use (exclusively) their book tools, leaving non-commercial teams at a disadvantage.

Vas

[Vasik Rajlich]

In practice, we're going to need to allow opening book and EGTB code. Most engine authors have been operating on the assumption that this is allowed and only a tournament with incredible rewards could entice them to write their own book code.

Wouldn't being able to win the World Championship be an incredible enough award?

Gian-Carlo,

this may vary from person to person, but I can't imagine myself writing a separate book tool just to play in a tournament. This tool would have very little value for users.

Say Nalimov EGTB are no longer accessible to you as result of a rule change. You have the option accept that they don't gain you enough to make them worthwhile.

If you take that option, you can obviously do without EGTB.

That's an easy choice.

But if you do take the option, then you're admitting your engines strength is significantly determined by code written by someone else, and that is not freely available to anyone.

Is that fair? I don't think so...

Tournaments are not a programming contest. Our team has Lukas with his hardware, Jeroen with his opening book, etc.

Vas

[Vasik Rajlich]

I do not see why one should request that an engine has its own book management routines : crafty or thinker have their own ones, but glaurung or rybka have not.

This is incorrect. Glaurung does have its own opening book code. I have just chosen to put it in the GUI part of my program rather than in the engine.

By the way, I agree with those who think it shouldn't be allowed to use somebody else's opening book or tablebase code in official tournaments. I don't buy Bob's argument that EGTBs are different because the results are completely static: How fast you can look up the results is just as important as the results themselves. The compression and caching schemes, which are very non-trivial to implement, have a huge impact on performance.

I wish people would stop making silly points about whether the GUI should be allowed to pick book moves, though. It obviously doesn't matter at all. The only thing that matters is where the book code comes from, not in what executable it is located.
Tord

My point exactly.

Those that do not involve chess logic (UI, server protocol) can be from anywhere.

Anything that is involved in move selection should be your own code. Where that code resides does not matter.

That should cover the EGTB code. It may be deterministic, but its effect is not equal. The more innovative developers will extract better performance in probing the tables.

If you think about it, even move generation is deterministic. There will always be the same set of legal moves from a given position. And yet, we all find ways of generating them differently. Rebel generates all moves at once. Crafty generates them on "as needed" basis.

This is not a very clear line.

For example:

1) Can I use a commercial chess GUI offline during the development of my program?

2) If I write a chess GUI which allows me to do things like visualize bitboard arrays, step through move sequences and search trees, etc - can I share this GUI with other programmers?

3) What if the above GUI writes some code? (For example, writes some basic mask arrays like 'knight_moves [64]'.)

4) What if the above GUI writes out the entire Rybka code?

There is just a fuzzy line between tools and the engine itself.

Vas

[Vasik Rajlich]

I propose a hybrid.

The tournament would be online (ICC), but the participants would meet locally.

For example, Bob and others could congregate at UAB (this has been done in the previous ACCL). Dann, Kerwin and me would meet at UW or somewhere in Redmond.

This way, travel cost and travel time is really minimized, while at the same time, you get the eye ball experience of the traditional (read archaic) WCCC.

That could work with a few gatherings in different places. However I would not want to play on any server that stops me using a .ctg book easily. I am happy to use an alternative book for tournaments like CCT but our tournament book is maintained in .ctg format and for the World Championship we would want to use this.

This is the primary reason I have maintained that the GUI should _not_ be handling the book facilities. That should be code inside the engine. Then the GUI one uses has nothing to do with playing the game, choosing book moves, and just serves as a user interface, which is where the "UI" in "GUI" comes from. I also strongly believe that an opening book is every bit as unique and important as the chess engine itself, which means one copy of any author's book is allowed in an event, not the multiple copies we have seen in the past.

For the question about EGTBs I don't care. That is static data everyone has access to, how / when you probe them is an internal engine issue anyway so I could care less about what is used there.

Just to clear, we are not really talking about not allowing the GUI to pick the moves (in most cases, opening moves). In the Thinker case, I also wrote the GUI.

I think what we should be saying is that the participating computer player should not pick moves using code that is written by somebody else. It does not matter whether that code is in the GUI or external DLL or main engine. If you did not write the code, it should not be allowed to decide moves for you.

Here some examples of acceptable systems:

1. UI and engine from the same author
a. The Shredder UI connets to the server.
b. The Shredder UI picks the book moves.
c. The Shredder UI asks the Shredder engine to pick a move.

2. UI from one author, and engine from another author
a. The Winboard UI connets to the server.
b. The Winboard UI asks the Crafty engine to pick moves.
c. The Crafty engine book code picks book moves.
d. The Crafty engine code picks moves using search algorithm.

Here are some examples of non-acceptable systems:

1. UI and engine from the same author, but book code from another author
a. The Fritz UI connets to the server.
b. The Fritz UI asks the Fritz engine to pick a move.
c. The Fritz engine asks Polyglot to pick a book move
d. The Fritz engine use a search algorithm to pick non-book moves.

2. UI from one author, and engine from another author
a. The Fritz UI connets to the server
b. The Fritz UI picks book moves.
c. The Fritz UI asks the Crafty engine to pick a move.

Correct. We often diverge into where the dividing line should be between the GUI and the engine. If you write both, you should decide what goes where. My issue is with a GUI that is used by many. In this case, it should be a UI, and only a UI. Not select book moves. Not deal with learning. Nor with EGTBs. etc...

That's primarily an issue with the commercial guys as they share UIs here and there, and in past WCCC events they shared books which is beyond unreasonable IMHO. Xboard is a perfect example of what a GUI should be. It just relays moves back and forth between the engine and the opponent, and otherwise stays out of the way of how the game is actually played.

In practice, we're going to need to allow opening book and EGTB code. Most engine authors have been operating on the assumption that this is allowed and only a tournament with incredible rewards could entice them to write their own book code.

As far as the theoretical aspect - you could argue this a number of ways. The way to phrase the question is: under what conditions can code written by one person be used by multiple teams in the same tournament?

Compiler/IDE: Obviously yes.
Engine: Obviously no.
Book editing tool: On the border. Like the compiler/IDE, it is (mostly) an offline process. Like the engine, chess-specific logic is involved.

If we could go back several decades and re-design the rules from the ground up, I would still push for allowing teams to share opening book editing tools, for practical reasons. The book tools are separate from the engine - the code base is different, different programming skills are required (book tools are graphical in nature), and having different people write them is a very natural division of labor.

Vas

I don't have a problem with any sort of "tool". I only care about two things:

(1) the opening moves and the code to the program uses to choose them, if this is not purely random. I've put a significant amount of work into the various components of choosing a book move. Probability of play, winning percentage, learning, and also allowing human "suggestions".

(2) The book itself. A good book author can spend months cooking up prepared lines for a particular program. That's fine. But don't give that to a group of programs to use in the same event, as has been done more than once in the past.

In my view the opening book itself (as opposed to opening book editing tools) should be treated like the engine code.

Vas

[Vasik Rajlich]

Again, the issue is this: If the GUI "picks" the moves, it is playing chess. If several different programs run on the same GUI, they are sharing a significant piece of code that can often be responsible for playing more moves in a game than the engine plays. This has happened several times, where we had GUI-A, BOOK-A, program-A GUI-A, BOOK-A, program-B, etc. I consider that unreasonable.

I don't mind the same GUI if it is not playing chess. If it chooses moves, then just one copy of GUI-A should be allowed in a single tournament. Xboard is a good example of what a real "GUI" is. If you add a book selection to a GUI, it is no longer a GUI (check definition of "interface" as opposed to "chess playing entity".)

I am not sure where this fixation on GUIs comes from, but it's beginning to get on my nerves. Everything you write above is technically correct, but talking about GUIs all the time is beside the point, and only serves to confuse matters and cast unnecessary suspicion over those of us who prefer to let the GUI handle the book moves. As I have said many times before, the thing that matters is who wrote the book code, not in which executable the book code is found.

We keep getting into this discussion again and again, but I never seem to be able to get the point across. Is it really so hard to write "it should not be allowed for multiple programs to use the same opening book code" without using the word "GUI"?

Whatever else one might say, there can be little question that from a design standpoint, it's bad and wrong. A user interface is for interface, not for picking chess moves.

It's a pure design discussion, and has nothing to do with tournament rules. Personally I want to keep my engine as simple as possible: It should do nothing more than searching and evaluating. It's written in an extremely low-level programming language, and because I suck at low-level programming, I don't see any need to suffer and spend time doing anything there that doesn't benefit from extreme speed.

Tord

With all due respect, the project is about a chess playing engine. If the engine can't play openings, then I suppose there is some solace to be found in that fact that it makes it a much simpler program. But since you've now gone to the trouble of creating a separate openings program, the sum of the two parts would seem to have negated all the solace. Now you have two programs, neither of which can excel at a complete game of chess on its own, and the latter cobbled with unrelated graphical interface functions, which does no small amount of violence to basic design principle.

Should we then wonder that a poor concept of design would result in the evils now seen in competition? If everyone were producing chess engines that could excel at a complete game of chess, we wouldn't be having this discussion.

However, I agree there should be no objection to your entering this agglomeration into competition, since you created all of it yourself.

Tord is right - book editing tools are fundamentally graphical in nature and belong to the GUI. Anyway, this has nothing to do with tournament rules.

Vas