Pedro Castro wrote:no mate with queen,
67. a8=Q+ Ke3 68. Kb4 Kd4 69. Ka3 Ke3 70. Ka4 Kd4 71. Qb8 Ke3 72. Qg3+ Kd4 73. Kb5 Ke4 74. Kc5 Kf5 75. Kd5 Kf6 76. Kd6 Kf5 77. Qh4 Kg6 78. Ke6 Kg7 79. Qf6+ Kh7 80. Kd6 Kg8 81. Kd5 Kh7 82. Kd6 Kg8 83. Kd5 Kh7 84. Kd6 1/2-1/2
Amazing! I only looked at the part of the game after the pawn promotion (assuming there were no other pieces on the board, i.e. KQK), and it must have had the mate well within its horizon after 79. ... Kh7. In fact I count only 5 ply to mate (7 to king capture):
80. Qg5 Kh8 81. Kf6 Kh7 82. Qg7+
At this stage of the game the search reaches to 8 ply, and the final capture of the moving king should not even count in the depth. But in stead it backs off its king Kd6, which is a very strange move. The line
- Code: Select all
if (p == 4) v += 9 * (e > C ? !((x ^ y) & 68) : -3);
is supposed to provide the mating capability: it ups the score v of a king (p==4) move when the current advantage e is more than ~8 pawns (C) by 9 pts (1 pawn = 99) when the cryptic expression !((x^y)&68) evaluates as true. x is the destination field of the previous ply, y of the current, so the bitwise exclusive or x^y contains 1-bits where these differed, and the &68 (= &0x44) tests the most significant bits of the rank and file bitwise difference, it is zero (and hence ! it is true = 1) if both these bits did not differ between x and y, i.e. if x and y fall in the same 4x4 quarter of the (0x88) board.
The white king thus gets 9 bonuspoints for each move upto the horizon that it can do in the same quarter as the king-to-be-mated, which maks it all the more strange that it steps immeditely out of that quarter! The idea was that once the kings are close enough, the mate would be within the horizon. The few cases I tested, it ated quickly and decisively. Perhaps it got confused here seeing both the mate in 4 and mate in 3, always preferring the former...
I had hoped to prevent that by the line
- Code: Select all
if (v > 1500) v -= 50;
which subtracts ~half a pawn for each move you delay a mate (which is about the only move that scores in this range, but this might be an unsafe technique: I should really adapt the window limits as well to prevent false cutoffs if I fiddle with the score afterwards. Thanks for reporting the bug, I will get to the bottom of this...