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

[Tord Romstad]

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

I am not sure where this fixation on GUIs comes from, but it's beginning to get on my nerves. Everything you write above is technically correct, but talking about GUIs all the time is beside the point, and only serves to confuse matters and cast unnecessary suspicion over those of us who prefer to let the GUI handle the book moves. As I have said many times before, the thing that matters is who wrote the book code, not in which executable the book code is found.

We keep getting into this discussion again and again, but I never seem to be able to get the point across. Is it really so hard to write "it should not be allowed for multiple programs to use the same opening book code" without using the word "GUI"?

Tord

[Dann Corbit]

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.

I guess we will have to look to other tournaments for that.

[mhull]

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

I am not sure where this fixation on GUIs comes from, but it's beginning to get on my nerves. Everything you write above is technically correct, but talking about GUIs all the time is beside the point, and only serves to confuse matters and cast unnecessary suspicion over those of us who prefer to let the GUI handle the book moves. As I have said many times before, the thing that matters is who wrote the book code, not in which executable the book code is found.

We keep getting into this discussion again and again, but I never seem to be able to get the point across. Is it really so hard to write "it should not be allowed for multiple programs to use the same opening book code" without using the word "GUI"?

Tord

Whatever else one might say, there can be little question that from a design standpoint, it's bad and wrong. A user interface is for interface, not for picking chess moves.

[Tord Romstad]

We keep getting into this discussion again and again, but I never seem to be able to get the point across. Is it really so hard to write "it should not be allowed for multiple programs to use the same opening book code" without using the word "GUI"?

Whatever else one might say, there can be little question that from a design standpoint, it's bad and wrong. A user interface is for interface, not for picking chess moves.

It's a pure design discussion, and has nothing to do with tournament rules. Personally I want to keep my engine as simple as possible: It should do nothing more than searching and evaluating. It's written in an extremely low-level programming language, and because I suck at low-level programming, I don't see any need to suffer and spend time doing anything there that doesn't benefit from extreme speed.

Another factor is that users prefer it this way. They often use the GUI part of my chess programs with other chess engines, and like to be able to use my book with these engines (which is fine, because they are just playing for fun, and not in a world championship). In other words, letting the GUI handle the book moves makes life less painful for myself and simultaneously makes the users happier. I couldn't care less whether someone thinks it is "bad and wrong from a design standpoint".

Tord

[mhull]

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

I am not sure where this fixation on GUIs comes from, but it's beginning to get on my nerves. Everything you write above is technically correct, but talking about GUIs all the time is beside the point, and only serves to confuse matters and cast unnecessary suspicion over those of us who prefer to let the GUI handle the book moves. As I have said many times before, the thing that matters is who wrote the book code, not in which executable the book code is found.

We keep getting into this discussion again and again, but I never seem to be able to get the point across. Is it really so hard to write "it should not be allowed for multiple programs to use the same opening book code" without using the word "GUI"?

Whatever else one might say, there can be little question that from a design standpoint, it's bad and wrong. A user interface is for interface, not for picking chess moves.

It's a pure design discussion, and has nothing to do with tournament rules. Personally I want to keep my engine as simple as possible: It should do nothing more than searching and evaluating. It's written in an extremely low-level programming language, and because I suck at low-level programming, I don't see any need to suffer and spend time doing anything there that doesn't benefit from extreme speed.

Tord

With all due respect, the project is about a chess playing engine. If the engine can't play openings, then I suppose there is some solace to be found in that fact that it makes it a much simpler program. But since you've now gone to the trouble of creating a separate openings program, the sum of the two parts would seem to have negated all the solace. Now you have two programs, neither of which can excel at a complete game of chess on its own, and the latter cobbled with unrelated graphical interface functions, which does no small amount of violence to basic design principle.

Should we then wonder that a poor concept of design would result in the evils now seen in competition? If everyone were producing chess engines that could excel at a complete game of chess, we wouldn't be having this discussion.

However, I agree there should be no objection to your entering this agglomeration into competition, since you created all of it yourself.

[Tord Romstad]

This is my last post in this particular sub-thread, because it no longer has anything to do with the thread. If you or someone else wants to continue the discussion, please start a new thread.

With all due respect, the project is about a chess playing engine.

Which project? My project is not. I'm writing a chess program, not just a chess engine.

If the engine can't play openings, then I suppose there is some solace to be found in that fact that it makes it a much simpler program.

It doesn't even play chess. It was never meant to. It just searches and evaluates positions. The engine consists of those parts of my program that need to be fast, and nothing more.

But since you've now gone to the trouble of creating a separate openings program, the sum of the two parts would seem to have negated all the solace. Now you have two programs, neither of which can excel at a complete game of chess on its own,

No, but they play a decent complete game of chess together, and because most of all users are completely unaware of the fact that they are not a single executable, and most of those who are aware of the fact appreciate the benefits it gives them, I don't see why I should care.

and the latter cobbled with unrelated graphical interface functions, which does no small amount of violence to basic design principle.

Should we then wonder that a poor concept of design would result in the evils now seen in competition? If everyone were producing chess engines that could excel at a complete game of chess, we wouldn't be having this discussion.

We also wouldn't have had nearly as many programs. For many of us, like myself, it's just too hard. I can just barely write a working search and evaluation function in a low-level programming language. I'm nowhere near good enough to write a complete chess program that way. What you are saying is basically that people like me shouldn't be doing chess programming at all, but leave it to wizards like Bob.

Tord

[Uri Blass]

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.

I disagree and I think that it is only a question of programming.

If people want to start they can start by simple tablebases.
You can get easily 100% correct for 3 pieces except KPK and for KPK you also can get easily rules that are always correct that catch the majority of the cases.(KQK or KRK is simply winning for the stronger side unless it is the weaker side to move and the weaker side is in stalemate or the weaker side can capture)

Next you continue with 4 pieces.
I believe that some endgames with big material advantage like KQQ vs K or KQR vs K or KRR vs K are also easy and the stronger side can always win unless the position is stalemate,

If I am wrong then it is easy to check it and prove it.

It is also probably easy to catch majority of the draws in KR vs KR by some simple rules.

You can try something that is not correct and use the exceptions to formalize something else that is correct.

the only reason not to draw in KR vs KR may be checkmate or winning the rook.

checkmate can happen only if the king is in the last rank or can be pushed to the last rank and the distance between the kings is small enough and in majority of the positions it is easy to see that it does not happen and capturing the rook can happen only by direct capture of the rook or by check that allow winning the rook(something like Ra8+ when the opponent rook is at h8 or h7 and in majority of the cases it is possible to see that the side not to move has rook in a square that it is impossible
to capture is by check(for example difference of at least 2 ranks and difference of at least 2 files from the relevant king or king that defends the rook when the opponent king does not attack the rook.

Of course you need to check no errors in the rules and I may have some mistake in what I say because it is possible that there are possibilities that I did not check but it is easy to check all the tablebases positions of KR vs KR to check for errors.

There are many cases and the program may be big if you want to have correct rules for half of the 3-6 tablebases positions but I see no reason to assume that it is impossible to write some function that get correct result in half of the tablebases(significantly faster than probing the tablebases) and get does not know result in another half.

Uri

[bob]

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.

I don't buy the "this hurts Rybka" idea, because the cluster rybka is a joke. And a poor joke at that. There have been some decent cluster-based programs. But Rybka is simply not one of them. Given that, there might be a reason that reducing total cores favors one engine over another, although I am not sure other than for the case of an engine that either doesn't have a parallel search, or which has a very inefficient one that loses ground against the good SMP searches as the number of processors increases.

Personally, I think this is a knee-jerk reaction to unknown forces that will eventually have to be exposed to the light of day which will embarrass someone.

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

I disagree and I think that it is only a question of programming.

The _only_ programming that will provide this information is an exhaustive search to terminal nodes that only end in mate or draw, from the given position. This is not going to happen for "all" cases. Ever...

If people want to start they can start by simple tablebases.
You can get easily 100% correct for 3 pieces except KPK and for KPK you also can get easily rules that are always correct that catch the majority of the cases.(KQK or KRK is simply winning for the stronger side unless it is the weaker side to move and the weaker side is in stalemate or the weaker side can capture)

Next you continue with 4 pieces.
I believe that some endgames with big material advantage like KQQ vs K or KQR vs K or KRR vs K are also easy and the stronger side can always win unless the position is stalemate,

If I am wrong then it is easy to check it and prove it.

Simple. Just provide some code that will characterize _all_ KRP vs KRP endings into "won, lost are drawn." That one is quite hard enough. Without worrying about KQRRPPP vs KQRRPPP and other impossible positions.

It is also probably easy to catch majority of the draws in KR vs KR by some simple rules.

You can try something that is not correct and use the exceptions to formalize something else that is correct.

the only reason not to draw in KR vs KR may be checkmate or winning the rook.

checkmate can happen only if the king is in the last rank or can be pushed to the last rank and the distance between the kings is small enough and in majority of the positions it is easy to see that it does not happen and capturing the rook can happen only by direct capture of the rook or by check that allow winning the rook(something like Ra8+ when the opponent rook is at h8 or h7 and in majority of the cases it is possible to see that the side not to move has rook in a square that it is impossible
to capture is by check(for example difference of at least 2 ranks and difference of at least 2 files from the relevant king or king that defends the rook when the opponent king does not attack the rook.

Of course you need to check no errors in the rules and I may have some mistake in what I say because it is possible that there are possibilities that I did not check but it is easy to check all the tablebases positions of KR vs KR to check for errors.

There are many cases and the program may be big if you want to have correct rules for half of the 3-6 tablebases positions but I see no reason to assume that it is impossible to write some function that get correct result in half of the tablebases(significantly faster than probing the tablebases) and get does not know result in another half.

Uri

[bob]

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.

"hoist on your own petard" comes to mind. Vincent called Eugene an idiot many times here. And then thinks he will return the "favor" by saying "certainly you can feel free to use my code." ???



One always ends up having to sleep in the bed they choose to lie down in...

I believe the actual terminology was "that fucking idiot Nalimov..." although I don't remember the context today...