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

[CRoberson]

We need to be more detailed on this GUI/Book issue.

Last year I put in a rule for WCRCC that no two participants can
use the same book. The rule specifically is concerned about
data content.

Here is an example:
I use ChessPartner 6.0 for interfacing Telepath in UCI mode
to ICC. Also, ChessPartner has opening book tools: book creation
tools, book editing tools and can handle book moves for the engine.

I grabbed some pgn files that I collected over the last 14 years and
some that I created myself and created a book with those pgns via
the ChessPartner book creation tool. Then I went through the book
establishing priorities with its graphical book editing tool. Now,
the book playing code will make book moves based on both the
data and the priorities that I encoded into the book.

If somebody else uses ChessPartner and its book facilities, it is
very unlikely that they have created the same book as I have. My
priorities are my own and some of the pgns were created by me from
reviewing my library of printed books on openings.

So, here would be the formal description of the situation:
Charles uses CP 6.0 + Charles' book (made via CP 6) + Telepath

Somebody else uses CP6.0 + some book (surely content different from Charles' book) + engineB.

Now, where is the problem with that? We don't use the same book.
The ChessPartner book moving code will surely pick different moves for engineB
than for Telepath. ChessPartner's code for making a book move
is a slave to the content of the books (the pgn data and the human
encoded priorities).

[CThinker]

a piece of Windows UCI Fruit-derived engine code that sits in between a ChessBase book and GUI, the Nalimov EGTB, and extracts the fastest chess from an 8 core machine

And even more interesting, is that, the Fruit-derived engine may not even get executed in the tournament.

Consider the case where two participants use the ChessBase UI and book, and the game was played and completed in its entirety just with moves from the book.

What then is the contribution of these so-called chess operators? ehm, "authors".

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

With one exception, I agree. That exception is "learning". Learning is non-trivial to implement, and doesn't belong in the GUI if others get to use it. My main concerns, expressed often, are:

(1) more than one program using the same book, is a no-no. Perhaps one could make a case for a "communal book" that anyone could use if they want to avoid dealing with the book issue at the moment. I'd go along with that, so long as _anyone_ could use if if they wanted. And so long as it really is generic and doesn't get into the "cooked opening" stuff to trap a specific program. And since this is so hard to detect and/or prove, the idea is probably doomed from the get-go.

(2) more than one program using the same book code could be OK, so long as _anyone_ is free to use that code. Then if the code includes learning, anyone can have learning if they want.

I liked things better when the GUI was really a "GUI" and nothing more. "GUI" is well-defined and doesn't include any chess-playing abilities of any kind...

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

With one exception, I agree. That exception is "learning". Learning is non-trivial to implement, and doesn't belong in the GUI if others get to use it. My main concerns, expressed often, are:

(1) more than one program using the same book, is a no-no. Perhaps one could make a case for a "communal book" that anyone could use if they want to avoid dealing with the book issue at the moment. I'd go along with that, so long as _anyone_ could use if if they wanted. And so long as it really is generic and doesn't get into the "cooked opening" stuff to trap a specific program. And since this is so hard to detect and/or prove, the idea is probably doomed from the get-go.

(2) more than one program using the same book code could be OK, so long as _anyone_ is free to use that code. Then if the code includes learning, anyone can have learning if they want.

You are making exceptions that nullify all your previous arguments. IMHO, none of those should be allowed. Code and books have authors and they should be recognized as such, no matter how spread and "communal" they are. If an author does not want to deal with the "book issue" as you say, he/she does not belong to WCCC for goodness sake.

I liked things better when the GUI was really a "GUI" and nothing more. "GUI" is well-defined and doesn't include any chess-playing abilities of any kind...

I think that you finished the post using the word GUI just to piss off Tord

Miguel

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

With one exception, I agree. That exception is "learning". Learning is non-trivial to implement, and doesn't belong in the GUI if others get to use it. My main concerns, expressed often, are:

(1) more than one program using the same book, is a no-no. Perhaps one could make a case for a "communal book" that anyone could use if they want to avoid dealing with the book issue at the moment. I'd go along with that, so long as _anyone_ could use if if they wanted. And so long as it really is generic and doesn't get into the "cooked opening" stuff to trap a specific program. And since this is so hard to detect and/or prove, the idea is probably doomed from the get-go.

(2) more than one program using the same book code could be OK, so long as _anyone_ is free to use that code. Then if the code includes learning, anyone can have learning if they want.

You are making exceptions that nullify all your previous arguments. IMHO, none of those should be allowed. Code and books have authors and they should be recognized as such, no matter how spread and "communal" they are. If an author does not want to deal with the "book issue" as you say, he/she does not belong to WCCC for goodness sake.

I liked things better when the GUI was really a "GUI" and nothing more. "GUI" is well-defined and doesn't include any chess-playing abilities of any kind...

I think that you finished the post using the word GUI just to piss off Tord

Miguel

No. And I see Tord's point of view. But the type of "GUI" being discussed here is a "GUI" that can be shared by others. In his i-phone case, I doubt he'd want his "GUI" to be used by others because it includes his engine as well.

For a private GUI I don't care what it does. We can argue about functionality forever, but the point still comes down to "if the GUI plays chess, then nobody should be able to use it in a tournament except for the actual author." I have personally witnessed games that were played (by one side) 100% out of the book. No engine thinking at all

But I am willing to accept the idea that many want to use someone else's GUI to avoid writing their own. I fit into this camp since I use xboard and don't want to write one for myself. I could. But why when xboard does exactly what I want and doesn't have a thing to do with the actual game.

I can see the point that someone might well not want to develop book code for the same reason. And while I don't particularly like the idea, I can live with that. But when the GUI becomes actively involved in the game, deciding which book moves can be played, handling book learning, making timing decisions (as in a UCI-based GUI) then suddenly the GUI is beginning to handle lots of bits and pieces of the actual game. And I'm willing to compromise quite a bit, with the major exception being the book itself, which has been a significant problem in past events...

I suppose one could say that there are things I don't want the GUI to use, if others can use it, there are things I don't believe the GUI should do at all, and there are some things I do not accept at all. I'd like to see a common GUI just be a user interface. And I simply do not accept the idea of a single book, with a single author, being used by multiple programs. Nor would I accept a single book author preparing opening books for several different programs, even if he says they are separate. He is a member of exactly one team, IMHO. All the other points can be debated, discussed, and whatever the majority wants I'll go along with. But not sharing the physical book, unless _everyone_ can share that book...

[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

With one exception, I agree. That exception is "learning". Learning is non-trivial to implement, and doesn't belong in the GUI if others get to use it. My main concerns, expressed often, are:

(1) more than one program using the same book, is a no-no. Perhaps one could make a case for a "communal book" that anyone could use if they want to avoid dealing with the book issue at the moment. I'd go along with that, so long as _anyone_ could use if if they wanted. And so long as it really is generic and doesn't get into the "cooked opening" stuff to trap a specific program. And since this is so hard to detect and/or prove, the idea is probably doomed from the get-go.

(2) more than one program using the same book code could be OK, so long as _anyone_ is free to use that code. Then if the code includes learning, anyone can have learning if they want.

I liked things better when the GUI was really a "GUI" and nothing more. "GUI" is well-defined and doesn't include any chess-playing abilities of any kind...

#2 is probably the right formulation. You certainly don't want a situation where some book code is available to exactly two teams (for example).

I'd still make an exception for EGTBs.

Vas

[Vasik Rajlich]

Last year I put in a rule for WCRCC that no two participants can
use the same book. The rule specifically is concerned about
data content.

In my view this is the right way to formulate it.

Vas

[Gian-Carlo Pascutto]

There is no benefit to the chess world in having me or anyone else roll his own EGTB implementation.

Vas

That's like saying Nalimov can't be improved upon. Think 6-men bitbases, for example.

[Gian-Carlo Pascutto]

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

I don't necessarily see that as a good thing. Allowing reusing Fruit code is 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

This seems logical to me, not something undesirable. Next thing we know we need to have a hardware limit because the commercial teams can afford more.

Oh wait, that's what got us here in the first place!

[Gian-Carlo Pascutto]

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.

I don't think you'd need to write a book tool (that code is not playing after all), but code that reads your book format and plays the correct moves from them. I think there are probably many uses for Rybka being able to use its book correctly no matter what the GUI.

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

I know. They're team contests. We can't have one person in multiple teams. I hope the reasons why don't have to be explained.