Consider the following position with white to move
1. Rc8 is very tempting but only draws, after
1. ... Ra7 2. Ke8 Rxd7 3. Kxd7 we reach the following KRKP endgame, which is a draw
iCE did not know that. In fact iCE selected the move 1. Rd1+, but this is also only a draw after 1. ... Ke4. So while the endgame is not even on the board the lack of knowledge let play iCE the wrong move. I run a search for several hours, iCE was still happy with 1. Rd1+. And of course it makes no sense to optimize towards a single position, the underlying knowledge problem must be solved.
There are a lot of winning positions for the pawn side if the pawn is already on the 6th or 7th rank. Here the rook is not able to stop the pawn from promoting and where the pawn side then wins the Queen vs Rook endgame. But sometimes the pawn safely promotes but the rook side is able to force a stalemate or give permanent checks. So finding out the pawn will promote is not enough for classifying it as a win.
If the pawn is not advanced the rook side might not be able to stop it without sacrificing the rook which leads to a draw.
In general one can state for this endgame
- Usually the rook side is able to stop the pawn
- If the attacker king is in front of the pawn the attacker will win
- If the pawn gets support from its own king and the attacker king is away and behind the pawn the pawn side might be able to draw.
- If the pawn is already on the 7th and sometimes on the 6th (with the pawn side to move) it might be able to promote and win
- There are hard to spot exceptions for both sides.
First I implemented a method to detect the wins for the pawn side. This method detects the trivial cases where the rook is immediately captured and the resulting KPK endgame is won, but also the non trivial ones where the pawn is able to promote and the queen survives (without stalemating the other king). The detector must handle the 3 non trivial cases
- the pawn is on the 7th and the pawn side moves
- the pawn is on the 7th and the rook side moves
- the pawn is on the 6th and the pawn side moves
Only about 6000 positions make up the 2nd case. I tried hard to assemble some rules for that but at the end I gave up and also store them explicitly. The 3rd case is easy then. To win the pawn must move and we can look whether we have stored the resulting position for case number 2.
So this method detects 100% the pawn wins with a small internal database and a few complex rules.
Next I require a 2nd method that detects the drawn positions which is called only if we see that the position is not a win for the pawn obviously.
Theory states to count the tempi for the pawn side to promote with king support and the rook side to control the promotion square with both rook and king. If the pawn side requires less tempi than the rook side it is a draw. This is maybe a good rule of thumb for a human but it is not a correct rule for a computer. It will announce a lot of false draws. So I tried another approach.
Whether a position is drawn depends mainly on the pawn and king positions and less on the position of the rook. I assembled a small internal database of about 2600 records (each 2 byte) that contain those king and pawn positions that are drawn no matter where the rook stands or whose side to move it is. With those 2600 records I'm able to detect 700k out of 1.2M drawn positions.
I decided to stop here, this is good enough.
So after all that efforts I wanted to see whether it helped iCE to find a better move in the above position and voila it actually did. It sticks to the winning move realizing that the alternatives will draw. It is even able to announce the correct distance to mate.
I like it when something works !