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

[michiguel]

why should you forbid the use of polyglot books by other engines ?

Marc

Because Fabien will be co-author of every single engine in the torunament.

Miguel

Complete nonsense.

Then only Tim Mann will be allowed to communicate through WB protocol and no one else than Stefan Meyer-Kahlen will be allowed to use the UCI protocol.

Marc

Similar answer than Lance's:

"The compiler does not make chess move decisions for me. On the contrary, my code makes the chess decisions. The compiler only translates my own chess code logic so that it can be executed by a machine. "

Xboard does not make chess move decisions for me.

Miguel

[CThinker]

This is what I will do then:
Moves 1 to 10, use BookThinker (my own move selection logic).
Moves 11 - 20, use Naum (someone else move selection logic).
Moves 21 - end of game, use Rybka (someone else move selection logic).

Excellent - then I will go to Pamplona and play under whatever rules the ICGA wants me to and win

I'm sure you will, because you have a compiler that knows chess logic. I am guessing that is where the strength of your engine comes from.

Vas does not have that kind of compiler. He has to actually make up his own chess logic in code. Vas will have a very hard time then.

Good luck.

Well Vas uses the same tb code as we do - and up till now uses the CB GUI and a ctg book in all major tournaments.

Now if we both used Jeroen Nooman that would be a little odd! In fact there are several engines who use books by the same author(with his permission) - Arturo Ochoa, in tournaments.

Thanks for your your Good Luck wishes - we will need them.

Best Wishes,
Harvey

Yup. Thanks for describing an example of a scenario in WCCC that I don't agree with and which I have been trying to describe.

As for luck, I think, with the exception of Rybka, everyone needs it. I'm actually hoping that Rybka would be unlucky this time, so that the tournament would be interesting and not like last year.

[bob]

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.

Hi Lance

I do not agree at all with you.

There is a 500 years old built knowledge regarding chess openings.
No engine can fight on its own against this.
I am ready to bet that thinker with a good book based on this knowledge would crush rybka 3 playing on its own from move one.

So it seems normal that an engine playing in a competition should be provided with some opening knowledge.

Moreover opening knowledge is not neutral.
There is a lot of skill needed to guess what are the openings lines from which a given engine has the best chance to achieve good results.

The way this knowledge is given to the engine is not important : this is only the basis on which the engine will begin to fight.

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.

If you feel that you are able to build better opening books based on your own code and heuristics, so be it. But if someone prefers to rely on a common book format with someone of his team building a tailored book for his engine within this format, where is the problem ?

The problem is two-fold:

(1) we have had cases in the past where multiple programs entered using the _same_ well-prepared book. At one point, Noomen was doing the book for Fritz, Tiger and Rebel I believe. Bruce (Moreland) raised the issue at that point with a question "Do we really have to face this same deadly book 3 times in the same tournament?" And it was a legitimate question.

(2) book learning and move selection algorithms are going to play a part in how the "system" plays chess overall. Because the book is significant, and then choosing moves from that book and learning about those moves is also significant.

My complaint is that I believe there is enough "chess playing skill" in some of the GUIs that there should only be allowed _one_ copy in a tournament. So one copy of the code that can, on occasion, actually play more moves than the engine (we have seen cases where a program is in book until the game is over, so the engine has no part at all there). One copy of the book. That's all most of us want to see limited... I don't think it reasonable that I spent a lot of time writing Crafty's book-learning code, and then others can get book learning for free just because of the GUI they choose to use. "learning" is a part of the "system" (the entity that plays the game)...

Why should one forbid an author to use a common known opening book format to build a specific book for his own engine ?

Format is irrelevant. Content is critical. And if the content is modified as the game progresses, based on information supplied by the engine, that is even worse if it is shared among several programs in the same event.

I really cannot understand your point here. this is as if you forbid authors to use a common format like WB or UCI to communicate with some GUI. Everyone should rely on his own code and format for everything?
Nonsense!

I feel in a good position to defend this : polyglot books design and creation functions have been designed by F Letouzey according to discussions that we had for the preparation of Fruit's participation at WCCC 2005.

Since then every aspects of polyglot books are open. why should you forbid the use of polyglot books by other engines ?

Marc

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

Quite clearly, the moves should be executed on a server. This is more fair, makes life a lot easier for everybody and results in automatic live coverage.

The big question is if physical attendance should be required or only encouraged. If it's required, I'm afraid that the tournament will be too small, especially if the programmer himself has to attend and can't send a substitute.

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 particular problem now has a solution. You can import your .ctg book into the Aquarium and use the UCI engine+book wrapper (which will be available shortly).

In general, in order to obtain the many benefits of having the moves automatically executed on a server, authors will need to make sure that their playing solutions are portable.

Vas

[Harvey Williamson]

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 particular problem now has a solution. You can import your .ctg book into the Aquarium and use the UCI engine+book wrapper (which will be available shortly).

In general, in order to obtain the many benefits of having the moves automatically executed on a server, authors will need to make sure that their playing solutions are portable.

Vas

The commercial UCI version of Hiarcs uses its own internal book in any GUI or even with no GUI and has done for years. If I can be 100% sure that, a ctg, when converted to Aquarium will play the moves I expect it to then this is a possible solution. Once imported to Aquarium can it be edited? Or would I need to reimport every time I want to make a change?

[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

[Vasik Rajlich]

If I can be 100% sure that, a ctg, when converted to Aquarium will play the moves I expect it to then this is a possible solution.

I've been told that this is the case. (Obviously, this point is ultra-important.) You should probably double-check with Convekta to avoid any surprises.

Once imported to Aquarium can it be edited? Or would I need to reimport every time I want to make a change?

You can import to Aquarium format and then edit that, or you can edit in .ctg format and keep re-importing.

What you can't do is export Aquarium format back to .ctg.

Vas

[hgm]

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.

[Uri Blass]

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