Repetition detection structure.

[hgm]

Sorry, but a computer playing in a FIDE event does have to shake hands with the opponent before the game starts. It is done by the human operator. The official rules have always been modified to allow computers to play, since computers obviously don't have hands to make moves or hit the clock, etc. USCF has computers using almost the same rules as those used by blind players, who can have an "assistant" that makes the move, hits the clock, and tells the player when a move has been made, etc...

But functional rules can be handled properly, things like draw offers and such...

So you did not notice we were discussing _automated_ engine-engine play here, and that the WinBoard_F adjudication features cannot even be activated in any other mode? And that CCRL rating tournaments and our other 'basement tourneys' that most of us use for testing our engines hardly qualify as FIDE events?

But it already seems progress that you now admit that some of the rules cannot be taken at face value, and have to be adapted when computers are replacing Humans as players. The additional requirement for a communication protocol happens to be one such necessary adaptation, that for computers has to replace the description of how to shake hands, touch and move pieces, press the clock, etc.

[bob]

If testers want to put a requirement on the engine in order to test it without wasting too much time, they should simply require it to implement the resign feature. Not abuse the score reported by that engine in a sneaky way for purposes it was not meant for.

For what it's worth, Arena adjudicated that game, not me. In fact I didn't even run the tournament, now that I look further.
There is nothing sneaky about our testing.

I don't think anybody is suggesting something sinister is going on, rather that something that is flawed is happening...

[bob]

Note that was apparantely a FIDE rule, which is OK by me. But if a program says "this is a draw" and it isn't, the game should continue unless the program refuses and loses on time.

Yes, it was a FIDE rule, and by that FIDE rule all computer programs would forfeit their game even before it would start, as they have no hands and do not greet their opponent in any alternative way. That just illustrates how silly it is to require that Human rules apply without any adaptation to computers.

Furthermore note that the engines under WinBoard_F (if the user sets this option) do not forfeit because they say "this is a draw", but because they say "I won't play on" in a position that is not won or drawn by any rule. And if they don't mean that, they'd just better not say it. This is also completely similar to Human Chess, where there is also no way back if you say "I resign", and later claim that you meant something else... Even if you think this is undesirable (which I don't), in practice there is simply no way to accomodate engines that substitute arbitry commands for arbitrary other commands, by having a GUI second-guess what they really mean. Because where would it stop? You might as well have the GUI say, when a program plays 1. a2a3 "Well, but this is such a poor move, it cannot possibly mean that. Let's assume it is just bad pronunciation, and that it means 1. e2e3"... If you don't stick to the protocol, the consequences are entirely for you. That is true if you number the board files differently, and it is true when you decide 'resign' means castling. So why should it be any different when you say "this game is definitely over" when you mean you want to play on?

Sorry, but a computer playing in a FIDE event does have to shake hands with the opponent before the game starts. It is done by the human operator. The official rules have always been modified to allow computers to play, since computers obviously don't have hands to make moves or hit the clock, etc. USCF has computers using almost the same rules as those used by blind players, who can have an "assistant" that makes the move, hits the clock, and tells the player when a move has been made, etc...

But functional rules can be handled properly, things like draw offers and such...

There is a reason to have different functional rules for computer and humans in few cases like draw claims(offering draws is no problem).
The reason is that there are mistakes that non buggy programs do not do.

A wrong draw claim for 50 move rule or for repetition is one of them.
Engines usually also agree about non sufficient material draw claims
(K vs K draw
KN vs K draw KB vs K draw KB vs KB draw when the bishops have the same color)

Most engines are not smart enough to make correct draw claims in practical different cases and if there is an author that his program is smart enough to do it then he may send his code when to claim draws to H.G.Muller and I guess that Muller is not going to have problems to use it in the adjudication.

I have also seen many "correct programs" blow things like KN vs KN, which is drawn almost 100% of the time, but not exactly 100%... So the natural approach would be to have a GUI that "does it right 100% of the time, or else it is not that useful. Who would ask a FIDE Arbiter to show up at a major tournament, if it was known that he only makes the right decision 99% of the time? (and no bad jokes about the ICCA doing just this either.)

The target of interface is to support engines of different strength but
not to support a small number of buggy engines at the price of spending computer time so the simplest solution is that engines that make wrong draw claim fix the bugs and claim draw correctly.

What would happen at a FIDE tournament if you claim a draw by repetition, and the TD/arbiter comes over and says "no, you made a mistake, en passant status changed so that one of the positions is not the same as the other two..."? The game would continue even though the "buggy human" made an error. I suppose there is nothing wrong with having an option to "kill a program if it does something even slightly improper", but, for example, in the kind of testing I do I would rather see the game played out. Particularly in cases where the only information we have is the often inaccurate evaluations they produce when doing a search.

If the interface decide to continue after wrong draw claim then the engine that did the wrong claim may often lose on time(because the author usually assume that the game is not going to continue after draw claim so he does not care how his engine behaves in that case) and you may lose computer time relative to the case that the interface adjudicates the game based on the wrong draw claim.


Finally I believe that H.G.Muller's code for winboard is free so you are free to fix it and release your winboard version if you do not like adjudicating games in case of draw claims

That's what we don't need. Multiple versions that behave differently. I am already having problems with this with the two different 22.0 versions of Crafty I released and am fixing to release a 22.1 just to get past that problem.

The previous situation of accepting wrong draw claims cannot be considered as better even from your point of view.

My point has always been here that programs should not be able to "force a result". If a program wants to claim a draw, and the claim is incorrect, either the game continues or that program loses. The current situation where a program can send a "result" to xboard and end the game is bad, because I had cases where one program (arasan 9/10) would get the result backward if they were playing black, and they would claim a result that was wrong. To solve this for my testing, my "GUI" only pays attention to crafty's claims...

Detecting wrong draw claims is the first step even from your point of view and you can add option to continue the game after a wrong draw claim.

I guess that most testers will prefer to use H.G.Muller's version and not your version if you do it but testers are free to do what they like.

Uri

The goal of any software engineering project should be to design _one_ program that addresses the task in general, rather than just a subset of the task while leaving the rest to others... that leads to the mess we have today with GUI incompatibilities, etc.

[gladius]

This is a very questionable statement. Uri selected 4 games for an independent reason (just because they were long, and contained a long sequence of reversible moves), and it turns out 2 of them were adjudicated wrong. That is 50%. I see no reasons why perpetuals would be more likely after a long sequence of reversible moves (if you adjudicate after 3-5 moves with the same score), so there is no reason why this 50% should not be representative of the total population of games.

And how much time would it really save you to terminate games that are truly won at +8? 10%?

If you really want to save time, you should adjudicate games draw after 40 reversible moves! (You can do this in WinBoard_F! ) It saves more time, and has a larger probability of being correct.

Those two games did not meet the 8 pawn criteria however, and I believe one of the games was even a user adjudication, which is obviously incorrect. The Joker/Garbochess game should have been a draw if the threshold was set to 8 pawns, although it does appear to be a won endgame (but Garbochess was not going to be finding that win).

Personally, I go with the default Arena adjudication, which is +9 pawns, and it does save quite a bit of time. I haven't seen a position where both engines evaluate as greater than +9 and is a draw. But I play my engine against engines of similar strength, so they usually are close to the same page on eval.

As for 40 reversible moves, that one is a bit tricky, as the pawn push forced by the 50 move rule can either turn a drawn position into a win or loss (and seems to quite frequently ).

[bob]

Sorry, but a computer playing in a FIDE event does have to shake hands with the opponent before the game starts. It is done by the human operator. The official rules have always been modified to allow computers to play, since computers obviously don't have hands to make moves or hit the clock, etc. USCF has computers using almost the same rules as those used by blind players, who can have an "assistant" that makes the move, hits the clock, and tells the player when a move has been made, etc...

But functional rules can be handled properly, things like draw offers and such...

So you did not notice we were discussing _automated_ engine-engine play here, and that the WinBoard_F adjudication features cannot even be activated in any other mode? And that CCRL rating tournaments and our other 'basement tourneys' that most of us use for testing our engines hardly qualify as FIDE events?

The problem is that I only recognize one type of chess game, one that does follow the FIDE rules. which has a precise protocol for how to offer/claim draws, repetitions, etc. Crafty has been explicitly tweaked to match every rule that is applicable. I have gotten a few wrong over the years, and have corrected them when someone pointed out the error...

But it already seems progress that you now admit that some of the rules cannot be taken at face value, and have to be adapted when computers are replacing Humans as players. The additional requirement for a communication protocol happens to be one such necessary adaptation, that for computers has to replace the description of how to shake hands, touch and move pieces, press the clock, etc.

I didn't exactly say that. I said that FIDE/USCF have already defined exceptions for computer games, some of which I have not agreed with. For example, FIDE/USCF allows the "operator" to offer/accept draws on behalf of the program, which I believe is wrong. This was done because until a few years ago, programs were unable to offer/accept draws, resign gracefully, etc... Doesn't make it right, but it was the way it was done. I don't want to have to support multiple different "rule-sets" for draws and such, just one compatible set of rules that everyone accepts and responds to in the same way.

[Uri Blass]

Note that was apparantely a FIDE rule, which is OK by me. But if a program says "this is a draw" and it isn't, the game should continue unless the program refuses and loses on time.

Yes, it was a FIDE rule, and by that FIDE rule all computer programs would forfeit their game even before it would start, as they have no hands and do not greet their opponent in any alternative way. That just illustrates how silly it is to require that Human rules apply without any adaptation to computers.

Furthermore note that the engines under WinBoard_F (if the user sets this option) do not forfeit because they say "this is a draw", but because they say "I won't play on" in a position that is not won or drawn by any rule. And if they don't mean that, they'd just better not say it. This is also completely similar to Human Chess, where there is also no way back if you say "I resign", and later claim that you meant something else... Even if you think this is undesirable (which I don't), in practice there is simply no way to accomodate engines that substitute arbitry commands for arbitrary other commands, by having a GUI second-guess what they really mean. Because where would it stop? You might as well have the GUI say, when a program plays 1. a2a3 "Well, but this is such a poor move, it cannot possibly mean that. Let's assume it is just bad pronunciation, and that it means 1. e2e3"... If you don't stick to the protocol, the consequences are entirely for you. That is true if you number the board files differently, and it is true when you decide 'resign' means castling. So why should it be any different when you say "this game is definitely over" when you mean you want to play on?

Sorry, but a computer playing in a FIDE event does have to shake hands with the opponent before the game starts. It is done by the human operator. The official rules have always been modified to allow computers to play, since computers obviously don't have hands to make moves or hit the clock, etc. USCF has computers using almost the same rules as those used by blind players, who can have an "assistant" that makes the move, hits the clock, and tells the player when a move has been made, etc...

But functional rules can be handled properly, things like draw offers and such...

There is a reason to have different functional rules for computer and humans in few cases like draw claims(offering draws is no problem).
The reason is that there are mistakes that non buggy programs do not do.

A wrong draw claim for 50 move rule or for repetition is one of them.
Engines usually also agree about non sufficient material draw claims
(K vs K draw
KN vs K draw KB vs K draw KB vs KB draw when the bishops have the same color)

Most engines are not smart enough to make correct draw claims in practical different cases and if there is an author that his program is smart enough to do it then he may send his code when to claim draws to H.G.Muller and I guess that Muller is not going to have problems to use it in the adjudication.

I have also seen many "correct programs" blow things like KN vs KN, which is drawn almost 100% of the time, but not exactly 100%... So the natural approach would be to have a GUI that "does it right 100% of the time, or else it is not that useful. Who would ask a FIDE Arbiter to show up at a major tournament, if it was known that he only makes the right decision 99% of the time? (and no bad jokes about the ICCA doing just this either.)

The target of interface is to support engines of different strength but
not to support a small number of buggy engines at the price of spending computer time so the simplest solution is that engines that make wrong draw claim fix the bugs and claim draw correctly.

What would happen at a FIDE tournament if you claim a draw by repetition, and the TD/arbiter comes over and says "no, you made a mistake, en passant status changed so that one of the positions is not the same as the other two..."? The game would continue even though the "buggy human" made an error. I suppose there is nothing wrong with having an option to "kill a program if it does something even slightly improper", but, for example, in the kind of testing I do I would rather see the game played out. Particularly in cases where the only information we have is the often inaccurate evaluations they produce when doing a search.

There is a difference between games between humans and games between chess programs.

You cannot be sure that humans will never make an error by wrong repetition claim.

You can be sure that chess program will never do error assuming there is no bug.

This is the reason that the winboard protocol has an option to claim a draw that means claiming a draw and refusing to continue the game.

If you want an option to claim a draw when you agree to continue in case that the claim is rejected then the only solution is to have another command that means it.

I guess H.G.Muller and other people are going to have no objection if you change the winboard of H.G.Muller and add another command that means claiming a draw and continue in case that the claim is rejected by the interface.

I guess that most programmers are not going to use it because they do not expect their program to claim wrong draw but there is no problem if you plan to use it.

Uri

[hgm]

The problem is that I only recognize one type of chess game, one that does follow the FIDE rules.

Really? So how exactly does Crafty, for example, follow the following FIDE rule?

Article 4: The act of moving the pieces

4.1 Each move must be made with one hand only.

In particular, how do you want to follow it in exactly the same way in automated engine-engine tournaments and in operator-assisted play?

[Guetti]

The problem is that I only recognize one type of chess game, one that does follow the FIDE rules.

Really? So how exactly does Crafty, for example, follow the following FIDE rule?

Article 4: The act of moving the pieces

4.1 Each move must be made with one hand only.

In particular, how do you want to follow it in exactly the same way in automated engine-engine tournaments and in operator-assisted play?

Doesn't belong to the topic, but this rule is obviously flawed and discriminating. It excludes people that don't have hands, are quadriplegic or are injured and cannot use their hands from tournament chess. It should be changed too:

4.1 It is not allowed to make moves with more than one hand.

or better, left out completely.

[Tony]

The problem is that I only recognize one type of chess game, one that does follow the FIDE rules.

Really? So how exactly does Crafty, for example, follow the following FIDE rule?

Article 4: The act of moving the pieces

4.1 Each move must be made with one hand only.

In particular, how do you want to follow it in exactly the same way in automated engine-engine tournaments and in operator-assisted play?

Does that mean you're not allowd to make a move if you have 2 hands ?

Tony

[bob]

The problem is that I only recognize one type of chess game, one that does follow the FIDE rules.

Really? So how exactly does Crafty, for example, follow the following FIDE rule?

Article 4: The act of moving the pieces

4.1 Each move must be made with one hand only.

In particular, how do you want to follow it in exactly the same way in automated engine-engine tournaments and in operator-assisted play?

Keep laughing. Or flip over to where you find out what they do for "blind human players" or do you believe that FIDE discriminates against people with handicaps and does not allow blind players, or players without arms or control of their arms?

One of these days you are going to get serious and quit trying to find one-line refutations that are ridiculous.

The USCF rules specifically address most of this by invoking "blind player" rules on behalf of a computer so that an operator for the computer becomes analogous to the blind player's "proxy" that makes the moves and tells him/her what the opponent played...

LOL indeed. Rather than laughing out loud, you ought to think quietly and most of those comments would not make it into print.

BTW I have had a version of Crafty that could meet that rule as is, because we used a robot arm. CDC/chess4.7 was the first to do this against David Levy in the late 70's, but it isn't that hard to do today...