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

[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

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

Why go off on such a wild tangent. Such a function can't be written, so it is irrelevant whether or not everyone could use a thing that will never exist.

[bob]

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

I personally could not care less about whether EGTBs are allowed. I have never used them at a WCCC event, and I have not used them in 4-5 years in the CCT events...

They work fine on my office machine, U320 SCSI 15K rpm drives. On the more common sata/sata2/ide disks, they generally hurt more than they help unless you can get 'em all into RAM and keep 'em there. I've just decided that I'm not going to use them any more and I've never looked back...

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

Does the available access code operate as fast as the Nalimov code? For that matter, some Google searching failed to find either the tablebases or even the generation code for either of these. I know that Steve is around here, so that if someone is really interested he could ask, but this sounds about as equal to me as segregated schooling was.

Ken released everything so far as I recall. A set of CDs with his DTC tables, and the code necessary to probe them. Speed is somewhat subjective, but his code was as good as it gets, except that it did not do the on-the-fly decompression the Nalimov code does. That does hurt speed because you end up doing more I/O.

[bob]

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.

No argument from me there. I don't care about the format, I only care about sharing the "content" which has happened many times in the past...

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.

If someone wants to port my "learning" code into the polyglot stuff, I'd happily give them permission to do so. But we then reach the issue of learning code written by A used in program B, which I do not support at all. But for non-tournament use, the polyglot stuff could use my code with permission.

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

Yes. In fact, a single common book format would be a nice idea overall. We already have a common "disk format" we have to use (cylinders, heads and sectors).

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

Not knowing doesn't mean it hasn't happened. It is certainly possible. I could see A saying to others, ok you just played C and I have been paired with him for the next round, so can you give me your learning data for those games?

[bob]

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

Again, the issue is this: If the GUI "picks" the moves, it is playing chess. If several different programs run on the same GUI, they are sharing a significant piece of code that can often be responsible for playing more moves in a game than the engine plays. This has happened several times, where we had GUI-A, BOOK-A, program-A GUI-A, BOOK-A, program-B, etc. I consider that unreasonable.

I don't mind the same GUI if it is not playing chess. If it chooses moves, then just one copy of GUI-A should be allowed in a single tournament. Xboard is a good example of what a real "GUI" is. If you add a book selection to a GUI, it is no longer a GUI (check definition of "interface" as opposed to "chess playing entity".)

[bob]

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.

I've already stated that I've not used EGTBs in any WCCC event I have participated in, and I have also not used them in the last 4-5 years of online CCT/ACCA events. So it is not that important to me. But I do not follow your code about extracting more performance. I use the exact same egtb.cpp that everyone else uses. So it doesn't perform any better or worse for me than it does for anyone else. How I use it is up to me of course...

[rebel777]

IMHO the two main things are having many participants and providing live coverage of every single game. Everything else is secondary.

Vas

This sounds like the CCT. What could be done to elevate the CCT to the stature of the WCCC?

In my opinion, open hardware is also a must for a world title. Otherwise, the competition devolves into the old microcomputer championships. It also ignores chess as the drosophila of computer research, in this case massive cluster and multi-core computing.

Ian

The current ICGA limit is bad for some non-obvious reasons.

(1) saying "8 cores" is an arbitrary number. And all "cores" are not created equal. One could find 8 cores with a $100K liquid nitrogen cooling system that can be overclocked far more than a more affordable system. So all this does is to make the rich even more likely to win.

(2) it is going to escalate the book-cooking to new levels. The biggest problem with trying to cook books today is you have no idea what kind of hardware you should be testing against when you try to cook some lines for program X. Now that will not only be possible, it will be a given since the hardware is so restricted.

(3) One might get a vendor to give them access to a "next generation" 8-core box that could be 2x faster than anything commercially available. Another big advantage.

(4) One can hold a tournament with hardware that is far better than the WCCC, which makes the "WCCC" title meaningless, as it should mean "the best there is" while it won't mean anything near that.

The idea of restricting WCCC hardware was bad when Levy came up with it. It remains bad today. And it will remain bad for a long time. What is even more troubling is that he doesn't seem to be able to grasp this issue and deal with it at all. Whatever/whomever has convinced him this is a good idea has certainly pulled the wool over his head quite nicely...

Like to add another reason, the world championship is about the program that plays the best chess. And since limited hardware reduces the playing strength of a program it's unacceptable.

Ed

[Dirt]

I've already stated that I've not used EGTBs in any WCCC event I have participated in, and I have also not used them in the last 4-5 years of online CCT/ACCA events. So it is not that important to me. But I do not follow your code about extracting more performance. I use the exact same egtb.cpp that everyone else uses. So it doesn't perform any better or worse for me than it does for anyone else.

It doesn't perform at all for those who aren't allowed to use it.

If everyone is allowed to use the same EGTB access code the situation is fair, although whether this is desirable could be debated. When some are not, such as Vincent D., as I recall, it is not fair at all.

[sje]

I built my tablebases starting back in 1994 and released an ANSI C generator shortly thereafter. The generator and the data have been free for all to use from Day One.

All data is DTM/DTL, not DTC. Unlike some other formats, the one I use does not compress the data, so the indexing and retrieval is simple and very fast. While the file sizes are larger, disk storage is fairly inexpensive.

Two drawbacks:

1) Upper limit of five men in a class.
2) En passant is not supported.

[CThinker]

Like to add another reason, the world championship is about the program that plays the best chess. And since limited hardware reduces the playing strength of a program it's unacceptable.
Ed

There is a much longer thread on the subject of the 8-core limit.

We already have a much more extensive knowledge of equal hardware performance of engines, from CCRL, CEGT, etc. Rybka is the champion, by a very wide margin over Naum. Naum then itself has a big lead over the rest.

If you think about it, the WCCC now is not about the best chess playing system, but has turned into, the luckiest engine that could beat Rybka by preventing Rybka to use the advancements that it has brought to computer chess (cluster).

Instead of celebrating Rybka's advancements, it is being curtailed. Sad, really.

Now I can't wait for Bob's version of Crafty for clusters. The same for Naum. I hope to see a Naum for clusters soon. I'm not looking forward to WCCC to encourage the advancement of computer chess.