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

[Marc Lacrosse]

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.

But I never suggested to use the same book for several engines. The most interesting part of book-making is precisely to build a book specifically tailored taking into account a given engine's strengths and weaknesses.
I do not think that something like the absolute best book giving decisive advantage to any engine against any opponent does exist.

But I just do not see why a common book format could not be used by different engines. At the extreme, it's just a standard as PGN is one for recording games : PG book format just associates positions, moves from these positions and desired relative frequencies of the moves.

Why should we forbid different engines of sharing this same format ?

As for the book content, this is another story : if a WCCC contender plays with any publicly available book he will suffer many a book loss from specifically prepared opponents. So I just can't see why someone would do this.

Then there is the problem of bookers who offer the same and similar services for different engines. I do not like it but this is completely independent of the book format.

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

I agree for the learning process.
This is relevant for ctg books (there is a book learning mechanism built into the GUI for automated tuning of books) but not for polyglot ones : there is no known public code for automated improvement of a PG book once it has been built.

Format is irrelevant. Content is critical.

So if no content is duplicated, you agree with use of the polyglot book format by several programs, I suppose...

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.

Once again : I do not know of any code shared among several engines and dealing with PG books optimisation.

Marc

[Gian-Carlo Pascutto]

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

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

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

I would have no problems (re)writing my own book logic and endgame databases for a World Championship. It would allow some more diversity and innovation in those areas.

Note that I don't see an issue towards sharing formats. Just against code. I think it's well possible to do an independent implementation of PolyGlot books. (For Nalimov EGTB, it looks way harder)

Likewise, for an automated tournament xboard is just a protocol translator. That doesn't have anything to do with chess. I'd be happy to use xboard. But if we're required to write our own interface, so be it. No problem for me.

You have to ask yourself what the World Champion should be:

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

OR

the strongest possible chess entity a team can field

[Gian-Carlo Pascutto]

We just have to accept that there are a bunch of things which can't be formalized. This includes how 'well-known' an author is, the exact things which have to be kibitzed and logged, etc.

In practice, we have had plenty of events (live and online) in the past and some common sense guidelines do seem to work.

Vas

I would agree that if you make clear in advance what the purpose of the logfiles and being well-known is, then it's up to every entrant to make sure that a reasonable tournament director will accept what they produce.

It's one of those things that's hard to formalize but tends to work fine in practice, because people who get themselves into trouble somewhat brought it upon themselves.

[Gian-Carlo Pascutto]

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.

You only want to play in a tournament where the judge of moves and time (the chess server) is controlled by a company which has a strong commercial interest in making sure that one of the programs they sell (like yours) wins, as well as getting the free publicity by organizing the event on the chess server of that company.

I'm so f*cking surprised!

[hgm]

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.

As I said, or me this is an obvious 'no'. I see absolutely no reason why that many people can use nalimov EGTB probing code. Using the tablebases itseld is quite a different issue, pertaining to use of shared (standardized) formats. I see no objections against the latter. As long as the use of the format is open to everyone, without any conditions. E.g. if it would be based on patented data-compression algorithm, it would not be accetable.

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

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

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

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

[Tord Romstad]

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

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

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

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

Tord

[Marc Lacrosse]

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

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

sorry for the mistake.

Marc

[CThinker]

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

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

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

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

My point exactly.

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

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

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

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

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