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

[bob]

Here's how it should be done:

1) Every engine outputs a real time series of status reports in some standard format. The format and frequency are chosen to limit the output bandwidth average requirement to some reasonable figure, say 100 Bps.

2) The reports are also issued by the engine immediately after it receives a move (or a game start) and immediately before it sends a move.

3) The reports, digitally signed, are sent via SSL to a central server for logging.

4) The reports are sent to a web server for conversion into pages that can be served and updated in real time.

5) The GUI/server interface does not involve itself with move selection.

That's not half bad in fact. I'm more than willing to ship "stuff" to a remote machine. I'd probably use a second machine to do the "sending" and have it effectively do something like tail -f logfile | sending_program so that it would not cause any load on the chess-playing box, but that would be absolutely trivial to do and would work just fine...

[michiguel]

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, and the same should apply for EGTB's.
Probing code written by one author (e.g. Nalimov), should be used by only one engine. But this will never happen.

Miguel

[Dirt]

Correct, and the same should apply for EGTB's.
Probing code written by one author (e.g. Nalimov), should be used by only one engine. But this will never happen.

Especially since some (many) authors are allowed to use the Nalimov code, and some aren't.

[bob]

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, and the same should apply for EGTB's.
Probing code written by one author (e.g. Nalimov), should be used by only one engine. But this will never happen.

Miguel

I don't see why that is a problem. EGTBs are static data. The probe mechanism is therefore fixed and the results are pre-determined. How you use that information is up to you. A book is entirely different. They do not have the same static data, much of it is carefully hand-crafted by excellent "book cookers" that spend long hours laying traps for others to walk into. And that has an effect on the outcome of the game that is different for each possible book. So one program, one book. But EGTBs just don't fit that category any more than specifying that no more than one program can use magic bitboard generation, or rotated bitboard generation, or 0x88, etc. Things that are "static" are OK to share IMHO. Things that are not static ought to be private to a specific engine.

[bob]

Correct, and the same should apply for EGTB's.
Probing code written by one author (e.g. Nalimov), should be used by only one engine. But this will never happen.

Especially since some (many) authors are allowed to use the Nalimov code, and some aren't.

There are even other alternatives. The Thompson endgame tables are free to all to use. Steven Edwards released EGTBs in his uncompressed format along with code anyone can use. I consider them all equal in that they all provide exactly the same information given the same position...

[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 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, and the same should apply for EGTB's.
Probing code written by one author (e.g. Nalimov), should be used by only one engine. But this will never happen.

Miguel

I suppose if you take your argument to the next logical level then anyone using a compiler not written by themselves is using someone elses code in the move decision.

As for tbs i guess not even Nalimov can use them as the decompression code used in the engine was written by someone else - Andrew Kadatch

[michiguel]

Correct, and the same should apply for EGTB's.
Probing code written by one author (e.g. Nalimov), should be used by only one engine. But this will never happen.

Especially since some (many) authors are allowed to use the Nalimov code, and some aren't.

There are even other alternatives. The Thompson endgame tables are free to all to use. Steven Edwards released EGTBs in his uncompressed format along with code anyone can use. I consider them all equal in that they all provide exactly the same information given the same position...

Just for the record, IIRC, the information is not the same at all.
Thompson's are distance to conversion, and Nalimov's are distance to mate.

Miguel

[michiguel]

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, and the same should apply for EGTB's.
Probing code written by one author (e.g. Nalimov), should be used by only one engine. But this will never happen.

Miguel

I suppose if you take your argument to the next logical level then anyone using a compiler not written by themselves is using someone elses code in the move decision.

At least the compiler I use, do not leave in my code specific algorithms for playing chess. Don't you think is that a good line to draw?

As for tbs i guess not even Nalimov can use them as the decompression code used in the engine was written by someone else - Andrew Kadatch

That is not a problem, unless Kadatch has another engine registered in the tournament.

Miguel

[bob]

Correct, and the same should apply for EGTB's.
Probing code written by one author (e.g. Nalimov), should be used by only one engine. But this will never happen.

Especially since some (many) authors are allowed to use the Nalimov code, and some aren't.

There are even other alternatives. The Thompson endgame tables are free to all to use. Steven Edwards released EGTBs in his uncompressed format along with code anyone can use. I consider them all equal in that they all provide exactly the same information given the same position...

Just for the record, IIRC, the information is not the same at all.
Thompson's are distance to conversion, and Nalimov's are distance to mate.

Miguel

Same idea. And you can use one instead of the other with no ill effects. In fact, the Thompson is even preferable for the 50-move draw cases it can help solve. The Edwards format is DTM. The point being that there are several alternatives that make this usable for anyone.

[Marc Lacrosse]

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 ?

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

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