1
0
Fork 0
stockfish/src/evaluate.cpp

889 lines
33 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-2019 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 {
// Threshold for lazy and space evaluation
constexpr Value LazyThreshold = Value(1400);
constexpr Value SpaceThreshold = Value(12222);
// KingAttackWeights[PieceType] contains king attack weights by piece type
constexpr int KingAttackWeights[PIECE_TYPE_NB] = { 0, 0, 77, 55, 44, 10 };
// Penalties for enemy's safe checks
constexpr int QueenSafeCheck = 780;
constexpr int RookSafeCheck = 1080;
constexpr int BishopSafeCheck = 635;
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(-62,-81), S(-53,-56), S(-12,-30), S( -4,-14), S( 3, 8), S( 13, 15), // Knights
S( 22, 23), S( 28, 27), S( 33, 33) },
{ 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
};
// RookOnFile[semiopen/open] contains bonuses for each rook when there is
// no (friendly) pawn on the rook file.
constexpr Score RookOnFile[] = { S(18, 7), S(44, 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] = {
Combo This PR is a combination of two unrelated [0, 4] patches that appeared promising but not quite strong enough to pass on their own. The combination initially failed STC with a positive score after a long run, and the subsequent speculative LTC test passed. * tweak_threatOnQueen4 : Increase the middlegame components of ThreatByMinor[QUEEN] and ThreatByRook[QUEEN] by 15 each. Bryan's (@crossbr) analysis of CCC Bonus Game 10 inspired several tests on penalizing a queen with limited safe mobility. While attempting to implement this idea, I noticed that when I did not include the queen's current square in the calculations, the Elo gains seemed to vanish--and only then did I have the idea to revisit ThreatByMinor[QUEEN] and ThreatByRook[QUEEN], adding a corresponding value to each. Without Bryan's work, this test would never have been submitted. I would also like to recognize the efforts and contributions of @SFisGOD, who also vigorously worked on this idea. * Use pure static eval for null move pruning : This idea was directly re-purposed from a promising test by Jerry Donald Watson (@jerrydonaldwatson) in August. It was also independently developed and tested by Stefan Geschwentner (@locutus2) previously. Thank you all! STC (failed yellow): LLR: -2.96 (-2.94,2.94) [0.00,4.00] Total: 83913 W: 17986 L: 17825 D: 48102 http://tests.stockfishchess.org/tests/view/5bbc59300ebc592439f76aa5 LTC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 137198 W: 22351 L: 21772 D: 93075 http://tests.stockfishchess.org/tests/view/5bbce35f0ebc592439f77639 Bench: 4312846
2018-10-08 12:43:45 -06:00
S(0, 0), S(0, 31), S(39, 42), S(57, 44), S(68, 112), S(62, 120)
};
constexpr Score ThreatByRook[PIECE_TYPE_NB] = {
Combo This PR is a combination of two unrelated [0, 4] patches that appeared promising but not quite strong enough to pass on their own. The combination initially failed STC with a positive score after a long run, and the subsequent speculative LTC test passed. * tweak_threatOnQueen4 : Increase the middlegame components of ThreatByMinor[QUEEN] and ThreatByRook[QUEEN] by 15 each. Bryan's (@crossbr) analysis of CCC Bonus Game 10 inspired several tests on penalizing a queen with limited safe mobility. While attempting to implement this idea, I noticed that when I did not include the queen's current square in the calculations, the Elo gains seemed to vanish--and only then did I have the idea to revisit ThreatByMinor[QUEEN] and ThreatByRook[QUEEN], adding a corresponding value to each. Without Bryan's work, this test would never have been submitted. I would also like to recognize the efforts and contributions of @SFisGOD, who also vigorously worked on this idea. * Use pure static eval for null move pruning : This idea was directly re-purposed from a promising test by Jerry Donald Watson (@jerrydonaldwatson) in August. It was also independently developed and tested by Stefan Geschwentner (@locutus2) previously. Thank you all! STC (failed yellow): LLR: -2.96 (-2.94,2.94) [0.00,4.00] Total: 83913 W: 17986 L: 17825 D: 48102 http://tests.stockfishchess.org/tests/view/5bbc59300ebc592439f76aa5 LTC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 137198 W: 22351 L: 21772 D: 93075 http://tests.stockfishchess.org/tests/view/5bbce35f0ebc592439f77639 Bench: 4312846
2018-10-08 12:43:45 -06:00
S(0, 0), S(0, 24), S(38, 71), S(38, 61), S(0, 38), S(51, 38)
};
// PassedRank[Rank] contains a bonus according to the rank of a passed pawn
constexpr Score PassedRank[RANK_NB] = {
S(0, 0), S(10, 28), S(17, 33), S(15, 41), S(62, 72), S(168, 177), S(276, 260)
};
// Assorted bonuses and penalties
constexpr Score BishopPawns = S( 3, 7);
constexpr Score CorneredBishop = S( 50, 50);
constexpr Score FlankAttacks = S( 8, 0);
constexpr Score Hanging = S( 69, 36);
constexpr Score KingProtector = S( 7, 8);
constexpr Score KnightOnQueen = S( 16, 12);
constexpr Score LongDiagonalBishop = S( 45, 0);
constexpr Score MinorBehindPawn = S( 18, 3);
constexpr Score Outpost = S( 18, 6);
constexpr Score PassedFile = S( 11, 8);
constexpr Score PawnlessFlank = S( 17, 95);
constexpr Score RestrictedPiece = S( 7, 7);
constexpr Score RookOnPawn = S( 10, 32);
constexpr Score SliderOnQueen = S( 59, 18);
constexpr Score ThreatByKing = S( 24, 89);
constexpr Score ThreatByPawnPush = S( 48, 39);
constexpr Score ThreatByRank = S( 13, 0);
constexpr Score ThreatBySafePawn = S(173, 94);
constexpr Score TrappedRook = S( 47, 4);
constexpr Score WeakQueen = S( 49, 15);
#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 at least 2 units of a given
// color, including x-rays. But diagonal x-rays through pawns are not computed.
Bitboard attackedBy2[COLOR_NB];
// kingRing[color] are the squares adjacent to the king plus some other
// very near squares, depending on king position.
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);
const Square ksq = pos.square<KING>(Us);
Bitboard dblAttackByPawn = pawn_double_attacks_bb<Us>(pos.pieces(Us, PAWN));
// 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 queen or controlled by
// enemy pawns are excluded from the mobility area.
mobilityArea[Us] = ~(b | pos.pieces(Us, KING, QUEEN) | pe->pawn_attacks(Them));
// Initialize attackedBy[] for king and pawns
attackedBy[Us][KING] = pos.attacks_from<KING>(ksq);
attackedBy[Us][PAWN] = pe->pawn_attacks(Us);
attackedBy[Us][ALL_PIECES] = attackedBy[Us][KING] | attackedBy[Us][PAWN];
attackedBy2[Us] = dblAttackByPawn | (attackedBy[Us][KING] & attackedBy[Us][PAWN]);
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
// Init our king safety tables
kingRing[Us] = attackedBy[Us][KING];
if (relative_rank(Us, ksq) == RANK_1)
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
kingRing[Us] |= shift<Up>(kingRing[Us]);
if (file_of(ksq) == FILE_H)
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
kingRing[Us] |= shift<WEST>(kingRing[Us]);
else if (file_of(ksq) == FILE_A)
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
kingRing[Us] |= shift<EAST>(kingRing[Us]);
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
kingAttackersCount[Them] = popcount(kingRing[Us] & pe->pawn_attacks(Them));
kingAttacksCount[Them] = kingAttackersWeight[Them] = 0;
// Remove from kingRing[] the squares defended by two pawns
kingRing[Us] &= ~dblAttackByPawn;
}
// 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 Direction Down = (Us == WHITE ? SOUTH : NORTH);
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;
Score score = SCORE_ZERO;
attackedBy[Us][Pt] = 0;
for (Square s = *pl; s != SQ_NONE; s = *++pl)
{
// 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]);
}
int mob = popcount(b & mobilityArea[Us]);
mobility[Us] += MobilityBonus[Pt - 2][mob];
if (Pt == BISHOP || Pt == KNIGHT)
{
// Bonus if piece is on an outpost square or can reach one
bb = OutpostRanks & attackedBy[Us][PAWN] & ~pe->pawn_attacks_span(Them);
if (bb & s)
score += Outpost * (Pt == KNIGHT ? 4 : 2);
else if (bb & b & ~pos.pieces(Us))
score += Outpost * (Pt == KNIGHT ? 2 : 1);
// Knight and Bishop bonus for being right behind a pawn
if (shift<Down>(pos.pieces(PAWN)) & s)
score += MinorBehindPawn;
// Penalty if the piece is far from the king
score -= KingProtector * distance(s, pos.square<KING>(Us));
if (Pt == BISHOP)
{
// Penalty according to number of pawns on the same color square as the
// bishop, bigger when the center files are blocked with pawns.
Bitboard blocked = pos.pieces(Us, PAWN) & shift<Down>(pos.pieces());
score -= BishopPawns * pos.pawns_on_same_color_squares(Us, s)
* (1 + popcount(blocked & CenterFiles));
// Bonus for bishop on a long diagonal which can "see" both center squares
if (more_than_one(attacks_bb<BISHOP>(s, pos.pieces(PAWN)) & Center))
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 (pos.is_on_semiopen_file(Us, s))
score += RookOnFile[bool(pos.is_on_semiopen_file(Them, 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 * (1 + !pos.castling_rights(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);
Bitboard weak, b1, b2, safe, unsafeChecks = 0;
Bitboard rookChecks, queenChecks, bishopChecks, knightChecks;
int kingDanger = 0;
const Square ksq = pos.square<KING>(Us);
2008-08-31 23:59:13 -06:00
// Init the score with king shelter and enemy pawns storm
Score score = pe->king_safety<Us>(pos);
2008-08-31 23:59:13 -06:00
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
// 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 rooks checks
rookChecks = b1 & safe & attackedBy[Them][ROOK];
if (rookChecks)
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
kingDanger += RookSafeCheck;
else
unsafeChecks |= b1 & attackedBy[Them][ROOK];
// Enemy queen safe checks: we count them only if they are from squares from
// which we can't give a rook check, because rook checks are more valuable.
queenChecks = (b1 | b2)
& attackedBy[Them][QUEEN]
& safe
& ~attackedBy[Us][QUEEN]
& ~rookChecks;
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
if (queenChecks)
kingDanger += QueenSafeCheck;
// Enemy bishops checks: we count them only if they are from squares from
// which we can't give a queen check, because queen checks are more valuable.
bishopChecks = b2
& attackedBy[Them][BISHOP]
& safe
& ~queenChecks;
if (bishopChecks)
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
kingDanger += BishopSafeCheck;
else
unsafeChecks |= b2 & attackedBy[Them][BISHOP];
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
// Enemy knights checks
knightChecks = pos.attacks_from<KNIGHT>(ksq) & attackedBy[Them][KNIGHT];
if (knightChecks & safe)
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
kingDanger += KnightSafeCheck;
else
unsafeChecks |= knightChecks;
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
// Find the squares that opponent attacks in our king flank, and the squares
// which are attacked twice in that flank.
b1 = attackedBy[Them][ALL_PIECES] & KingFlank[file_of(ksq)] & Camp;
b2 = b1 & attackedBy2[Them];
int kingFlankAttacks = popcount(b1) + popcount(b2);
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
kingDanger += kingAttackersCount[Them] * kingAttackersWeight[Them]
+ 69 * kingAttacksCount[Them]
+ 185 * popcount(kingRing[Us] & weak)
- 100 * bool(attackedBy[Us][KNIGHT] & attackedBy[Us][KING])
- 35 * bool(attackedBy[Us][BISHOP] & attackedBy[Us][KING])
+ 148 * popcount(unsafeChecks)
+ 98 * popcount(pos.blockers_for_king(Us))
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
- 873 * !pos.count<QUEEN>(Them)
- 6 * mg_value(score) / 8
+ mg_value(mobility[Them] - mobility[Us])
+ 5 * kingFlankAttacks * kingFlankAttacks / 16
- 7;
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
// Transform the kingDanger units into a Score, and subtract it from the evaluation
Raise kingDanger threshold and adjust constant term #2087 The kingDanger term is intended to give a penalty which increases rapidly in the middlegame but less so in the endgame. To this end, the middlegame component is quadratic, and the endgame component is linear. However, this produces unintended consequences for relatively small values of kingDanger: the endgame penalty will exceed the middlegame penalty. This remains true up to kingDanger = 256 (a S(16, 16) penalty), so some of these inaccurate penalties are actually rather large. In this patch, we increase the threshold for applying the kingDanger penalty to eliminate some of this unintended behavior. This was very nearly, but not quite, sufficient to pass on its own. The patch was finally successful by integrating a second kingDanger tweak by @Vizvezdenec, increasing the kingDanger constant term slightly and improving both STC and LTC performance. Where do we go from here? I propose that in the future, any attempts to tune kingDanger coefficients should also consider tuning the kingDanger threshold. The evidence shows clearly that it should not be automatically taken to be zero. Special thanks to @Vizvezdenec for the kingDanger constant tweak. Thanks also to all the approvers and CPU donors who made this possible! STC: LLR: -2.96 (-2.94,2.94) [0.00,4.00] Total: 141225 W: 31239 L: 30846 D: 79140 http://tests.stockfishchess.org/tests/view/5cabbdb20ebc5925cf00b86c LTC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 30708 W: 5296 L: 5043 D: 20369 http://tests.stockfishchess.org/tests/view/5cabff760ebc5925cf00c22d Bench: 3445945
2019-04-09 11:35:17 -06:00
if (kingDanger > 100)
Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-)
2018-12-26 23:51:43 -07:00
score -= make_score(kingDanger * kingDanger / 4096, kingDanger / 16);
// Penalty when our king is on a pawnless flank
if (!(pos.pieces(PAWN) & KingFlank[file_of(ksq)]))
score -= PawnlessFlank;
// Penalty if king flank is under attack, potentially moving toward the king
score -= FlankAttacks * kingFlankAttacks;
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, safe;
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(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];
// Safe or protected squares
safe = ~attackedBy[Them][ALL_PIECES] | 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 = 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);
}
if (weak & attackedBy[Us][KING])
score += ThreatByKing;
b = ~attackedBy[Them][ALL_PIECES]
| (nonPawnEnemies & attackedBy2[Us]);
score += Hanging * popcount(weak & b);
2014-09-21 11:27:34 -06:00
}
// Bonus for restricting their piece moves
b = attackedBy[Them][ALL_PIECES]
& ~stronglyProtected
& attackedBy[Us][ALL_PIECES];
score += RestrictedPiece * popcount(b);
// 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 relatively safe
b &= ~attackedBy[Them][PAWN] & safe;
// Bonus for safe pawn threats on the next move
b = pawn_attacks_bb<Us>(b) & nonPawnEnemies;
score += ThreatByPawnPush * popcount(b);
// Our safe or protected pawns
b = pos.pieces(Us, PAWN) & safe;
b = pawn_attacks_bb<Us>(b) & nonPawnEnemies;
score += ThreatBySafePawn * popcount(b);
// Bonus for threats on the next moves against enemy queen
if (pos.count<QUEEN>(Them) == 1)
{
Square s = pos.square<QUEEN>(Them);
safe = mobilityArea[Us] & ~stronglyProtected;
b = attackedBy[Us][KNIGHT] & pos.attacks_from<KNIGHT>(s);
score += KnightOnQueen * popcount(b & safe);
b = (attackedBy[Us][BISHOP] & pos.attacks_from<BISHOP>(s))
| (attackedBy[Us][ROOK ] & pos.attacks_from<ROOK >(s));
score += SliderOnQueen * popcount(b & safe & attackedBy2[Us]);
}
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, 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)));
int r = relative_rank(Us, s);
File f = file_of(s);
Score bonus = PassedRank[r];
if (r > RANK_3)
{
int w = 5 * r - 13;
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))
{
squaresToQueen = forward_file_bb(Us, s);
unsafeSquares = passed_pawn_span(Us, s);
bb = forward_file_bb(Them, s) & pos.pieces(ROOK, QUEEN);
if (!(pos.pieces(Them) & bb))
unsafeSquares &= attackedBy[Them][ALL_PIECES];
// If there are no enemy attacks on passed pawn span, assign a big bonus.
// Otherwise assign a smaller bonus if the path to queen is not attacked
// and even smaller bonus if it is attacked but block square is not.
int k = !unsafeSquares ? 35 :
!(unsafeSquares & squaresToQueen) ? 20 :
!(unsafeSquares & blockSq) ? 9 :
0 ;
Exclude passed pawns from Attacked2Unsupported We recently added a bonus for double pawn attacks on unsupported enemy pawns, on June 27. However, it is possible that the unsupported pawn may become a passer by simply pushing forward out of the double attack. By rewarding double attacks, we may inadvertently reward the creation of enemy passers, by encouraging both of our would-be stoppers to attack the enemy pawn even if there is no opposing friendly pawn on the same file. Here, we revise this term to exclude passed pawns. In order to simplify the code with this change included, we non-functionally rewrite Attacked2Unsupported to be a penalty for enemy attacks on friendly pawns, rather than a bonus for our attacks on enemy pawns. This allows us to exclude passed pawns with a simple & ~e->passedPawns[Us], while passedPawns[Them] is not yet defined in this part of the code. This dramatically reduces the proportion of positions in which Attacked2Unsupported is applied, to about a third of the original. To compensate, maintaining the same average effect across our bench positions, we nearly triple Attacked2Unsupported from S(0, 20) to S(0, 56). Although this pawn formation is rare, it is worth more than half a pawn in the endgame! STC: (stopped automatically by fishtest after 250,000 games) LLR: -0.87 (-2.94,2.94) [0.50,4.50] Total: 250000 W: 56585 L: 55383 D: 138032 http://tests.stockfishchess.org/tests/view/5d25795e0ebc5925cf0cfb51 LTC: LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 81038 W: 13965 L: 13558 D: 53515 http://tests.stockfishchess.org/tests/view/5d25f3920ebc5925cf0d10dd Closes https://github.com/official-stockfish/Stockfish/pull/2233 Bench: 3765158
2019-07-11 07:14:57 -06:00
// Assign a larger bonus if the block square is defended
if ((pos.pieces(Us) & bb) || (attackedBy[Us][ALL_PIECES] & blockSq))
k += 5;
bonus += make_score(k * w, k * w);
}
} // r > RANK_3
// 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) & (s + Up)))
bonus = bonus / 2;
score += bonus - PassedFile * std::min(f, ~f);
}
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 {
if (pos.non_pawn_material() < SpaceThreshold)
return SCORE_ZERO;
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
constexpr Direction Down = (Us == WHITE ? SOUTH : NORTH);
constexpr Bitboard SpaceMask =
Us == WHITE ? CenterFiles & (Rank2BB | Rank3BB | Rank4BB)
: CenterFiles & (Rank7BB | Rank6BB | Rank5BB);
// Find the available squares for our pieces inside the area defined by SpaceMask
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 |= shift<Down>(behind);
behind |= shift<Down+Down>(behind);
int bonus = popcount(safe) + popcount(behind & safe & ~attackedBy[Them][ALL_PIECES]);
int weight = pos.count<ALL_PIECES>(Us) - 1;
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 = 9 * pe->passed_count()
+ 11 * pos.count<PAWN>()
+ 9 * outflanking
+ 18 * pawnsOnBothFlanks
+ 49 * !pos.non_pawn_material()
-103 ;
// 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 scale is not already specific, scale down the endgame via general heuristics
if (sf == SCALE_FACTOR_NORMAL)
{
if ( pos.opposite_bishops()
&& pos.non_pawn_material() == 2 * BishopValueMg)
sf = 16 + 4 * pe->passed_count();
else
sf = std::min(40 + (pos.opposite_bishops() ? 2 : 7) * pos.count<PAWN>(strongSide), sf);
}
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 + pos.non_pawn_material() / 64)
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 /= 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)
<< " 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)
<< " Initiative | " << Term(INITIATIVE)
<< " ------------+-------------+-------------+------------\n"
<< " Total | " << Term(TOTAL);
ss << "\nTotal evaluation: " << to_cp(v) << " (white side)\n";
return ss.str();
}