Page 1 of 1

Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 17 Aug 2008, 18:59
by Ferdinand
Hi,

If I set Verify Engine Claims (VEC) and not set Detect Mates (DM) under engine options, winboard adjudication will not work as intended.

In the game below Neurosis-deuterium, deuterium mated neurosis, but winboard adjudicated it as {False win claim: 'Black mates'} 1-0. It awarded the win to neurosis :(

Mr. Muller can you check again on these 2 options please? I guess it is nice that if we set the VEC to true, possibly everything will be checked, and should not depend on DM setting.

Note that I already reported a similar case months ago using version 4.3.12.

Best regards.

Game records:
[Event "nts2006, t47, g1+1"]
[Site "VIVELEROI"]
[Date "2008.08.17"]
[Round "1.1"]
[White "Neurosis 2.4"]
[Black "deuterium 08.01.26.270"]
[Result "1-0"]
[TimeControl "60+1"]
[Annotator "15. -0.04 15... +0.25"]
[Number "1"]

1. e4 c5 2. Nf3 d6 3. d4 cxd4 4. Nxd4 Nf6 5. Nc3 a6 6. Be3 e5 7. Nb3 Be6 8.
f3 Be7 9. Qd2 O-O 10. O-O-O Nbd7 11. g4 b5 12. g5 b4 13. Ne2 Ne8 14. Kb1 a5
15. h4 {-0.04/7 1} a4 {+0.25/9 2} 16. Nbc1 {-0.05/6 0} Qb8 {+0.33/8 0} 17.
Bg2 {-0.10/6 0} Nc5 {+0.38/7 1} 18. Nd3 {-0.05/6 0} Nxd3 {+0.43/8 1} 19.
Qxd3 {-0.14/6 0} Qc7 {+0.49/8 1} 20. f4 {-0.08/6 0} b3 {+0.83/8 2} 21.
cxb3 {+0.03/7 1} axb3 {+0.77/9 2} 22. a3 {+0.05/7 1} Bc4 {+0.47/9 1} 23.
Qd2 {+0.05/7 1} Qc6 {-0.05/7 1} 24. Nc3 {+0.13/6 0} Rc8 {-0.33/8 1} 25.
h5 {+0.25/7 1} Nc7 {-0.33/8 1} 26. fxe5 {+0.27/7 1} dxe5 {-0.55/8 1} 27.
Qd7 {+0.18/7 0} Qxd7 {-0.66/9 1} 28. Rxd7 {+0.17/7 0} Rfe8 {-0.57/9 1} 29.
h6 {+0.12/7 0} g6 {-0.05/8 0} 30. Rg1 {+0.08/7 1} Ne6 {-0.09/9 1} 31.
Bh3 {+0.03/7 1} Rcd8 {+0.35/9 1} 32. Rb7 {-0.12/8 2} Ba6 {+0.00/8 1} 33.
Rxb3 {+0.78/6 0} Bd3+ {+0.29/8 1} 34. Kc1 {+0.53/8 0} Nf4 {+0.12/9 1} 35.
Rg3 {+0.08/8 1} Bxg5 {+0.64/9 1} 36. Rxg5 {+0.01/8 0} Nxh3 {+0.57/10 1} 37.
Rg4 {-0.09/8 1} f5 {+0.72/9 0} 38. Rh4 {-0.32/8 0} Nf4 {+0.49/10 1} 39.
Bxf4 {-0.29/8 0} exf4 {+0.39/7 0} 40. Nd5 {-0.29/8 0} Bc4 {+0.69/9 0} 41.
Rb7 {-0.39/8 0} Bxd5 {+1.12/8 1} 42. exd5 {-0.40/7 0} f3 {+1.40/10 1} 43.
Rf4 {-0.45/8 1} Re1+ {+1.56/10 1} 44. Kd2 {-0.40/6 0} Re2+ {+1.56/9 0} 45.
Kc3 {-0.33/6 0} f2 {+1.54/9 1} 46. Rg7+ {-0.39/7 0} Kh8 {+1.09/10 1} 47.
Rb7 {-0.44/7 1} Rc8+ {+1.09/8 1} 48. Kd3 {-0.42/7 1} Rce8 {+0.00/9 0} 49.
d6 {-0.31/7 3} R2e3+ {+0.00/9 1} 50. Kc2 {-0.25/6 0} Re2+ {+0.00/10 0} 51.
Kc3 {-0.25/6 0} Rd8 {+0.00/8 1} 52. b4 {-0.20/7 2} Re3+ {+0.00/7 1} 53.
Kb2 {-0.26/6 0} Re2+ {+0.00/8 0} 54. Kc3 {-0.19/5 0} Kg8 {+0.12/8 0} 55.
Re7 {-0.10/7 1} Rxe7 {-0.02/9 1} 56. dxe7 {-0.08/8 0} Rc8+ {+0.18/11 0} 57.
Kd2 {-0.08/8 0} Kf7 {+0.54/11 0} 58. Rxf2 {-0.24/8 0} Kxe7 {+0.55/10 0} 59.
Rf3 {-0.34/9 3} Kf6 {+0.46/10 1} 60. Rc3 {-0.37/9 1} Rh8 {+0.42/10 1} 61.
Rh3 {-0.35/9 1} Ra8 {+0.58/9 1} 62. Re3 {-0.42/8 0} g5 {+0.92/9 0} 63.
Kc2 {-0.94/9 1} g4 {+1.11/9 0} 64. b5 {-0.94/8 0} Kg5 {+1.63/9 0} 65.
Re7 {-1.07/8 1} Kxh6 {+1.45/8 0} 66. b6 {-1.17/8 1} Rb8 {+3.17/9 0} 67.
Re6+ {-1.29/8 0} Kg5 {+1.78/9 0} 68. Kd3 {-1.42/8 1} Rd8+ {+1.89/8 0} 69.
Kc4 {-1.37/6 0} h5 {+1.78/8 0} 70. b7 {-1.24/8 0} Rb8 {+2.18/8 0} 71.
Re7 {-1.38/8 1} Kf6 {+2.28/9 0} 72. Rd7 {-1.45/8 1} g3 {+3.03/10 1} 73.
Rd6+ {-1.49/7 0} Kg5 {+3.42/9 0} 74. Rd7 {-2.39/7 0} h4 {+6.69/9 0} 75.
Kd3 {-2.25/7 1} h3 {+13.74/9 0} 76. Rg7+ {-7.33/8 0} Kf4 {+14.35/10 0} 77.
a4 {-8.82/8 0} h2 {+15.46/8 0} 78. Rh7 {-10.75/8 0} g2 {+15.41/7 0} 79.
Rh4+ {-16.10/8 4} Kg3 {+22.22/8 0} 80. Rh7 {-16.33/8 3} h1=Q {+23.01/8 1}
81. Rg7+ {-17.34/7 0} Kf2 {+23.51/8 0} 82. a5 {-16.86/5 1}
g1=Q {+35.20/6 0} 83. Rxg1 {-299.92/4 0} Qd5+ {+99.93/6 1} 84.
Kc3 {-299.94/6 0} Qc5+ {+99.95/6 0} 85. Kb3 {-299.96/7 0}
Rxb7+ {+99.97/6 0} 86. Ka4 {-299.98/8 0} Qb4# {+99.99/6 0}
{False win claim: 'Black mates'} 1-0

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 17 Aug 2008, 21:12
by Zach Wegner
Does your engine report mate before or after it makes the move? It should be after. I don't use this feature myself ATM, so I can't tell you if I've seen the same behavior.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 17 Aug 2008, 22:56
by H.G.Muller
Indeed verify claims is not designed to work if detect mates is not switched on. But I did not really prevent switching it on if detect mates is off, and this could be considered a bug. Is this really a desirable mode?

Internally, the mates are detected as the move comes in, the claim comes in only later, in a separate message. For detection of draws, a draw condition (like 50-move or 3-fold rep) which is determined when the move comes in, is left in the e.p. status code of the position, (because you can never do an e.p. capture in a repeat or 50-move situation anyway), when rule Moves are set to > 50 or the drawRepeats to > 3. Draw claims are later verified against this.

I guess I could use the same strategy for handling mates. Always do the mate test, but leave the mate code in the e.p. status if detect mates is off, and check RESULT claims against it when these come in. A wrong claim here should not lead to forfeit, however, as the game is already officially finished when the mating move is done. Butthe claim should be corrected.

This is the reason why I did not support this combination of options: if in case of a wrong claim you would take the WinBoard adjudication result anyway, why not simply detect the mates in the first place? But it might be useful for testing if the mate claiming in engines works, of course. (But who wants the engines to claim mates if WinBoard can already detect them? The whole idea that engines must claim the mates is ridiculous, and a violation of FIDE rules.)

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 18 Aug 2008, 10:05
by Ferdinand
Zach Wegner wrote:Does your engine report mate before or after it makes the move? It should be after. I don't use this feature myself ATM, so I can't tell you if I've seen the same behavior.


Yes deuterium claimed mate after making the move.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 18 Aug 2008, 19:00
by Ferdinand
H.G.Muller wrote:Indeed verify claims is not designed to work if detect mates is not switched on. But I did not really prevent switching it on if detect mates is off, and this could be considered a bug. Is this really a desirable mode?

Internally, the mates are detected as the move comes in, the claim comes in only later, in a separate message. For detection of draws, a draw condition (like 50-move or 3-fold rep) which is determined when the move comes in, is left in the e.p. status code of the position, (because you can never do an e.p. capture in a repeat or 50-move situation anyway), when rule Moves are set to > 50 or the drawRepeats to > 3. Draw claims are later verified against this.

I guess I could use the same strategy for handling mates. Always do the mate test, but leave the mate code in the e.p. status if detect mates is off, and check RESULT claims against it when these come in. A wrong claim here should not lead to forfeit, however, as the game is already officially finished when the mating move is done. Butthe claim should be corrected.

This is the reason why I did not support this combination of options: if in case of a wrong claim you would take the WinBoard adjudication result anyway, why not simply detect the mates in the first place? But it might be useful for testing if the mate claiming in engines works, of course. (But who wants the engines to claim mates if WinBoard can already detect them? The whole idea that engines must claim the mates is ridiculous, and a violation of FIDE rules.)


From the winboard.txt:
"With /testClaim set, all result and illegal-move claims by engines that claim more than their own loss are scrutinized for validity, and false claims result in forfeit of the game. Useful with buggy engines."

I guess this guide should be updated :(

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 18 Aug 2008, 19:46
by Ferdinand
H.G.Muller wrote:Indeed verify claims is not designed to work if detect mates is not switched on. But I did not really prevent switching it on if detect mates is off, and this could be considered a bug. Is this really a desirable mode?

Internally, the mates are detected as the move comes in, the claim comes in only later, in a separate message. For detection of draws, a draw condition (like 50-move or 3-fold rep) which is determined when the move comes in, is left in the e.p. status code of the position, (because you can never do an e.p. capture in a repeat or 50-move situation anyway), when rule Moves are set to > 50 or the drawRepeats to > 3. Draw claims are later verified against this.

I guess I could use the same strategy for handling mates. Always do the mate test, but leave the mate code in the e.p. status if detect mates is off, and check RESULT claims against it when these come in. A wrong claim here should not lead to forfeit, however, as the game is already officially finished when the mating move is done. Butthe claim should be corrected.

This is the reason why I did not support this combination of options: if in case of a wrong claim you would take the WinBoard adjudication result anyway, why not simply detect the mates in the first place? But it might be useful for testing if the mate claiming in engines works, of course. (But who wants the engines to claim mates if WinBoard can already detect them? The whole idea that engines must claim the mates is ridiculous, and a violation of FIDE rules.)


I got a different case, this time I set the VEC and DM both to true.

[diag]8/8/8/5k1n/2n5/8/5K2/8 w - - 3 53 [/diag]
deuterium 08.01.26.270-RomiChess P3K
The last move was Nxh5 by RomiChess.

RomiChess then claimed this as draw, but the resulting adjudication was different, it says: {False draw claim: 'Romi says, we're all out of ammo'} 1-0

Winboard awarded the game to Deuterium :(

Perhaps adjudication should decide this as draw since white is no longer capable to mate black :wink:

Game record:
[Event "nts2006, t46, 17aug08, g1+1"]
[Site "VIVELEROI"]
[Date "2008.08.18"]
[Round "1.2"]
[White "deuterium 08.01.26.270"]
[Black "RomiChess P3K"]
[Result "1-0"]
[TimeControl "60+1"]
[Annotator "13. +0.35 12... -0.18"]
[Number "101"]

1. d4 d5 2. c4 dxc4 3. Nf3 Nf6 4. e3 e6 5. Bxc4 c5 6. O-O a6 7. a4 Nc6 8.
Qe2 cxd4 9. Rd1 Be7 10. exd4 O-O 11. Nc3 Nd5 12. Bb3 Ncb4 {-0.18/12 3} 13.
Bd2 {+0.35/7 1} f6 {-0.34/11 3} 14. Rdc1 {+0.58/9 2} Bd6 {-0.14/13 4} 15.
Ne4 {+0.74/7 2} Kh8 {-0.36/11 3} 16. Nxd6 {+1.18/5 0} Qxd6 {-0.33/13 4} 17.
Qe4 {+0.84/7 2} Rb8 {-0.32/12 2} 18. Rc4 {+1.17/6 1} Bd7 {-0.05/11 4} 19.
Nh4 {+0.79/6 1} f5 {+0.51/12 2} 20. Qe1 {+0.71/6 0} Nd3 {+0.52/12 2} 21.
Qf1 {+0.74/7 1} b5 {+0.81/13 3} 22. axb5 {-0.10/8 1} Nxb2 {+1.03/13 3} 23.
Rxa6 {-0.04/8 1} Qe7 {+0.38/12 2} 24. Ng6+ {+0.31/8 2} hxg6 {-0.12/14 2}
25. Rc5 {-0.18/9 2} Nf6 {-0.14/13 2} 26. Bf4 {+0.72/6 0} Ne4 {+0.47/13 2}
27. Bxb8 {-0.08/8 1} Rxb8 {+0.29/13 2} 28. Rc7 {-0.45/9 2}
Bxb5 {+0.63/12 2} 29. Rxe7 {+0.48/9 1} Bxf1 {+0.93/13 1} 30.
Raxe6 {+0.00/9 0} Rxb3 {+0.75/14 2} 31. Kxf1 {+0.00/10 1} Nd3 {+1.19/14 2}
32. g3 {-0.64/10 1} Rb2 {+1.66/13 2} 33. Re8+ {-1.25/8 1} Kh7 {+1.75/6 0}
34. f4 {-1.98/9 1} g5 {+2.18/14 2} 35. fxg5 {-1.79/10 1} Rf2+ {+2.41/14 2}
36. Kg1 {-0.03/4 0} Nxg5 {+2.09/14 2} 37. Re2 {-1.35/12 1}
Nf3+ {+1.98/14 2} 38. Kh1 {-1.62/4 0} Nxd4 {+1.94/15 1} 39.
Rxf2 {-1.37/11 1} Nxf2+ {+1.94/15 1} 40. Kg2 {-1.41/12 1} Ne4 {+2.12/15 1}
41. Rd8 {-1.44/10 0} Ne6 {+2.12/14 1} 42. Re8 {-1.42/10 0}
N4c5 {+2.06/14 1} 43. Kf3 {-1.62/11 1} Kg6 {+2.24/14 1} 44.
Ra8 {-1.51/10 1} Kf6 {+2.31/14 1} 45. h4 {-1.46/9 1} g6 {+2.32/14 1} 46.
Rg8 {-1.40/9 1} Ne4 {+2.25/13 1} 47. g4 {-1.50/9 0} Nd2+ {+2.74/13 1} 48.
Ke2 {-0.44/10 1} Nc4 {+2.35/14 1} 49. Rxg6+ {+0.00/11 1} Kxg6 {+8.54/15 1}
50. gxf5+ {+0.00/16 1} Kxf5 {+8.73/15 1} 51. h5 {+0.00/56 1}
Nf4+ {+9.29/14 1} 52. Kf2 {+0.00/39 1} Nxh5 {+9.34/15 1}
{False draw claim: 'Romi says, we're all out of ammo'} 1-0

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 19 Aug 2008, 00:27
by Zach Wegner
My mistake, I initially read your post as saying that both Verify Claims and Detect Mates were on, and I realize now that only VC was on.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 19 Aug 2008, 13:31
by H.G.Muller
Ferdinand wrote:I got a different case, this time I set the VEC and DM both to true.

[diag]8/8/8/5k1n/2n5/8/5K2/8 w - - 3 53 [/diag]
deuterium 08.01.26.270-RomiChess P3K
The last move was Nxh5 by RomiChess.

RomiChess then claimed this as draw, but the resulting adjudication was different, it says: {False draw claim: 'Romi says, we're all out of ammo'} 1-0

Winboard awarded the game to Deuterium :(

Well, KNNK is not a claimable draw, according to FIDE rules. There is a sequence of legal moves that leads to checkmate. So this is a false claim, and WinBoard is correct. I think Michael has been made aware of this Romi bug.

I admit the draw claim verification is not perfect, but KNNK is not amongst the problem cases. The problem lies in positions like this:

[diag]4k3/8/8/p1p1p1p1/PpPpPpPp/1P1P1P1P/8/4K3 w - - 0 1[/diag]

According to FIDE rule, this is draw, as no sequence of legal moves can lead to checkmate. But WinBoard is not smart enough to recognize that. But fortunately, neither are most engines, so it is not a big problem, and I do not intend to solve it. I think that WB protocol should specify that only things like KK, KNK, KBK and KBKB with like bishops can be claimed as draws, despite the fact that the FIDE rules might specify other cases. The FIDE rules are simply too difficult to handle. So the pragmatic solution is to reserve the 1/2-1/2 {insufficient mating material} command only for those cases. There would then be no command to claim more complex draws, and engines recognizing the draw would simply have to wait out the 50-move rule. This is a smaller inconvenience than making a claim that might not be recognized. So it should be clearly specified in the protocol definition what the limitations of the draw-recognition are, so that the boundary is not fuzzy, and some versions might reject claims that other versions would accept.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 19 Aug 2008, 14:18
by Ferdinand
H.G.Muller wrote:
Ferdinand wrote:I got a different case, this time I set the VEC and DM both to true.

[diag]8/8/8/5k1n/2n5/8/5K2/8 w - - 3 53 [/diag]
deuterium 08.01.26.270-RomiChess P3K
The last move was Nxh5 by RomiChess.

RomiChess then claimed this as draw, but the resulting adjudication was different, it says: {False draw claim: 'Romi says, we're all out of ammo'} 1-0

Winboard awarded the game to Deuterium :(

Well, KNNK is not a claimable draw, according to FIDE rules. There is a sequence of legal moves that leads to checkmate. So this is a false claim, and WinBoard is correct. I think Michael has been made aware of this Romi bug.


I think you miss this case, RomiChess has KNN and Deuterium has K only, and yet RomiChess claimed it as draw. RomiChess can not be defeated in this case bacause Deuterium has no pieces, and yet winboard adjudication gave the win to Deuterium :|

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 19 Aug 2008, 15:13
by Teemu Pudas
Ferdinand wrote:I think you miss this case, RomiChess has KNN and Deuterium has K only, and yet RomiChess claimed it as draw. RomiChess can not be defeated in this case bacause Deuterium has no pieces, and yet winboard adjudication gave the win to Deuterium :|

Claiming a draw with the RESULT command is like claiming a draw and immediately leaving the game even if the claim is rejected, so a false claim should always lose.

0.5-0?

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 19 Aug 2008, 18:53
by Ferdinand
Teemu Pudas wrote:
Ferdinand wrote:I think you miss this case, RomiChess has KNN and Deuterium has K only, and yet RomiChess claimed it as draw. RomiChess can not be defeated in this case bacause Deuterium has no pieces, and yet winboard adjudication gave the win to Deuterium :|

Claiming a draw with the RESULT command is like claiming a draw and immediately leaving the game even if the claim is rejected, so a false claim should always lose.

0.5-0?


Can you elaborate further, I did not get what you mean.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 19 Aug 2008, 19:48
by H.G.Muller
Ferdinand wrote:I think you miss this case, RomiChess has KNN and Deuterium has K only, and yet RomiChess claimed it as draw. RomiChess can not be defeated in this case bacause Deuterium has no pieces, and yet winboard adjudication gave the win to Deuterium :|

Ah, I missed that indeed. I remember a similar issue came up in the Chess War Promo (a false claim against an opponnt that was reduced to a bare King). We discussed it briefly, but without a clear reolution.

I am not sure what the FIDE rules say about this. If you for instance forfeit on time agains a bare opponent, is it a loss or a draw? Who knows this? And how about resigning? If the opponent of a bare King resigns, does he still lose?

It is easy enough to test all wins always for the winner not having a bare King, and correct them to draws, when verify claims is on. (It would be a lot more difficult to sort by kind of win, as the details field in the RESULT command is kind of free format, people could print any message there.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 19 Aug 2008, 20:11
by Roger Brown
H.G.Muller wrote:
Ah, I missed that indeed. I remember a similar issue came up in the Chess War Promo (a false claim against an opponnt that was reduced to a bare King). We discussed it briefly, but without a clear reolution.

I am not sure what the FIDE rules say about this. If you for instance forfeit on time agains a bare opponent, is it a loss or a draw? Who knows this? And how about resigning? If the opponent of a bare King resigns, does he still lose?

It is easy enough to test all wins always for the winner not having a bare King, and correct them to draws, when verify claims is on. (It would be a lot more difficult to sort by kind of win, as the details field in the RESULT command is kind of free format, people could print any message there.




Hello H.G.,

I hope the matter below helps. I lifted it from Wikipedia to credit the source.

The second rule regards the arbiter's possibility of ending a game as drawn due to a player's lack of effort in winning the game by "normal means". Occasionally it happens in a sudden death time control without increments that a player has trouble in physically executing an indefinite series of moves in the time remaining. The opponent could try playing on this, and continue to play on in the hopes of winning by time forfeit, rather than by winning the position on the board. To prevent this FIDE has article 10.2[7] A player with less than two minutes remaining can, if he considers that the opponent is no longer trying to win the game by normal means, claim a draw and summon the arbiter. The arbiter may accept the claim (which ends the game immediately as a draw), reject the claim (after which the game continues, with the opponent receiving two additional minutes), or postpone the decision. In this case the opponent may be given two minutes extra, and the game continues until the arbiter makes a call or the claimant's flag falls after which the arbiter makes a decision. Decisions made by the arbiter under 10.2 are final.



Tournaments governed under the rules of the United States Chess Federation have a similar rule to FIDE's 10.2, called the "insufficient losing chances" rule. A player with less than two minutes remaining without time delay can petition the tournament director for a draw on the grounds that the opponent has no reasonable chance of winning the position, had both players had ample time. In USCF's guidelines, this would mean an average tournament player (class C) having a less than a 10% probability of losing the position against a master. The tournament director may accept the claim (ending the game as drawn), reject the claim and penalize the claimant with one minute less time, or postpone the decision. If the tournament director postpones the decision, there is the option of substituting a non-delay clock with a delay clock with the claimant having his remaining time halved. Since the insufficient losing chances rules calls upon discretion from the tournament director, clocks with the time delay feature are preferred over clocks without them.

Later.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 19 Aug 2008, 20:15
by Matthias Gemuh
H.G.Muller wrote:
I am not sure what the FIDE rules say about this. If you for instance forfeit on time agains a bare opponent, is it a loss or a draw? Who knows this? And how about resigning? If the opponent of a bare King resigns, does he still lose?



Non-FIDE standard for ChessGUI :

The time forfeit is a draw.
The resign is a loss (a penalty for foolishness :wink: ).

Matthias.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 19 Aug 2008, 21:03
by Teemu Pudas
Ferdinand wrote:Can you elaborate further, I did not get what you mean.

FIDE Laws of Chess, Article 12.8 wrote:
Persistent refusal by a player to comply with the Laws of Chess shall be penalised by loss of the game. The arbiter shall decide the score of the opponent.

If the opponent can't mate, giving him only half a point seems reasonable.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 20 Aug 2008, 07:37
by Terry McCracken
H.G.Muller wrote:
Ferdinand wrote:I got a different case, this time I set the VEC and DM both to true.

[diag]8/8/8/5k1n/2n5/8/5K2/8 w - - 3 53 [/diag]
deuterium 08.01.26.270-RomiChess P3K
The last move was Nxh5 by RomiChess.

RomiChess then claimed this as draw, but the resulting adjudication was different, it says: {False draw claim: 'Romi says, we're all out of ammo'} 1-0

Winboard awarded the game to Deuterium :(

Well, KNNK is not a claimable draw, according to FIDE rules. There is a sequence of legal moves that leads to checkmate. So this is a false claim, and WinBoard is correct. I think Michael has been made aware of this Romi bug.

I admit the draw claim verification is not perfect, but KNNK is not amongst the problem cases.


I think this rule needs modification, as it is a draw expect for a helpmate.

I intentionally sacked material to force a draw over 20 years ago to achieve KNNK. It really peeved my opponent. :mrgreen:

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 20 Aug 2008, 08:38
by H.G.Muller
OK, I solved the problem as follows:

Verify Claims can now be turned on even when Detect Mates is off. (Of course Legality Testing still has to be on.) Even when DM is off, WinBoard tests if a move results in a mate after every move, but if it is, and DM was off, it just rembers the result (checkmate or stalemate) with the position (in the variable where it normally remembers e.p. status), just like it remembers if there is a 50-move, 3-fold-rep or insufficient-mating-material condition. When an engine claims, and VC is on, the claim is then checked against this remembered result, and changed into a loss when the claim turns out to be false.

After this whole process, when the result is not a draw, the pieces of the alleged winner are counted. If the count is <= 1, the result is corrected to draw. WinBoard will append the words "but bare king" to the result-details message. This happens even when legality testing is off, and not just to engine claims, but also to xboard adjudictions. But only if VC is on.

So in the Romi case, we would get the message:

{False draw claim: 'we are all out of ammo' but bare king} 1/2-1/2

When white would have claimed, however, it would remain a loss. Similarly you could get

{white loses on time, but bare king} 1/2-1/2
{engine 'buggy.exe' exited unexpectedly but bare king} 1/2-1/2
{black resigned but bare king} 1/2-1/2


The improved executable is hidden in the usual place.

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 24 Aug 2008, 17:24
by Ferdinand
H.G.Muller wrote:OK, I solved the problem as follows:

Verify Claims can now be turned on even when Detect Mates is off. (Of course Legality Testing still has to be on.) Even when DM is off, WinBoard tests if a move results in a mate after every move, but if it is, and DM was off, it just rembers the result (checkmate or stalemate) with the position (in the variable where it normally remembers e.p. status), just like it remembers if there is a 50-move, 3-fold-rep or insufficient-mating-material condition. When an engine claims, and VC is on, the claim is then checked against this remembered result, and changed into a loss when the claim turns out to be false.

After this whole process, when the result is not a draw, the pieces of the alleged winner are counted. If the count is <= 1, the result is corrected to draw. WinBoard will append the words "but bare king" to the result-details message. This happens even when legality testing is off, and not just to engine claims, but also to xboard adjudictions. But only if VC is on.

So in the Romi case, we would get the message:

{False draw claim: 'we are all out of ammo' but bare king} 1/2-1/2

When white would have claimed, however, it would remain a loss. Similarly you could get

{white loses on time, but bare king} 1/2-1/2
{engine 'buggy.exe' exited unexpectedly but bare king} 1/2-1/2
{black resigned but bare king} 1/2-1/2


The improved executable is hidden in the usual place.


Can you check again on this, I got one case here where white wins on time but has only a king. The adjudication was wrong, it gave the win to white. I use Winboard 4.3.15c.

[diag]8/8/8/8/5b2/8/4k2p/7K b - - 87 153 [/diag]
Deuterium 08.01.26.270-5-Neurosis 2.4
Black to play

Black overstepped the time limit here. Black played f4d6 based from debug below.

Please be noted that other adjudication by this new winboard version is correct, like I have one here, Black wins on time but bare king.

SOME PARTS OF DEBUG FILE:
Interrupting second
714922 >second: time 23
714922 >second: otim 4686
714922 >second: g2h1
715016 <second: Found usermove : Kh1
715063 <second: Legal moves: 18 Static score: 313
715063 <second: Ply Score Time Nodes Best move and expected line
715063 <second: ------------------------------------------------------------
715063 <second: 2 313 0 26 Bd6 Kg2 Ke1 Kh1 Bb8 Kg2 Bd6
715078 <second: 3 313 0 75 Bd6 Kg2 Ke1 Kh1 Bb8 Kg2 Bd6
715078 <second: Total nodes:347 n/sec:347 (q-nodes:1% max depth:4)
715094 <second: move f4d6
machine move 305, castling = -1 -1 -1 7 -1 -1
move to parse: f4d6
7 0 4 7 0 4 Legality test? f4d6
-1 -1 -1 7 -1 -1 Legality test? f4d6
(-1,0) (-1,0) (-1,0) (7,7) (-1,7) (-1,7) castling rights
GameEnds(37, White wins on time, 4)
GameEnds(37, White wins on time, 4) clock stopped
GameEnds(37, White wins on time, 4) bare king k=64 color=0
GameEnds(37, White wins on time, 4) after test
times = 59937 60000 60000 60000, seconds=0
....
....
715328 >first : result 1-0 {White wins on time}
Interrupting second
715328 >second: result 1-0 {White wins on time}
715328 >first : quit
715328 >second: force

COMPLETE GAME RECORD:
[Event "nts2006, t47, g1+1"]
[Site "VIVELEROI"]
[Date "2008.08.24"]
[Round "13"]
[White "Deuterium 08.01.26.270-5"]
[Black "Neurosis 2.4"]
[Result "1-0"]
[TimeControl "1000/60"]
[Annotator "19. +0.14 18... +0.08"]

1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8.
c3 O-O 9. h3 Na5 10. Bc2 c5 11. d4 Qc7 12. Nbd2 cxd4 13. cxd4 Nc6 14. Nb3
a5 15. Be3 a4 16. Nbd2 Bd7 17. Rc1 Qb7 18. d5 {+0.57/2 0} Nb4 {+0.08/7 0}
19. Bb1 {+0.14/4 0} Rfc8 {-0.08/7 0} 20. Rc3 {+0.14/2 0} Na6 {-0.08/6 0}
21. Qc1 {+0.36/2 0} Rxc3 {+0.03/6 0} 22. bxc3 {-0.10/4 0} Rc8 {+0.00/6 0}
23. Qb2 {-0.15/3 0} Qc7 {-0.05/6 0} 24. Bd3 {-0.04/3 0} Qxc3 {+1.02/6 0}
25. Qxc3 {-1.31/4 0} Rxc3 {+1.08/6 0} 26. Bf1 {-1.33/4 0} Nc5 {+1.24/6 0}
27. Rb1 {-1.26/3 0} Nfxe4 {+1.24/7 0} 28. Bxb5 {-0.93/4 0} Nxd2 {+1.17/7 0}
29. Bxd2 {-0.82/5 0} Bf5 {+1.18/7 0} 30. Rb2 {-0.70/5 0} Rc2 {+1.20/8 0}
31. Rxc2 {-0.69/5 0} Bxc2 {+1.19/6 0} 32. Kf1 {-0.86/6 0} Be4 {+1.22/7 0}
33. Bc6 {-0.84/5 0} Ne6 {+1.37/7 0} 34. a3 {-1.06/4 0} Nc7 {+1.42/8 0} 35.
Bxa4 {-1.02/5 0} Bxd5 {+1.46/8 0} 36. Bd7 {-1.04/6 0} Bxf3 {+1.57/8 0} 37.
gxf3 {-0.73/6 0} d5 {+1.54/8 0} 38. a4 {-0.82/6 0} Bd6 {+1.50/8 1} 39.
a5 {-0.51/5 0} d4 {+1.52/7 0} 40. Ke2 {-0.49/5 0} Kf8 {+1.50/7 1} 41.
Kd3 {-0.49/5 0} Ke7 {+1.50/7 0} 42. Bc6 {-0.51/5 0} Ne6 {+1.47/8 0} 43.
f4 {-0.43/5 0} exf4 {+1.37/8 0} 44. Bd5 {-0.59/5 0} Bc5 {+1.33/8 0} 45.
a6 {-0.61/5 0} g5 {+1.58/7 0} 46. Be4 {-0.77/5 0} h6 {+1.62/7 0} 47.
Bd5 {-0.68/5 0} Bb6 {+1.63/7 0} 48. Be1 {-0.83/4 0} Nc5+ {+2.06/7 0} 49.
Kxd4 {-0.79/5 0} Nxa6+ {+2.00/7 0} 50. Ke5 {-0.90/6 0} Bc5 {+2.05/7 0} 51.
f3 {-1.09/5 0} Bd6+ {+1.93/7 0} 52. Kf5 {-0.91/7 0} Bb4 {+1.86/9 0} 53.
Bf2 {-0.99/7 0} Bc5 {+1.86/9 0} 54. Be1 {-1.18/7 0} Nc7 {+1.99/8 0} 55.
Bc4 {-1.16/6 0} Ne8 {+1.45/8 0} 56. Ke5 {-1.05/6 0} Bd6+ {+1.47/8 0} 57.
Ke4 {-0.96/6 0} Nf6+ {+1.77/7 0} 58. Kf5 {-1.00/6 0} Nh5 {+1.47/8 0} 59.
Ke4 {-0.98/6 0} Ng3+ {+1.49/8 0} 60. Kd3 {-1.06/6 0} f5 {+1.99/7 0} 61.
Bc3 {-1.10/5 0} h5 {+2.06/8 0} 62. Bd5 {-1.24/6 0} g4 {+2.08/7 0} 63.
h4 {-1.19/5 0} Nf1 {+2.48/7 0} 64. Bd4 {-2.06/6 0} Nh2 {+2.53/8 0} 65.
Ke2 {-1.84/6 0} Nxf3 {+2.60/10 0} 66. Bxf3 {-1.96/6 0} gxf3+ {+2.57/9 0}
67. Kf2 {-2.11/7 0} Ke6 {+2.58/9 0} 68. Kxf3 {-2.11/7 0} Be7 {+2.58/8 0}
69. Bf2 {-1.96/7 0} Bd6 {+2.55/9 0} 70. Bd4 {+0.00/10 0} Be5 {+2.58/9 0}
71. Bc5 {-2.09/8 0} Bf6 {+2.55/9 0} 72. Bf2 {-1.67/8 0} Ke5 {+2.46/9 0} 73.
Be1 {-1.81/8 0} Be7 {+2.58/10 0} 74. Bc3+ {-2.11/8 0} Ke6 {+2.58/9 0} 75.
Be1 {-2.11/8 0} Ke5 {+2.48/10 0} 76. Bc3+ {+0.00/10 0} Ke6 {+1.27/9 0} 77.
Be1 {+0.00/10 0} Bd6 {+1.28/9 0} 78. Bd2 {-2.11/8 0} Bc7 {+1.37/9 0} 79.
Bb4 {-2.11/9 0} Bd8 {+2.55/9 0} 80. Be1 {-1.59/7 0} Bc7 {+1.37/9 0} 81.
Bb4 {+0.00/11 0} Be5 {+1.37/9 0} 82. Bc5 {+0.00/11 0} Bf6 {+1.50/9 0} 83.
Bf2 {+0.00/11 0} Ke5 {+1.34/9 0} 84. Be1 {+0.00/12 0} Bd8 {+1.24/9 0} 85.
Bc3+ {-1.57/9 0} Ke6 {+1.25/9 0} 86. Be1 {+0.00/12 0} Kf6 {+1.26/9 0} 87.
Kxf4 {-1.63/8 0} Bc7+ {+1.25/8 0} 88. Kf3 {-1.63/8 0} Ke6 {+1.27/9 0} 89.
Bf2 {-1.63/8 0} Kd5 {+1.27/8 0} 90. Ba7 {-1.63/8 0} Be5 {+1.27/8 0} 91.
Bf2 {-1.47/7 0} Bd6 {+1.27/8 0} 92. Be3 {-1.58/6 0} Be5 {+1.26/8 0} 93.
Bf2 {+0.00/9 0} Bd6 {+1.25/7 0} 94. Be3 {+0.00/10 0} Bc7 {+1.25/7 0} 95.
Ba7 {+0.00/10 0} f4 {+1.25/7 0} 96. Be3 {-0.41/7 0} fxe3 {+2.35/8 0} 97.
Kxe3 {+0.00/8 0} Bg3 {+2.40/7 0} 98. Kf3 {+0.00/8 0} Bxh4 {+2.59/7 0} 99.
Kf4 {+0.00/11 0} Be1 {+2.67/7 0} 100. Kg5 {+0.00/38 0} h4 {+2.95/11 0} 101.
Kg4 {+0.00/12 0} Ke4 {+2.95/9 0} 102. Kh3 {+0.00/13 0} Kf3 {+2.95/7 0} 103.
Kh2 {+0.00/14 0} Bg3+ {+2.99/6 0} 104. Kg1 {+0.00/15 0} h3 {+3.13/6 0} 105.
Kh1 {+0.00/14 0} Bf4 {+3.13/4 0} 106. Kg1 {+0.00/16 0} Ke2 {+3.15/5 0} 107.
Kh1 {+0.00/17 0} Kf3 {+3.13/2 0} 108. Kg1 {+0.00/60 0} Ke2 {+3.15/5 0} 109.
Kh1 {+0.00/60 0} h2 {+3.15/6 0} 110. Kg2 {+0.00/21 0} Bg3 {+3.15/6 0} 111.
Kh1 {+0.00/23 0} Be5 {+3.02/6 0} 112. Kg2 {+0.00/26 0} Ke1 {+3.15/5 0} 113.
Kh1 {+0.00/30 0} Ke2 {+3.02/5 0} 114. Kg2 {+0.00/60 0} Bf4 {+3.13/5 0} 115.
Kh1 {+0.00/30 0} Ke1 {+3.13/5 0} 116. Kg2 {+0.00/34 0} Kd2 {+3.02/3 0} 117.
Kh1 {+0.00/33 0} Ke1 {+3.15/4 0} 118. Kg2 {+0.00/60 0} Kd2 {+3.15/5 0} 119.
Kh1 {+0.00/60 0} Be5 {+3.02/5 0} 120. Kg2 {+0.00/34 0} Ke2 {+3.15/5 0} 121.
Kh1 {+0.00/36 0} Kd2 {+3.15/4 0} 122. Kg2 {+0.00/60 0} Ke2 {+3.02/4 0} 123.
Kh1 {+0.00/60 0} Kd1 {+3.02/5 0} 124. Kg2 {+0.00/38 0} Bf4 {+3.15/5 0} 125.
Kh1 {+0.00/39 0} Be5 {+3.02/5 0} 126. Kg2 {+0.00/60 0} Bf4 {+3.02/4 0} 127.
Kh1 {+0.00/60 0} Kd2 {+3.02/6 0} 128. Kg2 {+0.00/39 0} Kd3 {+3.02/4 0} 129.
Kh1 {+0.00/39 0} Kd2 {+3.13/4 0} 130. Kg2 {+0.00/60 0} Bc7 {+3.15/5 0} 131.
Kh1 {+0.00/42 0} Ke2 {+3.13/5 0} 132. Kg2 {+0.00/44 0} Bd6 {+3.02/4 0} 133.
Kh1 {+0.00/45 0} Ke1 {+3.02/5 0} 134. Kg2 {+0.00/48 0} Ke2 {+3.15/5 0} 135.
Kh1 {+0.00/60 0} Ke1 {+3.09/5 0} 136. Kg2 {+0.00/60 0} Bf4 {+3.15/5 0} 137.
Kh1 {+0.00/50 0} Be5 {+3.02/5 0} 138. Kg2 {+0.00/53 0} Kd2 {+3.15/5 0} 139.
Kh1 {+0.00/53 0} Ke1 {+3.02/5 0} 140. Kg2 {+0.00/60 0} Bf4 {+3.15/5 0} 141.
Kh1 {+0.00/60 0} Bg3 {+3.02/5 0} 142. Kg2 {+0.00/57 0} Ke2 {+3.02/7 0} 143.
Kh1 {+0.00/60 0} Ke1 {+3.02/5 0} 144. Kg2 {+0.00/60 0} Bd6 {+3.13/7 0} 145.
Kh1 {+0.00/60 0} Bc7 {+3.02/5 0} 146. Kg2 {+0.00/60 0} Ke2 {+3.02/7 0} 147.
Kh1 {+0.00/60 0} Ke1 {+3.02/6 0} 148. Kg2 {+0.00/60 0} Ke2 {+3.13/6 0} 149.
Kh1 {+0.00/60 0} Kd3 {+3.02/6 0} 150. Kg2 {+0.00/59 0} Bf4 {+3.02/4 0} 151.
Kh1 {+0.00/60 0} Ke3 {+3.13/3 0} 152. Kg2 {+0.00/60 0} Ke2 {+3.00/3 0} 153.
Kh1 {+0.00/60 0} {+3.13/3 0}
{White wins on time} 1-0

Re: Verify Engine Claims option of Winboard 4.3.13c

PostPosted: 30 Aug 2008, 07:02
by Gábor Szots
H.G.Muller wrote:I am not sure what the FIDE rules say about this. If you for instance forfeit on time agains a bare opponent, is it a loss or a draw? Who knows this?


Once I exceeded time in such a position (opp had lone king) and a draw was awarded.