False draw claim by Lime

[hgm]

It seems that the 50-move rule is not correctly implemented in Lime KM 621:

Code: Select all

[Event "Computer Chess Game"]
[Site "SCHAAK_PC"]
[Date "2010.01.14"]
[Round "7.5"]
[White "Lime KM 62 / 7"]
[Black "MSKCP 1.4.4"]
[Result "0-1"]
[TimeControl "40/960"]
[Variant "knightmate"]
[Number "69"]
[Annotator "1. +0.09"]

1. b3 {+0.09/9} e5 2. Bb2 {+0.01/8} d6 3. d4 {+0.05/8} c5 4. dxe5 {+0.01/9}
Qa5+ 5. c3 {+0.18/8} dxe5 6. e4 {+0.19/9} Mc7 7. Bc4 {+0.01/8} Md6 8. Mc2
{+0.05/8} Be6 9. Bxe6 {+0.02/10} Mxe6 10. Mf1 {+0.03/10} Rd8 11. Md3
{+0.05/9} g6 12. Mfe2 {+0.04/8} Bh6 13. Kg1 {+0.05/10} Mg7 14. Bc1
{+0.05/9} Kg8 15. Bxh6 {+0.00/9} Mxh6 16. Mee3 {+0.01/9} c4 17. bxc4
{+0.33/10} Rd7 18. Qf3 {+0.34/9} Rfd8 19. Rfd1 {+0.45/8} Mg5 20. Rab1
{+0.40/9} h5 21. Rd2 {+0.49/9} a6 22. Qd1 {+0.56/9} Qc5 23. Qc2 {+0.56/9}
h4 24. Rbd1 {+0.60/9} Qc6 25. Qb3 {+0.58/9} Md6 26. h3 {+0.48/8} Mc5 27.
Qa3 {+0.20/8} f5 28. Qb2 {+0.40/8} b6 29. f3 {+0.70/10} f4 30. Mee2
{+0.63/10} a5 31. Qb1 {+0.58/10} a4 32. Me1 {+0.50/9} a3 33. Qb3 {+0.67/11}
Qa8 34. Mde2 {+0.67/12} Rxd2 35. Rxd2 {+0.60/11} Rxd2 36. M1xd2 {+0.49/14}
Mf6 37. Mdd3 {+0.49/12} Me6 38. Qc2 {+0.45/12} Qa5 39. Qb1 {+0.45/11} Qa6
40. Qc1 {+0.43/12 0.1} Qa8 41. Md1 {+0.45/10} b5 42. Qd2 {+0.21/10} Mxc4
43. Mxc4 {+0.27/12} bxc4 44. Qf2 {+0.26/13} Qa5 45. Ke2 {+0.23/12} Qd8 46.
Mc2 {+0.41/12} Qg5 47. Kc1 {+0.49/13} Kh6 48. Qc5 {+0.55/11} Mf7 49. Qc8
{+0.38/10} Mg8 50. Qg4 {+0.13/14} Qxg4 51. hxg4 {+0.14/21} Mf8 52. Md2
{+0.14/20} Me8 53. Me2 {+0.14/21} Kf7 54. Mf2 {+0.13/19} Kh6 55. Mg1
{+0.21/21} Kf7 56. Mh2 {+0.22/22} g5 57. Mg1 {+0.22/24} Kh6 58. Mf1
{+0.22/25} Kg8 59. Ke2 {+0.22/25} Mf7 60. Me1 {+0.22/24} Me6 61. Mf2
{+0.22/23} Ke7 62. Mg1 {+0.22/24} Kg8 63. Kc1 {+0.22/17} Md7 64. Mf2
{+0.22/25} Mc6 65. Mf1 {+0.22/22} Mb6 66. Me2 {+0.22/23} Mc6 67. Md2
{+0.22/23} Md6 68. Ke2 {+0.22/24} Me6 69. Mc2 {+0.22/21} Mf6 70. Kg1
{+0.22/21} Mg7 71. Md1 {+0.22/24} Mh7 72. Md2 {+0.22/21} Mg7 73. Ke2
{+0.22/24} Ke7 74. Mc1 {+0.22/21} Kg8 75. Md1 {+0.22/23} Mf7 76. Kg1
{+0.22/27} Ke7 77. Md2 {+0.22/24} Kg8 78. Kh3 {+0.22/22} Mg6 79. Mc2
{+0.22/24} Ke7 80. Kf2 {+0.22/24 0.1} Mg7 81. Md2 {+0.22/22} Kc8 82. Me2
{+0.22/22} Ke7 83. Kd1 {+0.22/22} Kg8 84. Mf2 {+0.22/21} Mf7 85. Mf1
{+0.22/23} Me7 86. Me2 {+0.22/23} Mf7 87. Kf2 {+0.22/24} Mg7 88. Kh3
{+0.22/24} Mg6 89. Md2 {+0.22/23} Ke7 90. Kf2 {+0.22/22} Mg7 91. Me1
{+0.22/24} Kg8 92. Kh3 {+0.22/26} Mg6 93. Mf1 {+0.22/25} Mh6 94. Mg1
{+0.22/26} Ke7 95. Mf2 {+0.22/26} Kc6 96. Mf1 {+0.22/25} Ke7 97. Me2
{+0.22/25} Mg6 98. Mf2 {+0.22/15} Kc8 99. Mf1 {+0.00/21} Ke7 100. Kf2
{+0.00/24} Mg7 101. Me2 {+0.00/24} Mf7
{False draw claim: 'fifty move rule'} 0-1

After black move 101 it claims a draw. Now it is true that the last capture was at white move 51, but black move 56 was a Pawn move...

[Michel]

This is clearly a bug.

But assuming there had been no pawn move
how does the WB protocol handle the 50 move rule? If I understand
correctly FIDE rules allow one to claim draw after 99 plies provided one communicates the "intended move" to the opponent.

One can not actually make the move on the board since then it becomes the opponents turn and one loses the right to claim the draw.

So how does the WB protocol handle this?

[hgm]

Unfortunately, WB protocol does not support an atomic draw claim, and the specs allow you to claim after the move that draws. So even if due to the race condition the opponent can slip in a fast move which destroys the draw condition, WinBoard has to (and will) accept the claim. This allows cheating (wait claiming the draw until you have seen the opponent's move, in the hope it is a blunder), but the idea that there would be engines that actually try to exploit this is a bit far-fetched, IMO. Anyway, this cheating cannot be prevented without breaking backward compatibility, so it cannot be helped.

Internet Chess Servers are not so forth-coming, and might deny you the draw in such a case. On ICC you have to request the draw before the move (where formally it could still be refused by the opponent), and then the ICS treats a situation after the move where a claimable draw appears as if it is claimed atomically with the move, when such a request is pending. This is acheived through the WB commands:

offer draw
MOVE
1/2-1/2 {50-move rule}

This also works in local play (as the offer-draw does no harm).

Lately someone pointed out that FICS behaves differently, and that as a result the sequence above might not work. One has to send the move on the same line as the draw command there, to make an atomic claim. This is not supported by WinBoard, and I guess this should be considered a bug. WinBoard should learn to recognize FICS (or have an option that allows the user to tell it is playing on FICS), and translate the above sequence to

draw MOVE

As WinBoard does not relay the draw offer until after it has seen the move (it is not allowed to distract the opponent with draw offers when he is thinking), this can in principle easily be implemented.

[Richard Allbert]

Correct, it's a bug that was in v62 corrected in v66

In doundo.cpp, just change the line

Code: Select all

 if&#40;p->board&#91;to&#93;.typ < 2&#41; p->fifty = 0;

to

Code: Select all

 if&#40;p->board&#91;to&#93;.typ < 3&#41; p->fifty = 0;

Sorry!!!

Richard

[wgarvin]

If I understand
correctly FIDE rules allow one to claim draw after 99 plies provided one communicates the "intended move" to the opponent.

One can not actually make the move on the board since then it becomes the opponents turn and one loses the right to claim the draw.

Off-topic: The nice effect of these rules (when it comes to endgame databases) is that after 50 non-converting moves *by your opponent*, if he failed to win the game with the 50th move, you are able to claim a draw--it doesn't matter whether you yourself have made 50 consecutive non-converting moves, or only 49! If he didn't checkmate you, you can communicate any move as the "intended move" and atomically claim the draw. So for example, in endgame tablebases in DTZ50 format (distance-to-zeroing or 50 move draw), knowing who made the last converting move is not necessary to correctly handle draws and wins as the hmc gets near 100. Which was a tremendous relief to me when I figured out.

Although the WB protocol does not directly support the atomic draw claims there are workarounds, as hgm mentioned. There's a couple lengthy threads on this board discussing whether the protocol could be fixed, what workarounds all engines should use, etc. Its complicated because of timing loopholes. Any real solution has to work in several scenarios: on ICS play (where they won't change their protocol just because we nicely ask them to), with "dumb GUIs" (e.g. that don't know the rules of the variant you're playing, so they must blindly relay any draw offers to the opponent), with "smart GUIs" (that know when draws can legally be claimed in the variant you're playing, and will interpret "offer draw" followed by a move as a claimed draw without relaying the offer, but only when that is legal), and finally: how will it work with existing WB GUIs or adapters if they are not updated to the new protocol?

I think the "offer draw / move / claim result" sequence that hgm described, is the best compromise anyone has proposed. It works correctly with ICS and with smart GUIs, and the "offer draw" is hopefully not too annoying with dumb GUIs and old GUIs since the game will end momentarily anyway. It does have race conditions with non-smart GUIs, but that is difficult to fix.

One of the "race condition" cases (probably not the only one, I don't recall..) is where the GUI passes "offer draw" and "MOVE" to the opponent, who instantly responds with their pondered move (suppose its a pawn push..), which the GUI considers before it considers your "result" claim. So the GUI (or at least, your opponent) has already updated its board, and if it understands the rules of the variant, might decide that you lost the game instead of drawing it (because the board has changed and your draw claim may no longer be valid).

[hgm]

Off-topic: The nice effect of these rules (when it comes to endgame databases) is that after 50 non-converting moves *by your opponent*, if he failed to win the game with the 50th move, you are able to claim a draw--it doesn't matter whether you yourself have made 50 consecutive non-converting moves, or only 49! If he didn't checkmate you, you can communicate any move as the "intended move" and atomically claim the draw.

This is only true when you have legal non-capture moves, not? If you are in a position where you can only capture, it is important if you can claim before or after your move.

Joker lost to Ktulu in Leiden last year, because on the 100th ply it could only capture a Queen to get out of check in KQQK... Ktulu apparenty new that Joker could not claim before the move.

[Richard Allbert]

Fixed version is here

http://jabbachess.fileave.com/limeKM_621_ja.rar

Jim, if you upload this on your site, let me know, and I'll remove the link (space is limited )

Regards

Richard

[hgm]

One question, prompted by the fact that the KM version of Lime apparently still contains bugs that are already fixed in the normal version, which is a few cycles further in development. And tht you mentioned it only took you a few minutes to convert Jabba.

Would it be very hard to support normal and knightmate in the same version, and let the engine do the required patches only when it receives the WB command variant knightmate ? I don't know exactly what you had to do to convert; perhaps you change the list of move vectors for K and N in somemove-geerator table, or perhaps you just swap Kings and Knights in the opening setup and designate the other piece type as royal; (And of course change some piece base values or PSTs), but in both cases it would be very easy to do this at run time. That would avoid the need for parallel development, and the KM version would just hitch along with your main development.

I know, of course, that I set a bad example with JokerKM, which is a dedicated version, but it turned out that in Joker neither of the two mentioned strategies worked correctly (to my surprise; I spent two days of debugging on this... ). The reason was that Joker has special code for generating moves with pinned pieces, and that a Knight that is pinned never has any moves, while a Commoner that is pinned always can have two. (And the royal piece of course can never be pinned.) So it was overlooking those moves, and producing lots of false illegal-move claims... So I had to replace that code. (And I have not been developing Joker anyway since then, so there was never much need to unify the two versions.)

[Jim Ablett]

Fixed version is here

http://jabbachess.fileave.com/limeKM_621_ja.rar

Jim, if you upload this on your site, let me know, and I'll remove the link (space is limited )

Regards

Richard

It up on my site now.
Thanks for the quick fix.

Jim.

[Richard Allbert]

It would only require a few "if" statements in the code, for the draw detection in eval, piece values, psqt and move direction arrays.

Technically it may make it a little slower, but as tiny speed changes have almost 0% affect on performance here with Jabba, I can't see why not.

Next version (Working on it for CPT) shall have both variants.

Regards

Richard