1
0
Fork 0
stockfish/src/evaluate.cpp

951 lines
36 KiB
C++
Raw Normal View History

2008-08-31 23:59:13 -06:00
/*
Stockfish, a UCI chess playing engine derived from Glaurung 2.1
Copyright (C) 2004-2008 Tord Romstad (Glaurung author)
Copyright (C) 2008-2015 Marco Costalba, Joona Kiiski, Tord Romstad
Copyright (C) 2015-2018 Marco Costalba, Joona Kiiski, Gary Linscott, Tord Romstad
2008-08-31 23:59:13 -06:00
Stockfish is free software: you can redistribute it and/or modify
2008-08-31 23:59:13 -06:00
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
Stockfish is distributed in the hope that it will be useful,
2008-08-31 23:59:13 -06:00
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
2008-08-31 23:59:13 -06:00
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include <algorithm>
2008-08-31 23:59:13 -06:00
#include <cassert>
#include <cstring> // For std::memset
#include <iomanip>
#include <sstream>
2008-08-31 23:59:13 -06:00
#include "bitboard.h"
2008-08-31 23:59:13 -06:00
#include "evaluate.h"
#include "material.h"
#include "pawns.h"
Use per-thread dynamic contempt We now use per-thread dynamic contempt. This patch has the following effects: * for Threads=1: **non-functional** * for Threads>1: * with MultiPV=1: **no regression, little to no ELO gain** * with MultiPV>1: **clear improvement over master** First, I tried testing at standard MultiPV=1 play with [0,5] bounds. This yielded 2 yellow and 1 red test: 5+0.05, Threads=5: LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 82689 W: 16439 L: 16190 D: 50060 http://tests.stockfishchess.org/tests/view/5aa93a5a0ebc5902952892e6 5+0.05, Threads=8: LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 27164 W: 4974 L: 4983 D: 17207 http://tests.stockfishchess.org/tests/view/5ab2639b0ebc5902a6fbefd5 5+0.5, Threads=16: LLR: -2.97 (-2.94,2.94) [0.00,5.00] Total: 41396 W: 7127 L: 7082 D: 27187 http://tests.stockfishchess.org/tests/view/5ab124220ebc59029516cb62 Then, I tested with Skill Level=17 (implicitly MutliPV=4), showing a clear improvement: 5+0.05, Threads=5: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 3498 W: 1316 L: 1135 D: 1047 http://tests.stockfishchess.org/tests/view/5ab4b6580ebc5902932aeca2 Next, I tested the patch with MultiPV=1 again, this time checking for non-regression ([-3, 1]): 5+0.5, Threads=5: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 65575 W: 12786 L: 12745 D: 40044 http://tests.stockfishchess.org/tests/view/5ab4e8500ebc5902932aecb3 Finally, I ran some tests with fixed number of games, checking if reverting dynamic contempt gains more elo with Skill Level=17 (i.e. MultiPV) than applying the "prevScore" fix and this patch. These tests showed, that this patch gains 15 ELO when playing with Skill Level=17: 5+0.05, Threads=3, "revert dynamic contempt" vs. "WITHOUT this patch": ELO: -11.43 +-4.1 (95%) LOS: 0.0% Total: 20000 W: 7085 L: 7743 D: 5172 http://tests.stockfishchess.org/tests/view/5ab636450ebc590295d88536 5+0.05, Threads=3, "revert dynamic contempt" vs. "WITH this patch": ELO: -26.42 +-4.1 (95%) LOS: 0.0% Total: 20000 W: 6661 L: 8179 D: 5160 http://tests.stockfishchess.org/tests/view/5ab62e680ebc590295d88524 --- ***FAQ*** **Why should this be commited?** I believe that the gain for multi-thread MultiPV search is a sufficient justification for this otherwise neutral change. I also believe this implementation of dynamic contempt is more logical, although this may be just my opinion. **Why is per-thread contempt better at MultiPV?** A likely explanation for the gain in MultiPV mode is that during search each thread independently switches between rootMoves and via the shared contempt score skews each other's evaluation. **Why were the tests done with Skill Level=17?** This was originally suggested by @Hanamuke and the idea is that with Skill Level Stockfish sometimes plays also moves it thinks are slightly sub-optimal and thus the quality of all moves offered by the MultiPV search is checked by the test. **Why are the ELO differences so huge?** This is most likely because of the nature of Skill Level mode -- since it slower and weaker than normal mode, bugs in evaluation have much greater effect. --- Closes https://github.com/official-stockfish/Stockfish/pull/1515. No functional change -- in single thread mode.
2018-03-30 02:47:05 -06:00
#include "thread.h"
namespace Trace {
enum Tracing { NO_TRACE, TRACE };
enum Term { // The first 8 entries are reserved for PieceType
MATERIAL = 8, IMBALANCE, MOBILITY, THREAT, PASSED, SPACE, INITIATIVE, TOTAL, TERM_NB
};
Score scores[TERM_NB][COLOR_NB];
double to_cp(Value v) { return double(v) / PawnValueEg; }
void add(int idx, Color c, Score s) {
scores[idx][c] = s;
}
void add(int idx, Score w, Score b = SCORE_ZERO) {
scores[idx][WHITE] = w;
scores[idx][BLACK] = b;
}
std::ostream& operator<<(std::ostream& os, Score s) {
os << std::setw(5) << to_cp(mg_value(s)) << " "
<< std::setw(5) << to_cp(eg_value(s));
return os;
}
std::ostream& operator<<(std::ostream& os, Term t) {
if (t == MATERIAL || t == IMBALANCE || t == INITIATIVE || t == TOTAL)
os << " ---- ----" << " | " << " ---- ----";
else
os << scores[t][WHITE] << " | " << scores[t][BLACK];
os << " | " << scores[t][WHITE] - scores[t][BLACK] << "\n";
return os;
}
}
using namespace Trace;
namespace {
constexpr Bitboard QueenSide = FileABB | FileBBB | FileCBB | FileDBB;
constexpr Bitboard CenterFiles = FileCBB | FileDBB | FileEBB | FileFBB;
constexpr Bitboard KingSide = FileEBB | FileFBB | FileGBB | FileHBB;
constexpr Bitboard Center = (FileDBB | FileEBB) & (Rank4BB | Rank5BB);
constexpr Bitboard KingFlank[FILE_NB] = {
QueenSide, QueenSide, QueenSide,
CenterFiles, CenterFiles,
KingSide, KingSide, KingSide
};
// Threshold for lazy and space evaluation
constexpr Value LazyThreshold = Value(1500);
constexpr Value SpaceThreshold = Value(12222);
// KingAttackWeights[PieceType] contains king attack weights by piece type
constexpr int KingAttackWeights[PIECE_TYPE_NB] = { 0, 0, 78, 56, 45, 11 };
// Penalties for enemy's safe checks
constexpr int QueenSafeCheck = 780;
constexpr int RookSafeCheck = 880;
constexpr int BishopSafeCheck = 435;
constexpr int KnightSafeCheck = 790;
#define S(mg, eg) make_score(mg, eg)
2008-08-31 23:59:13 -06:00
// MobilityBonus[PieceType-2][attacked] contains bonuses for middle and end game,
// indexed by piece type and number of attacked squares in the mobility area.
constexpr Score MobilityBonus[][32] = {
{ S(-75,-76), S(-57,-54), S( -9,-28), S( -2,-10), S( 6, 5), S( 14, 12), // Knights
S( 22, 26), S( 29, 29), S( 36, 29) },
{ S(-48,-59), S(-20,-23), S( 16, -3), S( 26, 13), S( 38, 24), S( 51, 42), // Bishops
S( 55, 54), S( 63, 57), S( 63, 65), S( 68, 73), S( 81, 78), S( 81, 86),
S( 91, 88), S( 98, 97) },
{ S(-58,-76), S(-27,-18), S(-15, 28), S(-10, 55), S( -5, 69), S( -2, 82), // Rooks
S( 9,112), S( 16,118), S( 30,132), S( 29,142), S( 32,155), S( 38,165),
S( 46,166), S( 48,169), S( 58,171) },
{ S(-39,-36), S(-21,-15), S( 3, 8), S( 3, 18), S( 14, 34), S( 22, 54), // Queens
S( 28, 61), S( 41, 73), S( 43, 79), S( 48, 92), S( 56, 94), S( 60,104),
S( 60,113), S( 66,120), S( 67,123), S( 70,126), S( 71,133), S( 73,136),
S( 79,140), S( 88,143), S( 88,148), S( 99,166), S(102,170), S(102,175),
S(106,184), S(109,191), S(113,206), S(116,212) }
2008-08-31 23:59:13 -06:00
};
// Outpost[knight/bishop][supported by pawn] contains bonuses for minor
// pieces if they occupy or can reach an outpost square, bigger if that
// square is supported by a pawn.
constexpr Score Outpost[][2] = {
{ S(22, 6), S(36,12) }, // Knight
{ S( 9, 2), S(15, 5) } // Bishop
};
// RookOnFile[semiopen/open] contains bonuses for each rook when there is
// no (friendly) pawn on the rook file.
constexpr Score RookOnFile[] = { S(20, 7), S(45, 20) };
// ThreatByMinor/ByRook[attacked PieceType] contains bonuses according to
// which piece type attacks which one. Attacks on lesser pieces which are
// pawn-defended are not considered.
constexpr Score ThreatByMinor[PIECE_TYPE_NB] = {
S(0, 0), S(0, 31), S(39, 42), S(57, 44), S(68, 112), S(47, 120)
};
constexpr Score ThreatByRook[PIECE_TYPE_NB] = {
S(0, 0), S(0, 24), S(38, 71), S(38, 61), S(0, 38), S(36, 38)
};
// ThreatByKing[on one/on many] contains bonuses for king attacks on
// pawns or pieces which are not pawn-defended.
constexpr Score ThreatByKing[] = { S(3, 65), S(9, 145) };
// PassedRank[Rank] contains a bonus according to the rank of a passed pawn
constexpr Score PassedRank[RANK_NB] = {
S(0, 0), S(5, 7), S(5, 13), S(32, 42), S(70, 70), S(172, 170), S(217, 269)
};
// PassedFile[File] contains a bonus according to the file of a passed pawn
constexpr Score PassedFile[FILE_NB] = {
S( 9, 10), S(2, 10), S(1, -8), S(-20,-12),
S(-20,-12), S(1, -8), S(2, 10), S( 9, 10)
};
// PassedDanger[Rank] contains a term to weight the passed score
constexpr int PassedDanger[RANK_NB] = { 0, 0, 0, 2, 7, 12, 19 };
// KingProtector[PieceType-2] contains a penalty according to distance from king
constexpr Score KingProtector[] = { S(3, 5), S(4, 3), S(3, 0), S(1, -1) };
// Assorted bonuses and penalties
constexpr Score BishopPawns = S( 8, 12);
constexpr Score CloseEnemies = S( 7, 0);
constexpr Score Connectivity = S( 3, 1);
constexpr Score CorneredBishop = S( 50, 50);
constexpr Score Hanging = S( 52, 30);
constexpr Score HinderPassedPawn = S( 8, 1);
constexpr Score KnightOnQueen = S( 21, 11);
constexpr Score LongDiagonalBishop = S( 22, 0);
constexpr Score MinorBehindPawn = S( 16, 0);
Introduce Overload This patch applies a S(10, 5) bonus for every square that is: - Occupied by an enemy piece which is not a pawn - Attacked exactly once by our pieces - Defended exactly once by enemy pieces The idea is that these pieces must be defended. Their defenders have dramatically limited mobility, and they are vulnerable to our future attack. As with connectivity, there are probably many more tests to be run in this area. In particular: - I believe @snicolet's queen overload tests have demonstrated a potential need for a queen overload bonus above and beyond this one; however, the conditions for "overload" in this patch are different (excluding pieces we attack twice). My next test after this is (hopefully) merged will be to intersect the Bitboard I define here with the enemy's queen attacks and attempt to give additional bonus. - Perhaps we should exclude pieces attacked by pawns--can pawns really be overloaded? Should they have the same weight, or less? This didn't work with a previous version, but it could work with this one. - More generally, different pieces may need more or less bonus. We could change bonuses based on what type of enemy piece is being overloaded, what type of friendly piece is attacking, and/or what type of piece is being defended by the overloaded piece and attacked by us, or any intersection of these three. For example, here attacked/defended pawns are excluded, but they're not totally worthless targets, and could be added again with a smaller bonus. - This list is by no means exhaustive. STC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 17439 W: 3599 L: 3390 D: 10450 http://tests.stockfishchess.org/tests/view/5ac78a2e0ebc59435923735e LTC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 43304 W: 6533 L: 6256 D: 30515 http://tests.stockfishchess.org/tests/view/5ac7a1d80ebc59435923736f Closes https://github.com/official-stockfish/Stockfish/pull/1533 Bench: 5248871 ---------------- This is my first time opening a PR, so I apologize if there are errors. There are too many people to thank since I submitted my first test just over a month ago. Thank you all for the warm welcome and here is to more green patches! In particular, I would like to thank: - @crossbr, whose comment in a FishCooking thread first inspired me to consider the overloading of pieces other than queens, - @snicolet, whose queen overload tests inspired this one and served as the base of my first overload attempts, - @protonspring, whose connectivity tests inspired this one and who provided much of the feedback needed to take this from red to green, - @vondele, who kindly corrected me when I submitted a bad LTC test, - @Rocky640, who has helped me over and over again in the past month. Thank you all!
2018-04-06 17:20:48 -06:00
constexpr Score Overload = S( 10, 5);
constexpr Score PawnlessFlank = S( 20, 80);
constexpr Score RookOnPawn = S( 8, 24);
constexpr Score SliderOnQueen = S( 42, 21);
constexpr Score ThreatByPawnPush = S( 47, 26);
constexpr Score ThreatByRank = S( 16, 3);
constexpr Score ThreatBySafePawn = S(175,168);
constexpr Score TrappedRook = S( 92, 0);
constexpr Score WeakQueen = S( 50, 10);
constexpr Score WeakUnopposedPawn = S( 5, 25);
#undef S
// Evaluation class computes and stores attacks tables and other working data
template<Tracing T>
class Evaluation {
2012-03-21 06:19:21 -06:00
public:
Evaluation() = delete;
explicit Evaluation(const Position& p) : pos(p) {}
Evaluation& operator=(const Evaluation&) = delete;
Value value();
private:
template<Color Us> void initialize();
template<Color Us, PieceType Pt> Score pieces();
template<Color Us> Score king() const;
template<Color Us> Score threats() const;
template<Color Us> Score passed() const;
template<Color Us> Score space() const;
ScaleFactor scale_factor(Value eg) const;
Score initiative(Value eg) const;
const Position& pos;
Material::Entry* me;
Pawns::Entry* pe;
Bitboard mobilityArea[COLOR_NB];
Score mobility[COLOR_NB] = { SCORE_ZERO, SCORE_ZERO };
// attackedBy[color][piece type] is a bitboard representing all squares
// attacked by a given color and piece type. Special "piece types" which
// is also calculated is ALL_PIECES.
Bitboard attackedBy[COLOR_NB][PIECE_TYPE_NB];
// attackedBy2[color] are the squares attacked by 2 pieces of a given color,
// possibly via x-ray or by one pawn and one piece. Diagonal x-ray through
// pawn or squares attacked by 2 pawns are not explicitly added.
Bitboard attackedBy2[COLOR_NB];
// kingRing[color] are the squares adjacent to the king, plus (only for a
// king on its first rank) the squares two ranks in front. For instance,
// if black's king is on g8, kingRing[BLACK] is f8, h8, f7, g7, h7, f6, g6
// and h6. It is set to 0 when king safety evaluation is skipped.
Bitboard kingRing[COLOR_NB];
// kingAttackersCount[color] is the number of pieces of the given color
// which attack a square in the kingRing of the enemy king.
int kingAttackersCount[COLOR_NB];
// kingAttackersWeight[color] is the sum of the "weights" of the pieces of
// the given color which attack a square in the kingRing of the enemy king.
// The weights of the individual piece types are given by the elements in
// the KingAttackWeights array.
int kingAttackersWeight[COLOR_NB];
// kingAttacksCount[color] is the number of attacks by the given color to
// squares directly adjacent to the enemy king. Pieces which attack more
// than one square are counted multiple times. For instance, if there is
// a white knight on g5 and black's king is on g8, this white knight adds 2
// to kingAttacksCount[WHITE].
int kingAttacksCount[COLOR_NB];
};
// Evaluation::initialize() computes king and pawn attacks, and the king ring
// bitboard for a given color. This is done at the beginning of the evaluation.
template<Tracing T> template<Color Us>
void Evaluation<T>::initialize() {
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
constexpr Direction Up = (Us == WHITE ? NORTH : SOUTH);
constexpr Direction Down = (Us == WHITE ? SOUTH : NORTH);
constexpr Bitboard LowRanks = (Us == WHITE ? Rank2BB | Rank3BB: Rank7BB | Rank6BB);
// Find our pawns that are blocked or on the first two ranks
Bitboard b = pos.pieces(Us, PAWN) & (shift<Down>(pos.pieces()) | LowRanks);
// Squares occupied by those pawns, by our king, or controlled by enemy pawns
// are excluded from the mobility area.
mobilityArea[Us] = ~(b | pos.square<KING>(Us) | pe->pawn_attacks(Them));
// Initialise attackedBy bitboards for kings and pawns
attackedBy[Us][KING] = pos.attacks_from<KING>(pos.square<KING>(Us));
attackedBy[Us][PAWN] = pe->pawn_attacks(Us);
attackedBy[Us][ALL_PIECES] = attackedBy[Us][KING] | attackedBy[Us][PAWN];
attackedBy2[Us] = attackedBy[Us][KING] & attackedBy[Us][PAWN];
// Init our king safety tables only if we are going to use them
if (pos.non_pawn_material(Them) >= RookValueMg + KnightValueMg)
{
kingRing[Us] = attackedBy[Us][KING];
if (relative_rank(Us, pos.square<KING>(Us)) == RANK_1)
kingRing[Us] |= shift<Up>(kingRing[Us]);
if (file_of(pos.square<KING>(Us)) == FILE_H)
kingRing[Us] |= shift<WEST>(kingRing[Us]);
else if (file_of(pos.square<KING>(Us)) == FILE_A)
kingRing[Us] |= shift<EAST>(kingRing[Us]);
kingAttackersCount[Them] = popcount(attackedBy[Us][KING] & pe->pawn_attacks(Them));
kingAttacksCount[Them] = kingAttackersWeight[Them] = 0;
}
else
kingRing[Us] = kingAttackersCount[Them] = 0;
}
// Evaluation::pieces() scores pieces of a given color and type
template<Tracing T> template<Color Us, PieceType Pt>
Score Evaluation<T>::pieces() {
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
constexpr Bitboard OutpostRanks = (Us == WHITE ? Rank4BB | Rank5BB | Rank6BB
: Rank5BB | Rank4BB | Rank3BB);
const Square* pl = pos.squares<Pt>(Us);
2008-08-31 23:59:13 -06:00
Bitboard b, bb;
Square s;
Score score = SCORE_ZERO;
Remove the Queen from the mobility area of minor pieces In master, we already remove the King from the mobility area of minor pieces because the King simply stands in the way of other pieces, and since opponent cannot capture the King, any piece which "protects" the King cannot recapture. Similarly, this patch introduces the idea that it is rarely a need for a Queen to be "protected" by a minor (unless it is attacked only by a Queen, in fact). We used to have a LoosePiece bonus, and in a similar vein the Queen was excluded from that penalty. Idea came when reviewing an old game of Kholmov. He was a very good midgame player, but in the opening his misplace his Queen (and won in the end :-) : http://www.chessgames.com/perl/chessgame?gid=1134645 Both white queen moves 10.Qd3 and 13.Qb3 are in the way of some minor piece. I would prefer to not give a bishop mobility bonus at move 10 for the square d3, or later a knight mobility bonus at move 13 for the square b3. And the textbook move is 19.Qe3! which prepares 20.Nb3. This short game sample shows how much a queen can be "in the way" of minor pieces. STC http://tests.stockfishchess.org/tests/view/5ac2c15f0ebc591746423fa3 LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 22066 W: 4561 L: 4330 D: 13175 LTC http://tests.stockfishchess.org/tests/view/5ac2d6500ebc591746423faf LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 25871 W: 3953 L: 3738 D: 18180 Closes https://github.com/official-stockfish/Stockfish/pull/1532 Ideas for future work in this area: • tweak some more mobility areas for other piece type. • construct a notion of global mobility for the whole piece set. • bad bishops. Bench: 4989125
2018-04-03 15:55:52 -06:00
int mob;
attackedBy[Us][Pt] = 0;
while ((s = *pl++) != SQ_NONE)
{
// Find attacked squares, including x-ray attacks for bishops and rooks
b = Pt == BISHOP ? attacks_bb<BISHOP>(s, pos.pieces() ^ pos.pieces(QUEEN))
: Pt == ROOK ? attacks_bb< ROOK>(s, pos.pieces() ^ pos.pieces(QUEEN) ^ pos.pieces(Us, ROOK))
: pos.attacks_from<Pt>(s);
if (pos.blockers_for_king(Us) & s)
b &= LineBB[pos.square<KING>(Us)][s];
attackedBy2[Us] |= attackedBy[Us][ALL_PIECES] & b;
attackedBy[Us][Pt] |= b;
attackedBy[Us][ALL_PIECES] |= b;
if (b & kingRing[Them])
{
kingAttackersCount[Us]++;
kingAttackersWeight[Us] += KingAttackWeights[Pt];
kingAttacksCount[Us] += popcount(b & attackedBy[Them][KING]);
}
Remove the Queen from the mobility area of minor pieces In master, we already remove the King from the mobility area of minor pieces because the King simply stands in the way of other pieces, and since opponent cannot capture the King, any piece which "protects" the King cannot recapture. Similarly, this patch introduces the idea that it is rarely a need for a Queen to be "protected" by a minor (unless it is attacked only by a Queen, in fact). We used to have a LoosePiece bonus, and in a similar vein the Queen was excluded from that penalty. Idea came when reviewing an old game of Kholmov. He was a very good midgame player, but in the opening his misplace his Queen (and won in the end :-) : http://www.chessgames.com/perl/chessgame?gid=1134645 Both white queen moves 10.Qd3 and 13.Qb3 are in the way of some minor piece. I would prefer to not give a bishop mobility bonus at move 10 for the square d3, or later a knight mobility bonus at move 13 for the square b3. And the textbook move is 19.Qe3! which prepares 20.Nb3. This short game sample shows how much a queen can be "in the way" of minor pieces. STC http://tests.stockfishchess.org/tests/view/5ac2c15f0ebc591746423fa3 LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 22066 W: 4561 L: 4330 D: 13175 LTC http://tests.stockfishchess.org/tests/view/5ac2d6500ebc591746423faf LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 25871 W: 3953 L: 3738 D: 18180 Closes https://github.com/official-stockfish/Stockfish/pull/1532 Ideas for future work in this area: • tweak some more mobility areas for other piece type. • construct a notion of global mobility for the whole piece set. • bad bishops. Bench: 4989125
2018-04-03 15:55:52 -06:00
mob = (Pt == KNIGHT || Pt == BISHOP) ? popcount(b & mobilityArea[Us] & ~pos.pieces(Us, QUEEN))
: popcount(b & mobilityArea[Us]);
mobility[Us] += MobilityBonus[Pt - 2][mob];
// Penalty if the piece is far from the king
score -= KingProtector[Pt - 2] * distance(s, pos.square<KING>(Us));
if (Pt == BISHOP || Pt == KNIGHT)
{
// Bonus if piece is on an outpost square or can reach one
bb = OutpostRanks & ~pe->pawn_attacks_span(Them);
if (bb & s)
score += Outpost[Pt == BISHOP][bool(attackedBy[Us][PAWN] & s)] * 2;
else if (bb &= b & ~pos.pieces(Us))
score += Outpost[Pt == BISHOP][bool(attackedBy[Us][PAWN] & bb)];
// Bonus when behind a pawn
if ( relative_rank(Us, s) < RANK_5
&& (pos.pieces(PAWN) & (s + pawn_push(Us))))
score += MinorBehindPawn;
if (Pt == BISHOP)
{
// Penalty according to number of pawns on the same color square as the bishop
score -= BishopPawns * pe->pawns_on_same_color_squares(Us, s);
// Bonus for bishop on a long diagonal which can "see" both center squares
if (more_than_one(Center & (attacks_bb<BISHOP>(s, pos.pieces(PAWN)) | s)))
score += LongDiagonalBishop;
}
// An important Chess960 pattern: A cornered bishop blocked by a friendly
// pawn diagonally in front of it is a very serious problem, especially
// when that pawn is also blocked.
if ( Pt == BISHOP
&& pos.is_chess960()
&& (s == relative_square(Us, SQ_A1) || s == relative_square(Us, SQ_H1)))
{
Direction d = pawn_push(Us) + (file_of(s) == FILE_A ? EAST : WEST);
if (pos.piece_on(s + d) == make_piece(Us, PAWN))
score -= !pos.empty(s + d + pawn_push(Us)) ? CorneredBishop * 4
: pos.piece_on(s + d + d) == make_piece(Us, PAWN) ? CorneredBishop * 2
: CorneredBishop;
}
}
2008-08-31 23:59:13 -06:00
if (Pt == ROOK)
{
Document Elo impact of various parts of search In order to understand better the impact of various techniques used in search, Elo estimates have been run at STC for 60000 games (statistical error ~1.8 Elo), disabling each feature in turn. This should help future improvements and simplifications to pick suitable targets. The list of tests is: step 7 : http://tests.stockfishchess.org/tests/view/5abcbb4b0ebc5902926cf1ca step 8 : http://tests.stockfishchess.org/tests/view/5abcbb680ebc5902926cf1cc step 9 : http://tests.stockfishchess.org/tests/view/5abcbb850ebc5902926cf1ce step 10 : http://tests.stockfishchess.org/tests/view/5abcbbeb0ebc5902926cf1d2 step 11 : http://tests.stockfishchess.org/tests/view/5abcbbbf0ebc5902926cf1d0 step 13 : http://tests.stockfishchess.org/tests/view/5abd03680ebc5902926cf20b step 13a: http://tests.stockfishchess.org/tests/view/5abd29660ebc5902926cf22a step 13b: http://tests.stockfishchess.org/tests/view/5abd29820ebc5902926cf22c step 14 : http://tests.stockfishchess.org/tests/view/5abd03860ebc5902926cf20f step 14a: http://tests.stockfishchess.org/tests/view/5abd2b6c0ebc5902926cf230 step 14b: http://tests.stockfishchess.org/tests/view/5abd2b8d0ebc5902926cf232 step 14c: http://tests.stockfishchess.org/tests/view/5abd2bad0ebc5902926cf234 step 14d: http://tests.stockfishchess.org/tests/view/5abd2bcf0ebc5902926cf236 step 14e: http://tests.stockfishchess.org/tests/view/5abd2bf10ebc5902926cf238 This patch documents this in the code. Note that it will be a waste to recompute these estimates often, even a couple of [0,5] patches are unlikely to change them by more than the error bars. The interest of the Elo annotations in the code is not in the details, but in high- lighting trends such as razoring (2 Elo) and singular extensions (60 Elo). These estimates should be recomputed at most once a year. Closes https://github.com/official-stockfish/Stockfish/pull/1522 No functional change.
2018-03-31 19:13:29 -06:00
// Bonus for aligning rook with enemy pawns on the same rank/file
if (relative_rank(Us, s) >= RANK_5)
score += RookOnPawn * popcount(pos.pieces(Them, PAWN) & PseudoAttacks[ROOK][s]);
// Bonus for rook on an open or semi-open file
if (pe->semiopen_file(Us, file_of(s)))
score += RookOnFile[bool(pe->semiopen_file(Them, file_of(s)))];
// Penalty when trapped by the king, even more if the king cannot castle
else if (mob <= 3)
{
File kf = file_of(pos.square<KING>(Us));
if ((kf < FILE_E) == (file_of(s) < kf))
score -= (TrappedRook - make_score(mob * 22, 0)) * (1 + !pos.can_castle(Us));
}
2008-08-31 23:59:13 -06:00
}
if (Pt == QUEEN)
{
// Penalty if any relative pin or discovered attack against the queen
Bitboard queenPinners;
if (pos.slider_blockers(pos.pieces(Them, ROOK, BISHOP), s, queenPinners))
score -= WeakQueen;
}
}
if (T)
Trace::add(Pt, Us, score);
return score;
}
2008-08-31 23:59:13 -06:00
// Evaluation::king() assigns bonuses and penalties to a king of a given color
template<Tracing T> template<Color Us>
Score Evaluation<T>::king() const {
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
constexpr Bitboard Camp = (Us == WHITE ? AllSquares ^ Rank6BB ^ Rank7BB ^ Rank8BB
: AllSquares ^ Rank1BB ^ Rank2BB ^ Rank3BB);
const Square ksq = pos.square<KING>(Us);
Bitboard weak, b, b1, b2, safe, unsafeChecks, pinned;
2008-08-31 23:59:13 -06:00
// King shelter and enemy pawns storm
Score score = pe->king_safety<Us>(pos, ksq);
2008-08-31 23:59:13 -06:00
// Main king safety evaluation
if (kingAttackersCount[Them] > 1 - pos.count<QUEEN>(Them))
{
int kingDanger = 0;
unsafeChecks = 0;
// Attacked squares defended at most once by our queen or king
weak = attackedBy[Them][ALL_PIECES]
& ~attackedBy2[Us]
& (~attackedBy[Us][ALL_PIECES] | attackedBy[Us][KING] | attackedBy[Us][QUEEN]);
// Analyse the safe enemy's checks which are possible on next move
safe = ~pos.pieces(Them);
safe &= ~attackedBy[Us][ALL_PIECES] | (weak & attackedBy2[Them]);
b1 = attacks_bb<ROOK >(ksq, pos.pieces() ^ pos.pieces(Us, QUEEN));
b2 = attacks_bb<BISHOP>(ksq, pos.pieces() ^ pos.pieces(Us, QUEEN));
// Enemy queen safe checks
if ((b1 | b2) & attackedBy[Them][QUEEN] & safe & ~attackedBy[Us][QUEEN])
kingDanger += QueenSafeCheck;
b1 &= attackedBy[Them][ROOK];
b2 &= attackedBy[Them][BISHOP];
// Enemy rooks checks
if (b1 & safe)
kingDanger += RookSafeCheck;
else
unsafeChecks |= b1;
// Enemy bishops checks
if (b2 & safe)
kingDanger += BishopSafeCheck;
else
unsafeChecks |= b2;
// Enemy knights checks
b = pos.attacks_from<KNIGHT>(ksq) & attackedBy[Them][KNIGHT];
if (b & safe)
kingDanger += KnightSafeCheck;
else
unsafeChecks |= b;
// Unsafe or occupied checking squares will also be considered, as long as
// the square is in the attacker's mobility area.
unsafeChecks &= mobilityArea[Them];
pinned = pos.blockers_for_king(Us) & pos.pieces(Us);
kingDanger += kingAttackersCount[Them] * kingAttackersWeight[Them]
+ 102 * kingAttacksCount[Them]
+ 191 * popcount(kingRing[Us] & weak)
+ 143 * popcount(pinned | unsafeChecks)
- 848 * !pos.count<QUEEN>(Them)
- 9 * mg_value(score) / 8
+ 40;
// Transform the kingDanger units into a Score, and subtract it from the evaluation
if (kingDanger > 0)
{
int mobilityDanger = mg_value(mobility[Them] - mobility[Us]);
kingDanger = std::max(0, kingDanger + mobilityDanger);
score -= make_score(kingDanger * kingDanger / 4096, kingDanger / 16);
}
}
Bitboard kf = KingFlank[file_of(ksq)];
// Penalty when our king is on a pawnless flank
if (!(pos.pieces(PAWN) & kf))
score -= PawnlessFlank;
// Find the squares that opponent attacks in our king flank, and the squares
// which are attacked twice in that flank but not defended by our pawns.
b1 = attackedBy[Them][ALL_PIECES] & kf & Camp;
b2 = b1 & attackedBy2[Them] & ~attackedBy[Us][PAWN];
// King tropism, to anticipate slow motion attacks on our king
score -= CloseEnemies * (popcount(b1) + popcount(b2));
if (T)
Trace::add(KING, Us, score);
return score;
2008-08-31 23:59:13 -06:00
}
// Evaluation::threats() assigns bonuses according to the types of the
// attacking and the attacked pieces.
template<Tracing T> template<Color Us>
Score Evaluation<T>::threats() const {
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
constexpr Direction Up = (Us == WHITE ? NORTH : SOUTH);
constexpr Bitboard TRank3BB = (Us == WHITE ? Rank3BB : Rank6BB);
Bitboard b, weak, defended, nonPawnEnemies, stronglyProtected, safeThreats;
Score score = SCORE_ZERO;
Introduce Overload This patch applies a S(10, 5) bonus for every square that is: - Occupied by an enemy piece which is not a pawn - Attacked exactly once by our pieces - Defended exactly once by enemy pieces The idea is that these pieces must be defended. Their defenders have dramatically limited mobility, and they are vulnerable to our future attack. As with connectivity, there are probably many more tests to be run in this area. In particular: - I believe @snicolet's queen overload tests have demonstrated a potential need for a queen overload bonus above and beyond this one; however, the conditions for "overload" in this patch are different (excluding pieces we attack twice). My next test after this is (hopefully) merged will be to intersect the Bitboard I define here with the enemy's queen attacks and attempt to give additional bonus. - Perhaps we should exclude pieces attacked by pawns--can pawns really be overloaded? Should they have the same weight, or less? This didn't work with a previous version, but it could work with this one. - More generally, different pieces may need more or less bonus. We could change bonuses based on what type of enemy piece is being overloaded, what type of friendly piece is attacking, and/or what type of piece is being defended by the overloaded piece and attacked by us, or any intersection of these three. For example, here attacked/defended pawns are excluded, but they're not totally worthless targets, and could be added again with a smaller bonus. - This list is by no means exhaustive. STC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 17439 W: 3599 L: 3390 D: 10450 http://tests.stockfishchess.org/tests/view/5ac78a2e0ebc59435923735e LTC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 43304 W: 6533 L: 6256 D: 30515 http://tests.stockfishchess.org/tests/view/5ac7a1d80ebc59435923736f Closes https://github.com/official-stockfish/Stockfish/pull/1533 Bench: 5248871 ---------------- This is my first time opening a PR, so I apologize if there are errors. There are too many people to thank since I submitted my first test just over a month ago. Thank you all for the warm welcome and here is to more green patches! In particular, I would like to thank: - @crossbr, whose comment in a FishCooking thread first inspired me to consider the overloading of pieces other than queens, - @snicolet, whose queen overload tests inspired this one and served as the base of my first overload attempts, - @protonspring, whose connectivity tests inspired this one and who provided much of the feedback needed to take this from red to green, - @vondele, who kindly corrected me when I submitted a bad LTC test, - @Rocky640, who has helped me over and over again in the past month. Thank you all!
2018-04-06 17:20:48 -06:00
// Non-pawn enemies
nonPawnEnemies = pos.pieces(Them) ^ pos.pieces(Them, PAWN);
// Squares strongly protected by the enemy, either because they defend the
// square with a pawn, or because they defend the square twice and we don't.
stronglyProtected = attackedBy[Them][PAWN]
| (attackedBy2[Them] & ~attackedBy2[Us]);
// Non-pawn enemies, strongly protected
defended = nonPawnEnemies & stronglyProtected;
// Enemies not strongly protected and under our attack
weak = pos.pieces(Them) & ~stronglyProtected & attackedBy[Us][ALL_PIECES];
// Bonus according to the kind of attacking pieces
if (defended | weak)
{
b = (defended | weak) & (attackedBy[Us][KNIGHT] | attackedBy[Us][BISHOP]);
while (b)
{
Square s = pop_lsb(&b);
score += ThreatByMinor[type_of(pos.piece_on(s))];
if (type_of(pos.piece_on(s)) != PAWN)
score += ThreatByRank * (int)relative_rank(Them, s);
}
b = (pos.pieces(Them, QUEEN) | weak) & attackedBy[Us][ROOK];
while (b)
{
Square s = pop_lsb(&b);
score += ThreatByRook[type_of(pos.piece_on(s))];
if (type_of(pos.piece_on(s)) != PAWN)
score += ThreatByRank * (int)relative_rank(Them, s);
}
b = weak & attackedBy[Us][KING];
if (b)
score += ThreatByKing[more_than_one(b)];
score += Hanging * popcount(weak & ~attackedBy[Them][ALL_PIECES]);
// Bonus for overload (non-pawn enemies attacked and defended exactly once)
b = nonPawnEnemies
& attackedBy[Us][ALL_PIECES] & ~attackedBy2[Us]
& attackedBy[Them][ALL_PIECES] & ~attackedBy2[Them];
score += Overload * popcount(b);
2014-09-21 11:27:34 -06:00
}
// Bonus for enemy unopposed weak pawns
if (pos.pieces(Us, ROOK, QUEEN))
score += WeakUnopposedPawn * pe->weak_unopposed(Them);
// Our safe or protected pawns
b = pos.pieces(Us, PAWN)
& (~attackedBy[Them][ALL_PIECES] | attackedBy[Us][ALL_PIECES]);
safeThreats = pawn_attacks_bb<Us>(b) & nonPawnEnemies;
score += ThreatBySafePawn * popcount(safeThreats);
// Find squares where our pawns can push on the next move
b = shift<Up>(pos.pieces(Us, PAWN)) & ~pos.pieces();
b |= shift<Up>(b & TRank3BB) & ~pos.pieces();
// Keep only the squares which are not completely unsafe
b &= ~attackedBy[Them][PAWN]
& (attackedBy[Us][ALL_PIECES] | ~attackedBy[Them][ALL_PIECES]);
// Bonus for safe pawn threats on the next move
b = pawn_attacks_bb<Us>(b)
& pos.pieces(Them)
& ~attackedBy[Us][PAWN];
score += ThreatByPawnPush * popcount(b);
// Bonus for threats on the next moves against enemy queen
if (pos.count<QUEEN>(Them) == 1)
{
Square s = pos.square<QUEEN>(Them);
safeThreats = mobilityArea[Us] & ~stronglyProtected;
b = attackedBy[Us][KNIGHT] & pos.attacks_from<KNIGHT>(s);
score += KnightOnQueen * popcount(b & safeThreats);
b = (attackedBy[Us][BISHOP] & pos.attacks_from<BISHOP>(s))
| (attackedBy[Us][ROOK ] & pos.attacks_from<ROOK >(s));
score += SliderOnQueen * popcount(b & safeThreats & attackedBy2[Us]);
}
// Connectivity: ensure that knights, bishops, rooks, and queens are protected
b = (pos.pieces(Us) ^ pos.pieces(Us, PAWN, KING)) & attackedBy[Us][ALL_PIECES];
score += Connectivity * popcount(b);
if (T)
Trace::add(THREAT, Us, score);
return score;
}
// Evaluation::passed() evaluates the passed pawns and candidate passed
// pawns of the given color.
2008-08-31 23:59:13 -06:00
template<Tracing T> template<Color Us>
Score Evaluation<T>::passed() const {
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
constexpr Direction Up = (Us == WHITE ? NORTH : SOUTH);
2008-08-31 23:59:13 -06:00
auto king_proximity = [&](Color c, Square s) {
return std::min(distance(pos.square<KING>(c), s), 5);
};
Bitboard b, bb, squaresToQueen, defendedSquares, unsafeSquares;
Score score = SCORE_ZERO;
b = pe->passed_pawns(Us);
while (b)
{
Square s = pop_lsb(&b);
2008-08-31 23:59:13 -06:00
assert(!(pos.pieces(Them, PAWN) & forward_file_bb(Us, s + Up)));
bb = forward_file_bb(Us, s) & (attackedBy[Them][ALL_PIECES] | pos.pieces(Them));
score -= HinderPassedPawn * popcount(bb);
int r = relative_rank(Us, s);
int w = PassedDanger[r];
Score bonus = PassedRank[r];
if (w)
{
Square blockSq = s + Up;
// Adjust bonus based on the king's proximity
bonus += make_score(0, ( king_proximity(Them, blockSq) * 5
- king_proximity(Us, blockSq) * 2) * w);
// If blockSq is not the queening square then consider also a second push
if (r != RANK_7)
bonus -= make_score(0, king_proximity(Us, blockSq + Up) * w);
// If the pawn is free to advance, then increase the bonus
if (pos.empty(blockSq))
{
// If there is a rook or queen attacking/defending the pawn from behind,
// consider all the squaresToQueen. Otherwise consider only the squares
// in the pawn's path attacked or occupied by the enemy.
defendedSquares = unsafeSquares = squaresToQueen = forward_file_bb(Us, s);
bb = forward_file_bb(Them, s) & pos.pieces(ROOK, QUEEN) & pos.attacks_from<ROOK>(s);
if (!(pos.pieces(Us) & bb))
defendedSquares &= attackedBy[Us][ALL_PIECES];
if (!(pos.pieces(Them) & bb))
unsafeSquares &= attackedBy[Them][ALL_PIECES] | pos.pieces(Them);
// If there aren't any enemy attacks, assign a big bonus. Otherwise
// assign a smaller bonus if the block square isn't attacked.
int k = !unsafeSquares ? 20 : !(unsafeSquares & blockSq) ? 9 : 0;
// If the path to the queen is fully defended, assign a big bonus.
// Otherwise assign a smaller bonus if the block square is defended.
if (defendedSquares == squaresToQueen)
k += 6;
else if (defendedSquares & blockSq)
k += 4;
bonus += make_score(k * w, k * w);
}
else if (pos.pieces(Us) & blockSq)
bonus += make_score(w + r * 2, w + r * 2);
Document Elo impact of various parts of search In order to understand better the impact of various techniques used in search, Elo estimates have been run at STC for 60000 games (statistical error ~1.8 Elo), disabling each feature in turn. This should help future improvements and simplifications to pick suitable targets. The list of tests is: step 7 : http://tests.stockfishchess.org/tests/view/5abcbb4b0ebc5902926cf1ca step 8 : http://tests.stockfishchess.org/tests/view/5abcbb680ebc5902926cf1cc step 9 : http://tests.stockfishchess.org/tests/view/5abcbb850ebc5902926cf1ce step 10 : http://tests.stockfishchess.org/tests/view/5abcbbeb0ebc5902926cf1d2 step 11 : http://tests.stockfishchess.org/tests/view/5abcbbbf0ebc5902926cf1d0 step 13 : http://tests.stockfishchess.org/tests/view/5abd03680ebc5902926cf20b step 13a: http://tests.stockfishchess.org/tests/view/5abd29660ebc5902926cf22a step 13b: http://tests.stockfishchess.org/tests/view/5abd29820ebc5902926cf22c step 14 : http://tests.stockfishchess.org/tests/view/5abd03860ebc5902926cf20f step 14a: http://tests.stockfishchess.org/tests/view/5abd2b6c0ebc5902926cf230 step 14b: http://tests.stockfishchess.org/tests/view/5abd2b8d0ebc5902926cf232 step 14c: http://tests.stockfishchess.org/tests/view/5abd2bad0ebc5902926cf234 step 14d: http://tests.stockfishchess.org/tests/view/5abd2bcf0ebc5902926cf236 step 14e: http://tests.stockfishchess.org/tests/view/5abd2bf10ebc5902926cf238 This patch documents this in the code. Note that it will be a waste to recompute these estimates often, even a couple of [0,5] patches are unlikely to change them by more than the error bars. The interest of the Elo annotations in the code is not in the details, but in high- lighting trends such as razoring (2 Elo) and singular extensions (60 Elo). These estimates should be recomputed at most once a year. Closes https://github.com/official-stockfish/Stockfish/pull/1522 No functional change.
2018-03-31 19:13:29 -06:00
} // w != 0
// Scale down bonus for candidate passers which need more than one
// pawn push to become passed or have a pawn in front of them.
if ( !pos.pawn_passed(Us, s + Up)
|| (pos.pieces(PAWN) & forward_file_bb(Us, s)))
bonus = bonus / 2;
score += bonus + PassedFile[file_of(s)];
}
if (T)
Trace::add(PASSED, Us, score);
return score;
}
// Evaluation::space() computes the space evaluation for a given side. The
// space evaluation is a simple bonus based on the number of safe squares
// available for minor pieces on the central four files on ranks 2--4. Safe
// squares one, two or three squares behind a friendly pawn are counted
// twice. Finally, the space bonus is multiplied by a weight. The aim is to
// improve play on game opening.
template<Tracing T> template<Color Us>
Score Evaluation<T>::space() const {
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
constexpr Bitboard SpaceMask =
Us == WHITE ? CenterFiles & (Rank2BB | Rank3BB | Rank4BB)
: CenterFiles & (Rank7BB | Rank6BB | Rank5BB);
if (pos.non_pawn_material() < SpaceThreshold)
return SCORE_ZERO;
// Find the safe squares for our pieces inside the area defined by
// SpaceMask. A square is unsafe if it is attacked by an enemy
// pawn, or if it is undefended and attacked by an enemy piece.
Bitboard safe = SpaceMask
& ~pos.pieces(Us, PAWN)
& ~attackedBy[Them][PAWN];
// Find all squares which are at most three squares behind some friendly pawn
Bitboard behind = pos.pieces(Us, PAWN);
behind |= (Us == WHITE ? behind >> 8 : behind << 8);
behind |= (Us == WHITE ? behind >> 16 : behind << 16);
int bonus = popcount(safe) + popcount(behind & safe);
int weight = pos.count<ALL_PIECES>(Us) - 2 * pe->open_files();
Score score = make_score(bonus * weight * weight / 16, 0);
if (T)
Trace::add(SPACE, Us, score);
return score;
}
// Evaluation::initiative() computes the initiative correction value
// for the position. It is a second order bonus/malus based on the
// known attacking/defending status of the players.
template<Tracing T>
Score Evaluation<T>::initiative(Value eg) const {
int outflanking = distance<File>(pos.square<KING>(WHITE), pos.square<KING>(BLACK))
- distance<Rank>(pos.square<KING>(WHITE), pos.square<KING>(BLACK));
bool pawnsOnBothFlanks = (pos.pieces(PAWN) & QueenSide)
&& (pos.pieces(PAWN) & KingSide);
// Compute the initiative bonus for the attacking side
int complexity = 8 * outflanking
+ 8 * pe->pawn_asymmetry()
+ 12 * pos.count<PAWN>()
+ 16 * pawnsOnBothFlanks
+ 48 * !pos.non_pawn_material()
-136 ;
// Now apply the bonus: note that we find the attacking side by extracting
// the sign of the endgame value, and that we carefully cap the bonus so
// that the endgame score will never change sign after the bonus.
int v = ((eg > 0) - (eg < 0)) * std::max(complexity, -abs(eg));
if (T)
Trace::add(INITIATIVE, make_score(0, v));
return make_score(0, v);
}
// Evaluation::scale_factor() computes the scale factor for the winning side
template<Tracing T>
ScaleFactor Evaluation<T>::scale_factor(Value eg) const {
Color strongSide = eg > VALUE_DRAW ? WHITE : BLACK;
int sf = me->scale_factor(pos, strongSide);
// If we don't already have an unusual scale factor, check for certain
// types of endgames, and use a lower scale for those.
if (sf == SCALE_FACTOR_NORMAL || sf == SCALE_FACTOR_ONEPAWN)
{
if (pos.opposite_bishops())
{
Simplify KBPKB endgame with opposite bishops When we reach a position with only two opposite colored bishops and one pawn on the board, current master would give it a scale factor of 9/64=0.14 in about one position out of 7200, and a scale factor of 0.0 in the 7199 others. The patch gives a scale factor of 0.0 in 100% of the cases. STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 55845 W: 11467 L: 11410 D: 32968 http://tests.stockfishchess.org/tests/view/5abc585f0ebc5902926cf15e LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 11915 W: 1852 L: 1719 D: 8344 http://tests.stockfishchess.org/tests/view/5abc7f750ebc5902926cf18c We also have exhaustive coverage analysis of this patch effect by Alain Savard, comparing the perfect evaluation given by the Syzygy tablebase with the heuristic play after this patch for the set of all legal positions of the KBPKP endgame with opposite bishops, in the comments thread for this pull request: https://github.com/official-stockfish/Stockfish/pull/1520 Alain's conclusion: > According to this definition and the data, I consider this PR is > identical to master to "solve for draw" and slightly better than > master to solve earlier for "wins". Note: this patch is a side effect of an ongoing effort to improve the evaluation of positions involving a pair of opposite bishops. See the GitHub diff of this LTC test which almost passed at sprt[0..5] for a discussion: http://tests.stockfishchess.org/tests/view/5ab9030b0ebc5902932cbf93 No functional change (at small bench depths)
2018-03-31 18:00:57 -06:00
// Endgame with opposite-colored bishops and no other pieces is almost a draw
if ( pos.non_pawn_material(WHITE) == BishopValueMg
&& pos.non_pawn_material(BLACK) == BishopValueMg)
Simplify KBPKB endgame with opposite bishops When we reach a position with only two opposite colored bishops and one pawn on the board, current master would give it a scale factor of 9/64=0.14 in about one position out of 7200, and a scale factor of 0.0 in the 7199 others. The patch gives a scale factor of 0.0 in 100% of the cases. STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 55845 W: 11467 L: 11410 D: 32968 http://tests.stockfishchess.org/tests/view/5abc585f0ebc5902926cf15e LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 11915 W: 1852 L: 1719 D: 8344 http://tests.stockfishchess.org/tests/view/5abc7f750ebc5902926cf18c We also have exhaustive coverage analysis of this patch effect by Alain Savard, comparing the perfect evaluation given by the Syzygy tablebase with the heuristic play after this patch for the set of all legal positions of the KBPKP endgame with opposite bishops, in the comments thread for this pull request: https://github.com/official-stockfish/Stockfish/pull/1520 Alain's conclusion: > According to this definition and the data, I consider this PR is > identical to master to "solve for draw" and slightly better than > master to solve earlier for "wins". Note: this patch is a side effect of an ongoing effort to improve the evaluation of positions involving a pair of opposite bishops. See the GitHub diff of this LTC test which almost passed at sprt[0..5] for a discussion: http://tests.stockfishchess.org/tests/view/5ab9030b0ebc5902932cbf93 No functional change (at small bench depths)
2018-03-31 18:00:57 -06:00
sf = 31;
// Endgame with opposite-colored bishops, but also other pieces. Still
// a bit drawish, but not as drawish as with only the two bishops.
else
sf = 46;
}
// Endings where weaker side can place his king in front of the enemy's
// pawns are drawish.
else if ( abs(eg) <= BishopValueEg
&& pos.count<PAWN>(strongSide) <= 2
&& !pos.pawn_passed(~strongSide, pos.square<KING>(~strongSide)))
sf = 37 + 7 * pos.count<PAWN>(strongSide);
}
return ScaleFactor(sf);
}
// Evaluation::value() is the main function of the class. It computes the various
// parts of the evaluation and returns the value of the position from the point
// of view of the side to move.
template<Tracing T>
Value Evaluation<T>::value() {
assert(!pos.checkers());
// Probe the material hash table
me = Material::probe(pos);
// If we have a specialized evaluation function for the current material
// configuration, call it and return.
if (me->specialized_eval_exists())
return me->evaluate(pos);
// Initialize score by reading the incrementally updated scores included in
// the position object (material + piece square tables) and the material
// imbalance. Score is computed internally from the white point of view.
Use per-thread dynamic contempt We now use per-thread dynamic contempt. This patch has the following effects: * for Threads=1: **non-functional** * for Threads>1: * with MultiPV=1: **no regression, little to no ELO gain** * with MultiPV>1: **clear improvement over master** First, I tried testing at standard MultiPV=1 play with [0,5] bounds. This yielded 2 yellow and 1 red test: 5+0.05, Threads=5: LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 82689 W: 16439 L: 16190 D: 50060 http://tests.stockfishchess.org/tests/view/5aa93a5a0ebc5902952892e6 5+0.05, Threads=8: LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 27164 W: 4974 L: 4983 D: 17207 http://tests.stockfishchess.org/tests/view/5ab2639b0ebc5902a6fbefd5 5+0.5, Threads=16: LLR: -2.97 (-2.94,2.94) [0.00,5.00] Total: 41396 W: 7127 L: 7082 D: 27187 http://tests.stockfishchess.org/tests/view/5ab124220ebc59029516cb62 Then, I tested with Skill Level=17 (implicitly MutliPV=4), showing a clear improvement: 5+0.05, Threads=5: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 3498 W: 1316 L: 1135 D: 1047 http://tests.stockfishchess.org/tests/view/5ab4b6580ebc5902932aeca2 Next, I tested the patch with MultiPV=1 again, this time checking for non-regression ([-3, 1]): 5+0.5, Threads=5: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 65575 W: 12786 L: 12745 D: 40044 http://tests.stockfishchess.org/tests/view/5ab4e8500ebc5902932aecb3 Finally, I ran some tests with fixed number of games, checking if reverting dynamic contempt gains more elo with Skill Level=17 (i.e. MultiPV) than applying the "prevScore" fix and this patch. These tests showed, that this patch gains 15 ELO when playing with Skill Level=17: 5+0.05, Threads=3, "revert dynamic contempt" vs. "WITHOUT this patch": ELO: -11.43 +-4.1 (95%) LOS: 0.0% Total: 20000 W: 7085 L: 7743 D: 5172 http://tests.stockfishchess.org/tests/view/5ab636450ebc590295d88536 5+0.05, Threads=3, "revert dynamic contempt" vs. "WITH this patch": ELO: -26.42 +-4.1 (95%) LOS: 0.0% Total: 20000 W: 6661 L: 8179 D: 5160 http://tests.stockfishchess.org/tests/view/5ab62e680ebc590295d88524 --- ***FAQ*** **Why should this be commited?** I believe that the gain for multi-thread MultiPV search is a sufficient justification for this otherwise neutral change. I also believe this implementation of dynamic contempt is more logical, although this may be just my opinion. **Why is per-thread contempt better at MultiPV?** A likely explanation for the gain in MultiPV mode is that during search each thread independently switches between rootMoves and via the shared contempt score skews each other's evaluation. **Why were the tests done with Skill Level=17?** This was originally suggested by @Hanamuke and the idea is that with Skill Level Stockfish sometimes plays also moves it thinks are slightly sub-optimal and thus the quality of all moves offered by the MultiPV search is checked by the test. **Why are the ELO differences so huge?** This is most likely because of the nature of Skill Level mode -- since it slower and weaker than normal mode, bugs in evaluation have much greater effect. --- Closes https://github.com/official-stockfish/Stockfish/pull/1515. No functional change -- in single thread mode.
2018-03-30 02:47:05 -06:00
Score score = pos.psq_score() + me->imbalance() + pos.this_thread()->contempt;
// Probe the pawn hash table
pe = Pawns::probe(pos);
score += pe->pawn_score(WHITE) - pe->pawn_score(BLACK);
// Early exit if score is high
Value v = (mg_value(score) + eg_value(score)) / 2;
if (abs(v) > LazyThreshold)
return pos.side_to_move() == WHITE ? v : -v;
// Main evaluation begins here
initialize<WHITE>();
initialize<BLACK>();
// Pieces should be evaluated first (populate attack tables)
score += pieces<WHITE, KNIGHT>() - pieces<BLACK, KNIGHT>()
+ pieces<WHITE, BISHOP>() - pieces<BLACK, BISHOP>()
+ pieces<WHITE, ROOK >() - pieces<BLACK, ROOK >()
+ pieces<WHITE, QUEEN >() - pieces<BLACK, QUEEN >();
score += mobility[WHITE] - mobility[BLACK];
score += king< WHITE>() - king< BLACK>()
+ threats<WHITE>() - threats<BLACK>()
+ passed< WHITE>() - passed< BLACK>()
+ space< WHITE>() - space< BLACK>();
score += initiative(eg_value(score));
// Interpolate between a middlegame and a (scaled by 'sf') endgame score
ScaleFactor sf = scale_factor(eg_value(score));
v = mg_value(score) * int(me->game_phase())
+ eg_value(score) * int(PHASE_MIDGAME - me->game_phase()) * sf / SCALE_FACTOR_NORMAL;
v /= int(PHASE_MIDGAME);
// In case of tracing add all remaining individual evaluation terms
if (T)
{
Trace::add(MATERIAL, pos.psq_score());
Trace::add(IMBALANCE, me->imbalance());
Trace::add(PAWN, pe->pawn_score(WHITE), pe->pawn_score(BLACK));
Trace::add(MOBILITY, mobility[WHITE], mobility[BLACK]);
Trace::add(TOTAL, score);
}
return (pos.side_to_move() == WHITE ? v : -v) // Side to move point of view
+ Eval::Tempo;
}
} // namespace
/// evaluate() is the evaluator for the outer world. It returns a static
/// evaluation of the position from the point of view of the side to move.
Value Eval::evaluate(const Position& pos) {
return Evaluation<NO_TRACE>(pos).value();
}
/// trace() is like evaluate(), but instead of returning a value, it returns
/// a string (suitable for outputting to stdout) that contains the detailed
/// descriptions and values of each evaluation term. Useful for debugging.
std::string Eval::trace(const Position& pos) {
std::memset(scores, 0, sizeof(scores));
Use per-thread dynamic contempt We now use per-thread dynamic contempt. This patch has the following effects: * for Threads=1: **non-functional** * for Threads>1: * with MultiPV=1: **no regression, little to no ELO gain** * with MultiPV>1: **clear improvement over master** First, I tried testing at standard MultiPV=1 play with [0,5] bounds. This yielded 2 yellow and 1 red test: 5+0.05, Threads=5: LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 82689 W: 16439 L: 16190 D: 50060 http://tests.stockfishchess.org/tests/view/5aa93a5a0ebc5902952892e6 5+0.05, Threads=8: LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 27164 W: 4974 L: 4983 D: 17207 http://tests.stockfishchess.org/tests/view/5ab2639b0ebc5902a6fbefd5 5+0.5, Threads=16: LLR: -2.97 (-2.94,2.94) [0.00,5.00] Total: 41396 W: 7127 L: 7082 D: 27187 http://tests.stockfishchess.org/tests/view/5ab124220ebc59029516cb62 Then, I tested with Skill Level=17 (implicitly MutliPV=4), showing a clear improvement: 5+0.05, Threads=5: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 3498 W: 1316 L: 1135 D: 1047 http://tests.stockfishchess.org/tests/view/5ab4b6580ebc5902932aeca2 Next, I tested the patch with MultiPV=1 again, this time checking for non-regression ([-3, 1]): 5+0.5, Threads=5: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 65575 W: 12786 L: 12745 D: 40044 http://tests.stockfishchess.org/tests/view/5ab4e8500ebc5902932aecb3 Finally, I ran some tests with fixed number of games, checking if reverting dynamic contempt gains more elo with Skill Level=17 (i.e. MultiPV) than applying the "prevScore" fix and this patch. These tests showed, that this patch gains 15 ELO when playing with Skill Level=17: 5+0.05, Threads=3, "revert dynamic contempt" vs. "WITHOUT this patch": ELO: -11.43 +-4.1 (95%) LOS: 0.0% Total: 20000 W: 7085 L: 7743 D: 5172 http://tests.stockfishchess.org/tests/view/5ab636450ebc590295d88536 5+0.05, Threads=3, "revert dynamic contempt" vs. "WITH this patch": ELO: -26.42 +-4.1 (95%) LOS: 0.0% Total: 20000 W: 6661 L: 8179 D: 5160 http://tests.stockfishchess.org/tests/view/5ab62e680ebc590295d88524 --- ***FAQ*** **Why should this be commited?** I believe that the gain for multi-thread MultiPV search is a sufficient justification for this otherwise neutral change. I also believe this implementation of dynamic contempt is more logical, although this may be just my opinion. **Why is per-thread contempt better at MultiPV?** A likely explanation for the gain in MultiPV mode is that during search each thread independently switches between rootMoves and via the shared contempt score skews each other's evaluation. **Why were the tests done with Skill Level=17?** This was originally suggested by @Hanamuke and the idea is that with Skill Level Stockfish sometimes plays also moves it thinks are slightly sub-optimal and thus the quality of all moves offered by the MultiPV search is checked by the test. **Why are the ELO differences so huge?** This is most likely because of the nature of Skill Level mode -- since it slower and weaker than normal mode, bugs in evaluation have much greater effect. --- Closes https://github.com/official-stockfish/Stockfish/pull/1515. No functional change -- in single thread mode.
2018-03-30 02:47:05 -06:00
pos.this_thread()->contempt = SCORE_ZERO; // Reset any dynamic contempt
Value v = Evaluation<TRACE>(pos).value();
v = pos.side_to_move() == WHITE ? v : -v; // Trace scores are from white's point of view
std::stringstream ss;
ss << std::showpoint << std::noshowpos << std::fixed << std::setprecision(2)
<< " Term | White | Black | Total \n"
<< " | MG EG | MG EG | MG EG \n"
<< " ------------+-------------+-------------+------------\n"
<< " Material | " << Term(MATERIAL)
<< " Imbalance | " << Term(IMBALANCE)
<< " Initiative | " << Term(INITIATIVE)
<< " Pawns | " << Term(PAWN)
<< " Knights | " << Term(KNIGHT)
<< " Bishops | " << Term(BISHOP)
<< " Rooks | " << Term(ROOK)
<< " Queens | " << Term(QUEEN)
<< " Mobility | " << Term(MOBILITY)
<< " King safety | " << Term(KING)
<< " Threats | " << Term(THREAT)
<< " Passed | " << Term(PASSED)
<< " Space | " << Term(SPACE)
<< " ------------+-------------+-------------+------------\n"
<< " Total | " << Term(TOTAL);
ss << "\nTotal evaluation: " << to_cp(v) << " (white side)\n";
return ss.str();
}