KN vs KP - a cautionary tale

[mar]

I still think 8x64 would be enough. It can tabulate the maximum number of steps a Pawn can have to the promotion square to still be unstoppable. My point was more that safeDistance[d8][b6] = 0, (white to move) rather than 2.

Of course, a nice reformulation of the problem.

And I am not sure the presence of the board edge could spoil it. Perhaps it can be tabulated as a function of the Knight location relative to the promotion square safeDistance[knightSqr-promoSqr].

This looks even better I cannot imagine a case where this wouldn't work because the knight can always jump the opposite direction of the edge to achieve the same goal. I hope I'm not missing something here.

Another pitfal is that the fastest Knight trajectory might expose you to capture by the Pawn...

Yes, it's just a heuristics. Still if the knight is too far away to stop the passer, the passer still gets the bonus.
Last question (and perhaps the most important) is if this idea wouble be viable in practice...

[zullil]

[d]

This sounds like a draw, even after Kb5 Nd5 c4 Nb4 Be2 Kd6. What is the PV you think it should win?

Miguel

Stockfish certainly thinks it's a draw:

Code: Select all

0.00 49. Kb5 Nd5 50. c4 Nb4 51. Be2 Kd6 52. Bf3 Ke5 53. Bg2 Kd6 54. Be4 Kd7 55. Bb1 Kd6 56. Bh7 Kd7 57. Be4 Kd6 58. Bg6 Kc7 59. Be8 Kd6 60. Bf7 Ke7 61. Bh5 Kd6 62. Bd1 Ke5 63. Kxc5 Nd3+ 64. Kb5 Kd4 65. Bh5 Nc5 66. Bf7 Nb3 67. Bd5 Nc1 68. Be6 Nb3 69. Bg8 Nc5 70. Bd5 Nb3 71. a6 Nc5 72. Bg8 Ne4 73. Be6 Nc5 74. Bd5 Nd3 75. Bg2 Nc5 76. Bf1 Ne6 77. Kb4 Nc7 78. Ka5 Kc5 79. Bd3 Ne6 80. Bf5 Nc7 81. Bh3 Kxc4 (depth 127, 0:05:23)

[bob]

I have always assumed that it is safe to return 0 as a positional evaluation, when the stronger side has just one minor piece and no pawns. Yesterday, however, my program, playing at 5 minutes + 2 seconds per move voluntarily entered lost ending, betting on KN ve KP being a draw, while the pawn was in fact unstoppable. The problem was further aggravated by hashing in the quiescence search, as the wrong draw score spread through the transposition table, when parents of a "drawn positions" were also wrongly labelled as draws.

It took me a while to understand what is going on, and I was afraid of a program-ruining bug, since not seeing a win for White after Kb5 was outlandish:

[d]

You can see this behaviour in Mini Rodent (https://github.com/nescitus/Rodent_II/b ... %201.0.zip) and see it go away after making GetDrawFactor() (in draw.cpp) always return 64.

This is a dead draw. That's why you should always assume your program is correct and try to prove it wrong, rather than assuming it is wrong.