KN vs KP - a cautionary tale

[PK]

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] 8/p7/8/P1p1k3/K7/2PBn3/8/8 w - - 6 49 [/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.

[mar]

This is a natural thing to do (scale down) since you want to cover most common cases.
It's natural to make changes that work in most of the cases (=gain elo), you can't possibly cover all anyway (but almost everybody tries

It's odd though that Rodent doesn't see that Kb5 is winning. Does it if it gets more time?
Cheng does this kind of scaling (but I never scale by 0) and Kb5 still rises to +1.38 in ~11 seconds (and continues to rise).
Not sure if this would be fast enough at that TC (my guess is yes), but still.

Are you really sure you fixed the cause this way? What if you instead broke a ton of other positions where it would work well?

[hgm]

Normally you would discount the score of the side that has nothing but a minor by a large factor only when that side is ahead. The minor-only condition doesn't protect you particularly well from losing. And an unstoppable passer is usuall evaluated a lot higher than a measly minor...

Note that even KNKB is not automatically a draw. There is a mateposition, and it can actually be forced. (But not from within KNKB)

[d]7k/4N2b/7K/8/8/8/8/6R1 w
1. Rg8+ Bxg8 2. Ng6#

[mar]

Knights are known to be poor defenders in pawn races, so perhaps one might try to evaluate unstopabble passers even in positions where either side has a knight (or both),
it doesn't have to be n vs p but n+pawns vs pawns.
Question is if it would be worth it and how much complicated it would be. Obviously one could easily pre-compute a table with how many knight moves it would take to reach the queening square of most advanced passer.
EDIT: of course the problem is that tactics may be invoved (knight checks)

[PK]

Rodent 1.7 sees a win after Kb5 all right. In fact, it has won a test game because of that. The problem appeared in a version that is meant to eventually supersede it (and lacks only a couple of Elo right now) I suspect that KN vs KP eval triggers the problem, and the real case is related to quiescence search hashing and/or pruning. Both Rodent 1.7 and developement version hash quiescence nodes, both do check evasions and some basic checks The difference is that Rodent 1.7 switches off delta pruning and bad capture pruning when material is too low. Right now I'm running the test without qs hashing, and intermediate results are encouraging. The next test will be hashing on and qs prunings depending on the remaining material.

@HGM, of course I do not discount the score when the weaker side has only one minor

[mar]

Now that I think about it, it might be worth trying, say you'll only cosider cases where it's k+pawns vs k+knight (or k+knight+pawns) and evaluate unstopabble passer here.
The table can be actually small, i.e. you only need 8x64 (8 queening squares) and index with knight position (just vflip the square if it's black for example, assuming it's computed from white's POV)

[hgm]

You should not just tabulate the number of Knight moves needed to reach the promotion square, though, but also take into account of whether you can stop it earlier. E.g. from b6 to d8 would take four Knight moves, but to d7 only one.

[mar]

You should not just tabulate the number of Knight moves needed to reach the promotion square, though, but also take into account of whether you can stop it earlier. E.g. from b6 to d8 would take four Knight moves, but to d7 only one.

Yes you're right, I forgot that you could block the passer earlier , so the table has to be 48x64 (maybe smaller if one could exploit symmetry), still I don't think this would be a problem in practice because this code would only trigger in a special case.

[hgm]

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.

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].

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

[michiguel]

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] 8/p7/8/P1p1k3/K7/2PBn3/8/8 w - - 6 49 [/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 sounds like a draw, even after Kb5 Nd5 c4 Nb4 Be2 Kd6. What is the PV you think it should win?

Miguel