Draw by insufficient material

[Uri Blass]

WinBoard would not recognize such a draw claim as valid. I did decide against putting that in, because it will not occur in practice, and because doing it would still not cover all draw cases. Because according to FIDE rules a game is draw if no mate is possible, not because of the material that is on the board. So K+4P vs K+4P can also be a legal draw. And it is actually a lot more likely than KBBKB. But there is no way a GUI is going to recognize that, so why bother with KBBKB?

[d] 4k3/8/8/p1p1p1p1/P1P1P1P1/8/8/4K3 w

I disagree with the part that there is no way a GUI is going to recognize it.

It is not trivial but it is possible to write a program to detect blocked positions and George lyapko already did it and based on my memory his lgpgnver detected in engine-engine game one drawn position when one of the programs lost on time in blocked pawn endgame as a draw and corrected the wrong winboard adjudication.

http://www.geocities.com/lyapko/lgpgnver.htm


Uri

[michiguel]

Fide says:

10.4
The game is drawn when one of the following endings arises:

(a)
king against king;
(b)
king against king with only bishop or knight;
(c)
king and bishop against king and bishop, with both bishops on diagonals of the same colour.

This immediately ends the game.

This a new version of FIDE rules:

"b. The game is drawn when a position has arisen in which neither player can checkmate
the opponent’s king with any series of legal moves. The game is said to end in a ‘dead
position’. This immediately ends the game, provided that the move producing the
position was legal."

Miguel

http://www.lawsofchess.com/doc/fide_e.pdf

[Uri Blass]

Fide says:

10.4
The game is drawn when one of the following endings arises:

(a)
king against king;
(b)
king against king with only bishop or knight;
(c)
king and bishop against king and bishop, with both bishops on diagonals of the same colour.

This immediately ends the game.

This a new version of FIDE rules:

"b. The game is drawn when a position has arisen in which neither player can checkmate
the opponent’s king with any series of legal moves. The game is said to end in a ‘dead
position’. This immediately ends the game, provided that the move producing the
position was legal."

Miguel

http://www.lawsofchess.com/doc/fide_e.pdf

Correct
see 5.2b
The rule is written again with different words in 9.6

"The game is drawn when a position is reached from which a checkmate cannot occur by any possible series of legal moves,even with the most unskilled play. This immediately ends the game provided that the move
producing this position was legal."

Uri

[hgm]

In this position, they don't. But I do not believe the "insufficient material to force checkmate" applies. I don't have my rule book here at home, but I suspect the only rule that will apply is the rule about offering/accepting draws...

You old-timers have obsolete rule books!

This tends to happen with books. For the rules as they currently apply, look on the FIDE website.

[Sven]

WinBoard would not recognize such a draw claim as valid. I did decide against putting that in, because it will not occur in practice, and because doing it would still not cover all draw cases. Because according to FIDE rules a game is draw if no mate is possible, not because of the material that is on the board. So K+4P vs K+4P can also be a legal draw. And it is actually a lot more likely than KBBKB. But there is no way a GUI is going to recognize that, so why bother with KBBKB?

Yes, agree, why bother?
To avoid any problems with WinBoard or another GUI I will remove this claim from my engine and let it only claim a draw for K+B vs K+B with B's of the same color.
Not that I ever saw something like K+B vs K+B+B with B's of the same color, but you never know ..

I think the policy should be the other way round. This is my proposal:

1) In general, a GUI should *never* reject an engine's draw claim as "illegal" if it is really a draw according to FIDE chess rules. I would regard it as extremely disappointing if an engine were punished although behaving correctly.

2) In practice it is clear that there are some types of positions (like the KPPPP vs. KPPPP position shown above) for which neither an engine nor a GUI can "easily" and "quickly" detect the draw, from today's viewpoint. Such types of positions should be excluded from the general rule in 1).

3) All regular draw positions where the draw can be seen statically by looking only at the set of pieces present on the board [EDIT: including their square's color, of course ] - not their current squares - should be detected by a GUI, and engines should be allowed to claim a draw in these cases. This would especially include the "KB* vs. KB*" case with all bishops on same color and no other pieces than kings and bishops on the board.

4) "Lazyness" and likelyhood of some positions are no strong arguments for a GUI not to implement all cases of 3). Especially in the "bishops" case I think that it is very easy to have a function that returns a square's color, and to have code that loops over all squares of bishops to find out whether they are all on the same color or not.

If this can be agreed I propose to add the necessary "all bishops on same color" code to WinBoard.

Sven

[Sven]

Also rule 1.3 has the same contents:

"If the position is such that neither player can possibly checkmate, the game is drawn."

So in fact there are three paragraphs in the current FIDE rules (valid since 1-jul-2005) stating the same, and covering both special cases that have been mentioned in this thread (the KPPPP-KPPPP case and the KB*-KB* case).

Sven

[Sven]

Additionally, both GUIs and (if they like) engines could also handle the case KB-K as a trivial case of "KB*-KB* with all bishops on same color", and therefore remove the special code for KB-K. Furthermore, even K-K would fit when implemented well , so only two cases are left (the other is KN-K).

Sven

[hgm]

My original philosophy was this:

The FIDE rules include cases that are more complicated than I care to recognize. So the protocol will have to define which draws you can claim, and which not, e.g. by making a list of those you are allowed to claim. For the sake of clarity, it is better if the list is short. Initially, I did not even include KBKB on that list, but it turned out some engines did claim this (with like Bishops), so I added it later. So the list now consists of KK, KNK, KBK, KBKB(like).

In the second place, it is a bit pedantic that engines want to claim rarely occurring quirks, like KBBKB (like) or the KPPPPKPPPP above. The game has legally ended, and they should trust the GUI to terminate it. If they really want to be smart, they should realize that if the GUI does not terminate it, it probably does not recognize it as a draw, and claiming it will just cause trouble. The sensible action in this situation would be to offer a draw, and hope that the opponent is smarter than the GUI and will take it.

[Sven]

My original philosophy was this:

The FIDE rules include cases that are more complicated than I care to recognize. So the protocol will have to define which draws you can claim, and which not, e.g. by making a list of those you are allowed to claim. For the sake of clarity, it is better if the list is short. Initially, I did not even include KBKB on that list, but it turned out some engines did claim this (with like Bishops), so I added it later. So the list now consists of KK, KNK, KBK, KBKB(like).

In the second place, it is a bit pedantic that engines want to claim rarely occurring quirks, like KBBKB (like) or the KPPPPKPPPP above. The game has legally ended, and they should trust the GUI to terminate it. If they really want to be smart, they should realize that if the GUI does not terminate it, it probably does not recognize it as a draw, and claiming it will just cause trouble. The sensible action in this situation would be to offer a draw, and hope that the opponent is smarter than the GUI and will take it.

As you wrote, WinBoard is already able to detect KBKB(like) so I think that the step towards detecting KB*KB*(like) - which also includes KK and KBK as I already mentioned in a previous post! - is really small. Give it a try!

Since detection of draw cases like that KPPPPKPPPP is obviously a bit more complex I still agree to exclude these and draw the borderline below them, although I would not agree to the statement that these cases are rare.

Sven

[hgm]

I am sure I would have no problems programming it. But I don't think a desicion about which claims to accept and which to reject should be taken unilaterally. Otherwise we get into a situation where some claims are rejected by WinBoard but OK on, say Arena or ChessGUI, while others are accepted by WinBoard but lead to a forfeit with, say, Arena. Engine authors should know very clearly what they are not supposed to claim, so they don't get unpleasant surprises if their program is working with another GUI as the one they developed it with.

So I would welcome comments from other GUI developers, to see if we can get some consensus on where exactly to draw the line.

As to how rare exactly the cases like the KPPPPKPPPP above are, I already remarked that this IMO would be much more frequent than KBBKB(all like). This was in fact an important reason for me to not worry about KBBKB at all. If I could make things 100% perfect by repairing a 0.001% error, I would certainly do it. But if such a repair would merely reduce the error rate from 0.1% to 0.099%, it serves no purpose.