CCRL Discussion Board

I sometimes practice the two knights v pawn ending against Rybka 2.3.2a mp 32-bit native (i.e.with no EGTB attached). This is because Rybka normally plays this ending reasonably well unaided, but will vary the game (as opposed to Wilhelm with an attached EGTB).

I think the superiority of Rybka in this ending over the other chess programs I have (playing native) can only be explained by embedded rules specific to this ending.

However when I played White against Rybka from position C given here (viz. N6k/2p5/2N2K2/8/8/8/8/8 w - - 0 1), the game went.

1. Ne5 Kg8
2. Ke6 c5

You will notice that on move 2, Rybka moves from an obviously drawn position into an obviously lost position.

I am fairly sure from playing Rybka in similar situations that Rybka "recognises" the position after move 2 to be lost for black. If that be the case, the only explanation for its second move is that it also (erroneously) evaluates the position after move 1 as a loss for black.

I think a likely explanation of this is that the program implements a version of the Troitsky line rule similar to, or actually, one of the Wikipedia versions reported in the above link, without adequately covering the exceptional cases.

The source code for Rybka is not generally available, so it's difficult to check in this particular case. Does anyone know of a similar case where a program which is generally competent in knnkp plays crap in position C and the reason is the implementation of a bad version of the Troitsky line rule?

Note that if a version of the Troitsky line rule reading:

If the black pawn stands on or behind the Troitsky line and a white knight stands immediately in front of the pawn and is protected by the other knight, then the position is won for White (and the reverse in colours)

were implemented this would not lead to the play mentioned. I don't think this would introduce any significant performance degredation over incorrect versions either. No code to cover exceptions would be required.

I think the rule could be extended to:

If a white knight stands on the same file as and in front of the black pawn no further forward (from the pawn's point of view) than one square beyond the Troitsky line and it is defended by the other knight from a square that is not both on a file adjacent to the pawn and on a rank strictly ahead of the pawn but behind the first knight, then the position is won for White (and the reverse in colours).

These rules would, of course, not take account of the 50 move rule.

Martin Rattigan wrote:Note that if a version of the Troitsky line rule reading:

If the black pawn stands on or behind the Troitsky line and a white knight stands immediately in front of the pawn and is protected by the other knight, then the position is won for White (and the reverse in colours)

were implemented this would not lead to the play mentioned.

That is not a good rule for a chess evaluation function. With that rule, once the other knight moves away from protecting the blockading knight, the evaluation function will evaluate the position as a draw. The engine will therefore make sure that that other knight continues to protect the blockading knight and, as a result, draw the game.

If an evaluation function evaluates KNNvKP as a draw unless a particular rule applies, then that rule should cover not only selected positions that are known to win, but also all their "successor positions", i.e. the positions on the winning path. So it is not sufficient to limit the rule to selected positions of which you are 100% sure that they win, as that will not enable the engine to actually win these selected positions.

So for an engine the first Troitzky line with a sort of "loose" definition of securely blockading seems very useful. Whether the knight is securely blockading actually does not need to be checked in the evaluation function, as a few plies of search will take care of it.

This approach will not cover all exceptions, but that is inevitable with rules. The alternative is using a tablebase.

The particular exception that is position C is not unreachable, but is quite unlikely to occur in a real game.

I think the rule could be extended to:

If a white knight stands on the same file as and in front of the black pawn no further forward (from the pawn's point of view) than one square beyond the Troitsky line and it is defended by the other knight from a square that is not both on a file adjacent to the pawn and on a rank strictly ahead of the pawn but behind the first knight, then the position is won for White (and the reverse in colours).

I think the term "blockading" already includes the case that the pawn still has a square or more to go before it is stopped (at or before the Troitzky line) by the blockading knight.

I wasn't intending that the engine should assume that only the Troitzky line positions are won. The rule could be used to give a definite evaluation of certain positions, so that a forward search can stop at any such positions without further analysis. Any position where such a position could be forced can also be evaluated as won.

There would have to be other rules used in conjunction with this to make progress. (Possibly a DTM or DTM50 count associated with each Troitzky line position, drawing zones for the black king for each pawn position, increasing plus points for white if the black king is in outside successive octagons surrounding the central 4 squares etc. ... ).

Having worked out how to use the Wihelm analysis functions in the meantime, I realise that another complication is that the rules as I proposed them are wrong. There are still exceptions.

WTM

k7/8/p1N5/NK6/8/8/8/8 w - - 0 1
7k/8/5N1p/6KN/8/8/8/8 w - - 0 1
KN6/2p5/1kN5/8/8/8/8/8 w - - 0 1
6NK/5p2/5Nk1/8/8/8/8/8 w - - 0 1
KN6/p7/Nk6/8/8/8/8/8 w - - 0 1
6NK/7p/6kN/8/8/8/8/8 w - - 0 1

8/8/8/8/p7/Nk6/8/KN6 w - - 0 1
8/8/8/8/7p/6kN/8/6NK w - - 0 1
8/8/8/p7/NK6/2N5/8/k7 w - - 0 1
8/8/8/7p/6KN/5N2/8/7k w - - 0 1

BTM

KN6/2p5/2N5/1k6/8/8/8/8 b - - 0 1
6NK/5p2/5N2/6k1/8/8/8/8 b - - 0 1
KN6/2p5/2N5/2k5/8/8/8/8 b - - 0 1
6NK/5p2/5N2/5k2/8/8/8/8 b - - 0 1
KN6/2p5/2N5/k7/8/8/8/8 b - - 0 1
6NK/5p2/5N2/7k/8/8/8/8 b - - 0 1
KN6/2p5/k1N5/8/8/8/8/8 b - - 0 1
6NK/5p2/5N1k/8/8/8/8/8 b - - 0 1
KN6/p7/N7/1k6/8/8/8/8 b - - 0 1
6NK/7p/7N/6k1/8/8/8/8 - - 0 1
KN6/p7/N7/2k5/8/8/8/8 b - - 0 1
6NK/7p/7N/5k2/8/8/8/8 b - - 0 1
KN6/p7/N7/k7/8/8/8/8 b - - 0 1
6NK/7p/7N/7k/8/8/8/8 b - - 0 1
KN6/p1k5/N7/8/8/8/8/8 b - - 0 1
6NK/5k1p/7N/8/8/8/8/8 b - - 0 1
KN6/p7/N1k5/8/8/8/8/8 b - - 0 1
6NK/7p/5k1N/8/8/8/8/8 b - - 0 1

8/8/8/8/p1k5/N7/8/KN6 b - - 0 1
8/8/8/8/5k1p/7N/8/6NK b - - 0 1
8/8/8/8/p7/N1k5/8/KN6 b - - 0 1
8/8/8/8/7p/7N/5k2/6NK b - - 0 1
8/8/8/8/p7/N7/2k5/KN6 b - - 0 1
8/8/8/8/7p/5k1N/8/6NK b - - 0 1
8/8/8/8/pk6/N7/8/KN6 b - - 0 1
8/8/8/8/6kp/7N/8/6NK b - - 0 1

However these represent only half a dozen situations, so could be practicably incorporated.

Do you not think that the most likely cause of Rybka's bad play in C' is that a version of the Troitzky line rule is implemented in Rybka that evaluates positions like C' as lost for black?

(Sorry about the delay in replying - I didn't notice your inserted text.)

P.S. I would have agreed with your interpretation of "blockaded", but Wikipedia doesn't (https://en.wikipedia.org/wiki/Glossary_of_chess#B).

PPS. The "loose" definition of securely blockaded should fall out in the extended search. If the blockading knight is protected only by the king, White generally must move his other knight to take part (otherwise the Black king cannot be divorced from the blockading knight). If this cannot be done the position is generally drawn.

PPPS. You say, "This approach will not cover all exceptions, but that is inevitable with rules. The alternative is using a tablebase." This is not always true. I think I could write a perfect krk rule based routine for example. It would obviously be harder for knnkp (especially if the 50 move rule is to be enforced). Actually, isn't a tablebase just a rule based approach with a lot of rules anyway?