]> git.sesse.net Git - stockfish/commitdiff
Fix KXK endgame
authorRonald de Man <ronalddeman@gmail.com>
Sat, 3 May 2014 19:37:24 +0000 (21:37 +0200)
committerMarco Costalba <mcostalba@gmail.com>
Sat, 3 May 2014 19:40:09 +0000 (21:40 +0200)
Position is win also if strong side has a bishop
and a knight (plus other material, otherwise
KBNK would be triggered instead of KXK).

This fixes a subtle bug where a search on position

k7/8/8/8/8/P7/PB6/K7 b - - 6 1

Instead of returning a draw score, suddendly returns
a big score. This happens because at one point in
search we reach this position:

8/Pk6/8/8/8/4B3/P7/K7 w - - 3 8

Where white can promote. In case of rook promotion (and also in case of
queen promotion) the resutling position gets a huge static eval that is
above VALUE_KNOWN_WIN (from the point of view of white). So for rook
promotion it is

          &&  futilityBase > -VALUE_KNOWN_WIN

that prevents futility pruning in qsearch. (Removing this condition indeed
lets the problem occur). Raising the static eval for K+B+N+X v K to a value
higher than VALUE_KNOWN_WIN fixes this particular problem without having to
introduce an extra futility pruning condition in qsearch.

I just checked and it seems K+R v K, K+2B v K and even K+B+N v K already get
a huge static eval. Why not K+B+N+P v K?

I think this fix corrects an oversight. There is special code for KBNK, but
KBNXK is handled by KXK, so the test for sufficient material should also test
for B+N.

bench: 8678654

src/endgame.cpp

index 23c546d796dccc914724aa80b938781db2c30fba..4ee515ade71cab5c856f3f6c547d1fd959a8820f 100644 (file)
@@ -166,6 +166,7 @@ Value Endgame<KXK>::operator()(const Position& pos) const {
 
   if (   pos.count<QUEEN>(strongSide)
       || pos.count<ROOK>(strongSide)
+      ||(pos.count<BISHOP>(strongSide) && pos.count<KNIGHT>(strongSide))
       || pos.bishop_pair(strongSide))
       result += VALUE_KNOWN_WIN;