From: Ronald de Man <ronalddeman@gmail.com>
Date: Sat, 3 May 2014 19:37:24 +0000 (+0200)
Subject: Fix KXK endgame
X-Git-Url: https://git.sesse.net/?p=stockfish;a=commitdiff_plain;h=c0d3010438e9cec2d40dec9e92695b58514497bb;hp=a9e93fa6a56d985e98f16a480a8b0d166fdea324

Fix KXK endgame

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

diff --git a/src/endgame.cpp b/src/endgame.cpp
index 23c546d7..4ee515ad 100644
--- a/src/endgame.cpp
+++ b/src/endgame.cpp
@@ -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;