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

[Gian-Carlo Pascutto]

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

What happens when you get out of the area where priorities are encoded, and into the general PGN book? Then it's no longer your code, but the code of Lex Loep that is playing[1]. That is the problem...

[1] And in some versions of ChessPartner, it's Lex's code and a set of algorithms I designed around the time we sent Deep Sjeng 1.0 to SSDF

[Nick C]

I agree it's a good idea and should be at least stated up front that no two entrants can use the same book

However, mandating this only works in practice if the book you use is a private one, in which case you are assured that no-one else is using your book by definition.

If there is a publically (commercially or otherwise) available book (say HIARCS12.ctg) there is nothing to stop someone "removing" (perhaps through using the book to play games and saving the games) the lines from it and putting them into their own book. Not only can they do that with with HIARCS12.ctg they can also do it with Rybka3.ctg Shredder11.bkt etc to make an uber-book. Books in the public domain are subject to book attackss, so you can end up with a book that can defeat any commercially available book. This is why the top book authors come out with new releases as their lines are refuted.

So if you have all of the lines of HIARCS12.ctg in your book does that mean you are playing with HIARCS12.ctg? No, but it could seem like it.

[Rolf]

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.

Did anyone of the mods see this ironical attack? Shouldnt be allowed IMO. The whole undertone doesnt please me.

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!

[Harvey Williamson]

Next thing we know we need to have a hardware limit because the commercial teams can afford more.!

Now that Sjeng is commercial I am sure you are aware of the 'fortune' that is earned from selling an engine. We also have to pay more to enter WCCC as I am sure you know as you now have to pay the higher rate.

[bob]

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.

Did anyone of the mods see this ironical attack? Shouldnt be allowed IMO. The whole undertone doesnt please me.

Please go away. You have nothing to offer in this discussion, and there is absolutely no "ironical attack" here at all. Look up the word "analogy" and you will follow his comment.

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!

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

#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

I'm neutral on that. I've not used 'em for several events now. If you don't have fast disks, you can actually hurt overall strength, which is what convinced me to only use them on my office box which has impossibly fast drives. 6 x 15K SCSI configured as raid-0 to do parallel read/writes.

[bob]

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

Right. And we have asked the ICGA to do that several times, but they can't seem to do so. But they can always come up with a major hardware rule at the last minute, for no good reason at all...

[bob]

I agree it's a good idea and should be at least stated up front that no two entrants can use the same book

However, mandating this only works in practice if the book you use is a private one, in which case you are assured that no-one else is using your book by definition.

If there is a publically (commercially or otherwise) available book (say HIARCS12.ctg) there is nothing to stop someone "removing" (perhaps through using the book to play games and saving the games) the lines from it and putting them into their own book. Not only can they do that with with HIARCS12.ctg they can also do it with Rybka3.ctg Shredder11.bkt etc to make an uber-book. Books in the public domain are subject to book attackss, so you can end up with a book that can defeat any commercially available book. This is why the top book authors come out with new releases as their lines are refuted.

So if you have all of the lines of HIARCS12.ctg in your book does that mean you are playing with HIARCS12.ctg? No, but it could seem like it.

I'm not so concerned about that. I am more interested in the case where a professional book author spends months hand-tuning a book, particularly using potential opponents for tuning, and then lets multiple programs use that same book. The "public" books are not the problem...

[Nick C]

I'm not so concerned about that. I am more interested in the case where a professional book author spends months hand-tuning a book, particularly using potential opponents for tuning, and then lets multiple programs use that same book. The "public" books are not the problem...

Well here is an example. Probably the most professional book author around (Jeroen) has just released a book that he spent months hand tuning. Perhaps he used potential opponents to hand tune this book, I don't know how Jeroen makes his books but it's possible. He cannot stop multiple multiple programs from using that book, it's out there in the public domain. I don't know the statistics, but I would bet that draws are far more likely if two competitors are using the same book, because a good book maker is unlikely to put lines in the book without a refutation for the other side.

One could limit the book in some way, to perhaps 10 moves or so (I know that the testing groups do something similar already). There are at least two downsides to placing limits on the book:

1/ It's much less fun (for me anyway), we don't get to see some exciting cooked line (cooked by someone probably using Rybka)

2/ The dominant engine (currently Rybka) will have an even bigger advantage over the competition, because it is less likely to get caught in a book trap if the book is only 10 moves deep

The benefit of limiting the book of course is that the engine gets to play more of its own moves.

[bob]

I'm not so concerned about that. I am more interested in the case where a professional book author spends months hand-tuning a book, particularly using potential opponents for tuning, and then lets multiple programs use that same book. The "public" books are not the problem...

Well here is an example. Probably the most professional book author around (Jeroen) has just released a book that he spent months hand tuning. Perhaps he used potential opponents to hand tune this book, I don't know how Jeroen makes his books but it's possible. He cannot stop multiple multiple programs from using that book, it's out there in the public domain. I don't know the statistics, but I would bet that draws are far more likely if two competitors are using the same book, because a good book maker is unlikely to put lines in the book without a refutation for the other side.

One could limit the book in some way, to perhaps 10 moves or so (I know that the testing groups do something similar already). There are at least two downsides to placing limits on the book:

1/ It's much less fun (for me anyway), we don't get to see some exciting cooked line (cooked by someone probably using Rybka)

2/ The dominant engine (currently Rybka) will have an even bigger advantage over the competition, because it is less likely to get caught in a book trap if the book is only 10 moves deep

The benefit of limiting the book of course is that the engine gets to play more of its own moves.

As long as it is public, I am not concerned. I am concerned about the "private books" that have book lines explicitly included for multiple potential tournament opponents. years ago a program reached a position where the opponent resigned, and _every_ move had come from book, having been pre-planned by the opponent by playing against the most recent commercial version of that program. That's fine for a single team to use. Book-cooking has been a common theme in computer chess events since the 1970's. But it isn't fine for that book author to create a private (aka tournament) book that a few selected commercial programs (or even a private program as far as that goes) get to use... it represents a lot of work and is a huge help to the engine. It should only be a big help for one engine...

I play all of my test games sans books to eliminate that factor. Whether we want to go to random starting positions is an interesting question as that would stop all of this in its tracks. It would be nice to eliminate the random factors from influencing the games, and concentrate on the engines. Pick a single position, give it to everyone, and each side plays it with black and then white. No book allowed. But that is not quite "chess" as we know it today. But I'd be more than willing to try it...