2008-08-31 23:59:13 -06:00
|
|
|
/*
|
2008-10-19 10:56:28 -06:00
|
|
|
Stockfish, a UCI chess playing engine derived from Glaurung 2.1
|
|
|
|
Copyright (C) 2004-2008 Tord Romstad (Glaurung author)
|
2016-01-02 02:43:25 -07:00
|
|
|
Copyright (C) 2008-2015 Marco Costalba, Joona Kiiski, Tord Romstad
|
2018-01-01 02:33:07 -07:00
|
|
|
Copyright (C) 2015-2018 Marco Costalba, Joona Kiiski, Gary Linscott, Tord Romstad
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2008-10-19 10:56:28 -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.
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2008-10-19 10:56:28 -06:00
|
|
|
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-09-23 16:32:53 -06:00
|
|
|
|
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/>.
|
|
|
|
*/
|
|
|
|
|
2014-05-03 04:09:56 -06:00
|
|
|
#include <algorithm>
|
2008-08-31 23:59:13 -06:00
|
|
|
#include <cassert>
|
2014-12-30 02:31:50 -07:00
|
|
|
#include <cstring> // For std::memset
|
2011-02-26 06:09:58 -07:00
|
|
|
#include <iomanip>
|
|
|
|
#include <sstream>
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2016-04-08 11:52:15 -06:00
|
|
|
#include "bitboard.h"
|
2008-08-31 23:59:13 -06:00
|
|
|
#include "evaluate.h"
|
2013-04-28 16:54:08 -06:00
|
|
|
#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"
|
2015-02-27 01:52:56 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
namespace Trace {
|
2015-02-27 01:52:56 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
enum Tracing { NO_TRACE, TRACE };
|
2015-08-25 09:12:51 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
enum Term { // The first 8 entries are reserved for PieceType
|
|
|
|
MATERIAL = 8, IMBALANCE, MOBILITY, THREAT, PASSED, SPACE, INITIATIVE, TOTAL, TERM_NB
|
|
|
|
};
|
2015-08-25 09:12:51 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
Score scores[TERM_NB][COLOR_NB];
|
2015-08-25 09:12:51 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
double to_cp(Value v) { return double(v) / PawnValueEg; }
|
2015-08-25 09:12:51 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
void add(int idx, Color c, Score s) {
|
|
|
|
scores[idx][c] = s;
|
|
|
|
}
|
2015-08-25 09:12:51 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
void add(int idx, Score w, Score b = SCORE_ZERO) {
|
|
|
|
scores[idx][WHITE] = w;
|
|
|
|
scores[idx][BLACK] = b;
|
2015-02-27 01:52:56 -07:00
|
|
|
}
|
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
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;
|
|
|
|
}
|
2015-02-27 01:52:56 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
std::ostream& operator<<(std::ostream& os, Term t) {
|
2017-06-21 15:01:59 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
if (t == MATERIAL || t == IMBALANCE || t == INITIATIVE || t == TOTAL)
|
|
|
|
os << " ---- ----" << " | " << " ---- ----";
|
|
|
|
else
|
|
|
|
os << scores[t][WHITE] << " | " << scores[t][BLACK];
|
2017-06-21 15:01:59 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
os << " | " << scores[t][WHITE] - scores[t][BLACK] << "\n";
|
|
|
|
return os;
|
|
|
|
}
|
|
|
|
}
|
2017-06-21 15:01:59 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
using namespace Trace;
|
2017-01-17 19:40:31 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
namespace {
|
2013-04-28 16:54:08 -06:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
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);
|
2016-07-03 06:29:53 -06:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Bitboard KingFlank[FILE_NB] = {
|
2018-02-20 09:10:37 -07:00
|
|
|
QueenSide, QueenSide, QueenSide,
|
|
|
|
CenterFiles, CenterFiles,
|
|
|
|
KingSide, KingSide, KingSide
|
|
|
|
};
|
2013-04-28 16:54:08 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Threshold for lazy and space evaluation
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Value LazyThreshold = Value(1500);
|
|
|
|
constexpr Value SpaceThreshold = Value(12222);
|
2013-04-28 16:54:08 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// KingAttackWeights[PieceType] contains king attack weights by piece type
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr int KingAttackWeights[PIECE_TYPE_NB] = { 0, 0, 78, 56, 45, 11 };
|
2013-04-28 16:54:08 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Penalties for enemy's safe checks
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr int QueenSafeCheck = 780;
|
|
|
|
constexpr int RookSafeCheck = 880;
|
|
|
|
constexpr int BishopSafeCheck = 435;
|
|
|
|
constexpr int KnightSafeCheck = 790;
|
2013-04-28 16:54:08 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
#define S(mg, eg) make_score(mg, eg)
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-03-05 19:20:27 -07:00
|
|
|
// MobilityBonus[PieceType-2][attacked] contains bonuses for middle and end game,
|
2017-01-17 19:40:31 -07:00
|
|
|
// indexed by piece type and number of attacked squares in the mobility area.
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score MobilityBonus[][32] = {
|
2017-02-19 14:56:17 -07:00
|
|
|
{ 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) },
|
2017-05-07 21:56:04 -06:00
|
|
|
{ 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) },
|
2017-02-19 14:56:17 -07:00
|
|
|
{ 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
|
|
|
};
|
|
|
|
|
2017-01-18 19:10:31 -07:00
|
|
|
// Outpost[knight/bishop][supported by pawn] contains bonuses for minor
|
2018-02-20 09:10:37 -07:00
|
|
|
// pieces if they occupy or can reach an outpost square, bigger if that
|
|
|
|
// square is supported by a pawn.
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score Outpost[][2] = {
|
2017-09-16 06:07:41 -06:00
|
|
|
{ S(22, 6), S(36,12) }, // Knight
|
|
|
|
{ S( 9, 2), S(15, 5) } // Bishop
|
2015-11-14 07:30:50 -07:00
|
|
|
};
|
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// RookOnFile[semiopen/open] contains bonuses for each rook when there is
|
|
|
|
// no (friendly) pawn on the rook file.
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score RookOnFile[] = { S(20, 7), S(45, 20) };
|
2015-12-30 04:29:25 -07:00
|
|
|
|
2016-12-28 15:14:09 -07:00
|
|
|
// 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.
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score ThreatByMinor[PIECE_TYPE_NB] = {
|
2018-02-08 07:13:26 -07:00
|
|
|
S(0, 0), S(0, 31), S(39, 42), S(57, 44), S(68, 112), S(47, 120)
|
2009-11-12 09:42:43 -07:00
|
|
|
};
|
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score ThreatByRook[PIECE_TYPE_NB] = {
|
2018-02-08 07:13:26 -07:00
|
|
|
S(0, 0), S(0, 24), S(38, 71), S(38, 61), S(0, 38), S(36, 38)
|
2016-12-28 15:14:09 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
// ThreatByKing[on one/on many] contains bonuses for king attacks on
|
2016-01-16 14:34:29 -07:00
|
|
|
// pawns or pieces which are not pawn-defended.
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score ThreatByKing[] = { S(3, 65), S(9, 145) };
|
2009-11-12 09:42:43 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// PassedRank[Rank] contains a bonus according to the rank of a passed pawn
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score PassedRank[RANK_NB] = {
|
2018-02-20 09:10:37 -07:00
|
|
|
S(0, 0), S(5, 7), S(5, 13), S(32, 42), S(70, 70), S(172, 170), S(217, 269)
|
2015-08-09 11:25:41 -06:00
|
|
|
};
|
|
|
|
|
2015-12-30 04:29:25 -07:00
|
|
|
// PassedFile[File] contains a bonus according to the file of a passed pawn
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score PassedFile[FILE_NB] = {
|
2018-02-20 09:10:37 -07:00
|
|
|
S( 9, 10), S(2, 10), S(1, -8), S(-20,-12),
|
|
|
|
S(-20,-12), S(1, -8), S(2, 10), S( 9, 10)
|
2015-10-03 04:46:53 -06:00
|
|
|
};
|
2017-03-08 19:45:09 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// PassedDanger[Rank] contains a term to weight the passed score
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr int PassedDanger[RANK_NB] = { 0, 0, 0, 2, 7, 12, 19 };
|
2018-02-20 09:10:37 -07:00
|
|
|
|
|
|
|
// KingProtector[PieceType-2] contains a penalty according to distance from king
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score KingProtector[] = { S(3, 5), S(4, 3), S(3, 0), S(1, -1) };
|
2018-02-20 09:10:37 -07:00
|
|
|
|
|
|
|
// Assorted bonuses and penalties
|
2018-03-18 16:38:58 -06:00
|
|
|
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);
|
2018-03-18 16:38:58 -06:00
|
|
|
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);
|
2018-02-20 09:10:37 -07:00
|
|
|
|
|
|
|
#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
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
public:
|
|
|
|
Evaluation() = delete;
|
|
|
|
explicit Evaluation(const Position& p) : pos(p) {}
|
|
|
|
Evaluation& operator=(const Evaluation&) = delete;
|
|
|
|
Value value();
|
2009-11-07 07:02:10 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
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;
|
2013-06-01 03:48:38 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
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
|
2018-03-08 18:04:33 -07:00
|
|
|
// is also calculated is ALL_PIECES.
|
2018-02-20 09:10:37 -07:00
|
|
|
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];
|
2013-06-01 03:48:38 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// 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];
|
|
|
|
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
// 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.
|
2018-02-20 09:10:37 -07:00
|
|
|
int kingAttackersWeight[COLOR_NB];
|
|
|
|
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
// 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
|
2018-02-20 09:10:37 -07:00
|
|
|
// a white knight on g5 and black's king is on g8, this white knight adds 2
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
// to kingAttacksCount[WHITE].
|
|
|
|
int kingAttacksCount[COLOR_NB];
|
2018-02-20 09:10:37 -07:00
|
|
|
};
|
2010-05-15 06:29:21 -06:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// 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.
|
2017-06-21 15:01:59 -06:00
|
|
|
template<Tracing T> template<Color Us>
|
|
|
|
void Evaluation<T>::initialize() {
|
2010-05-15 06:29:21 -06:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
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);
|
2010-05-15 06:29:21 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Find our pawns that are blocked or on the first two ranks
|
2017-01-17 19:40:31 -07:00
|
|
|
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.
|
2017-06-21 15:01:59 -06:00
|
|
|
mobilityArea[Us] = ~(b | pos.square<KING>(Us) | pe->pawn_attacks(Them));
|
2017-01-17 19:40:31 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Initialise attackedBy bitboards for kings and pawns
|
|
|
|
attackedBy[Us][KING] = pos.attacks_from<KING>(pos.square<KING>(Us));
|
2017-06-21 15:01:59 -06:00
|
|
|
attackedBy[Us][PAWN] = pe->pawn_attacks(Us);
|
2018-02-20 09:10:37 -07:00
|
|
|
attackedBy[Us][ALL_PIECES] = attackedBy[Us][KING] | attackedBy[Us][PAWN];
|
|
|
|
attackedBy2[Us] = attackedBy[Us][KING] & attackedBy[Us][PAWN];
|
2017-01-17 19:40:31 -07:00
|
|
|
|
|
|
|
// Init our king safety tables only if we are going to use them
|
2017-05-17 19:23:07 -06:00
|
|
|
if (pos.non_pawn_material(Them) >= RookValueMg + KnightValueMg)
|
2010-09-12 07:02:33 -06:00
|
|
|
{
|
2018-02-20 09:10:37 -07:00
|
|
|
kingRing[Us] = attackedBy[Us][KING];
|
2017-05-15 20:26:27 -06:00
|
|
|
if (relative_rank(Us, pos.square<KING>(Us)) == RANK_1)
|
2018-02-20 09:10:37 -07:00
|
|
|
kingRing[Us] |= shift<Up>(kingRing[Us]);
|
2017-05-15 20:26:27 -06:00
|
|
|
|
2018-03-26 01:26:50 -06:00
|
|
|
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]);
|
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
kingAttackersCount[Them] = popcount(attackedBy[Us][KING] & pe->pawn_attacks(Them));
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
kingAttacksCount[Them] = kingAttackersWeight[Them] = 0;
|
2013-10-18 09:42:52 -06:00
|
|
|
}
|
|
|
|
else
|
2017-06-21 15:01:59 -06:00
|
|
|
kingRing[Us] = kingAttackersCount[Them] = 0;
|
2010-05-15 06:29:21 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Evaluation::pieces() scores pieces of a given color and type
|
|
|
|
template<Tracing T> template<Color Us, PieceType Pt>
|
|
|
|
Score Evaluation<T>::pieces() {
|
2017-01-17 19:40:31 -07:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
|
|
|
|
constexpr Bitboard OutpostRanks = (Us == WHITE ? Rank4BB | Rank5BB | Rank6BB
|
2018-03-20 18:26:12 -06:00
|
|
|
: Rank5BB | Rank4BB | Rank3BB);
|
2015-08-04 01:00:52 -06:00
|
|
|
const Square* pl = pos.squares<Pt>(Us);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2016-12-28 15:14:09 -07: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;
|
2016-12-28 15:14:09 -07:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
attackedBy[Us][Pt] = 0;
|
2010-08-24 07:59:24 -06:00
|
|
|
|
2011-06-28 08:16:43 -06:00
|
|
|
while ((s = *pl++) != SQ_NONE)
|
2009-03-06 08:29:46 -07:00
|
|
|
{
|
2009-11-12 09:42:43 -07:00
|
|
|
// Find attacked squares, including x-ray attacks for bishops and rooks
|
2017-12-22 03:50:09 -07:00
|
|
|
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))
|
2014-02-15 05:27:16 -07:00
|
|
|
: pos.attacks_from<Pt>(s);
|
2009-05-09 15:21:26 -06:00
|
|
|
|
2018-02-26 17:18:33 -07:00
|
|
|
if (pos.blockers_for_king(Us) & s)
|
2015-08-04 01:00:52 -06:00
|
|
|
b &= LineBB[pos.square<KING>(Us)][s];
|
2013-11-07 11:59:11 -07:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
attackedBy2[Us] |= attackedBy[Us][ALL_PIECES] & b;
|
2018-02-20 09:10:37 -07:00
|
|
|
attackedBy[Us][Pt] |= b;
|
|
|
|
attackedBy[Us][ALL_PIECES] |= b;
|
2009-11-11 13:17:38 -07:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
if (b & kingRing[Them])
|
2009-11-11 13:17:38 -07:00
|
|
|
{
|
2017-06-21 15:01:59 -06:00
|
|
|
kingAttackersCount[Us]++;
|
|
|
|
kingAttackersWeight[Us] += KingAttackWeights[Pt];
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
kingAttacksCount[Us] += popcount(b & attackedBy[Them][KING]);
|
2009-11-11 13:17:38 -07:00
|
|
|
}
|
|
|
|
|
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]);
|
2013-07-13 15:07:24 -06:00
|
|
|
|
2017-05-09 05:50:05 -06:00
|
|
|
mobility[Us] += MobilityBonus[Pt - 2][mob];
|
2017-03-08 19:45:09 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Penalty if the piece is far from the king
|
|
|
|
score -= KingProtector[Pt - 2] * distance(s, pos.square<KING>(Us));
|
2009-10-25 01:16:34 -06:00
|
|
|
|
2014-02-15 05:27:16 -07:00
|
|
|
if (Pt == BISHOP || Pt == KNIGHT)
|
2013-08-13 06:19:42 -06:00
|
|
|
{
|
2018-02-20 09:10:37 -07:00
|
|
|
// Bonus if piece is on an outpost square or can reach one
|
2017-06-21 15:01:59 -06:00
|
|
|
bb = OutpostRanks & ~pe->pawn_attacks_span(Them);
|
2015-11-14 07:30:50 -07:00
|
|
|
if (bb & s)
|
2017-12-03 10:29:55 -07:00
|
|
|
score += Outpost[Pt == BISHOP][bool(attackedBy[Us][PAWN] & s)] * 2;
|
2018-02-20 09:10:37 -07:00
|
|
|
|
|
|
|
else if (bb &= b & ~pos.pieces(Us))
|
|
|
|
score += Outpost[Pt == BISHOP][bool(attackedBy[Us][PAWN] & bb)];
|
2013-08-13 06:19:42 -06:00
|
|
|
|
2014-12-27 02:47:21 -07:00
|
|
|
// Bonus when behind a pawn
|
2013-08-13 06:19:42 -06:00
|
|
|
if ( relative_rank(Us, s) < RANK_5
|
|
|
|
&& (pos.pieces(PAWN) & (s + pawn_push(Us))))
|
2013-08-17 03:05:55 -06:00
|
|
|
score += MinorBehindPawn;
|
2014-12-27 02:47:21 -07:00
|
|
|
|
|
|
|
if (Pt == BISHOP)
|
2017-10-01 16:41:06 -06:00
|
|
|
{
|
2018-02-20 09:10:37 -07:00
|
|
|
// Penalty according to number of pawns on the same color square as the bishop
|
2017-06-21 15:01:59 -06:00
|
|
|
score -= BishopPawns * pe->pawns_on_same_color_squares(Us, s);
|
2014-12-27 02:47:21 -07:00
|
|
|
|
2017-10-07 14:35:19 -06:00
|
|
|
// 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)))
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
score += LongDiagonalBishop;
|
2017-10-01 16:41:06 -06:00
|
|
|
}
|
|
|
|
|
2014-12-27 02:47:21 -07:00
|
|
|
// 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)))
|
|
|
|
{
|
2017-12-04 09:52:31 -07:00
|
|
|
Direction d = pawn_push(Us) + (file_of(s) == FILE_A ? EAST : WEST);
|
2014-12-27 02:47:21 -07:00
|
|
|
if (pos.piece_on(s + d) == make_piece(Us, PAWN))
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
score -= !pos.empty(s + d + pawn_push(Us)) ? CorneredBishop * 4
|
|
|
|
: pos.piece_on(s + d + d) == make_piece(Us, PAWN) ? CorneredBishop * 2
|
|
|
|
: CorneredBishop;
|
2014-12-27 02:47:21 -07:00
|
|
|
}
|
2013-08-13 06:19:42 -06:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
Remove QueenOn7th and QueenOnPawn
Small simplification.
Passed SPRT(-3,1) both at STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17051 W: 3132 L: 3005 D: 10914
and LTC:
LLR: 4.55 (-2.94,2.94) [-3.00,1.00]
Total: 24890 W: 3842 L: 3646 D: 17402
The rationale behind this is that I've never managed to add a
Queen on 7th rank bonus in DiscoCheck, because it never showed
to be positive (evne slightly) in testing. The only thing that
worked is Rook on 7th rank.
In terms of SF code, it seemed natural to group it with QueenOnPawn
as well as those are done together. I know you're against groupping
in general, but when it comes to non regression test, you are being
more conservative by groupping. If the group passes SPRT(-3,1) it's
safer to commit, than test every component in SPRT(-3,1) and end up
with the risk of commiting several -1 elo regression instead of just
one -1 elo regression.
In chess terms, perhaps it's just easier to manouver a Queen (which
can more also diagonaly) than a Rook. Therefore you can let the search
do its job without needing eval ad-hoc terms to guide it. For the Rook
which takes more moves to manouver such eval terms can be (marginally)
useful.
bench: 7473314
2014-04-03 07:31:42 -06:00
|
|
|
if (Pt == ROOK)
|
2009-03-06 08:29:46 -07:00
|
|
|
{
|
2018-03-31 19:13:29 -06:00
|
|
|
// Bonus for aligning rook with enemy pawns on the same rank/file
|
Remove QueenOn7th and QueenOnPawn
Small simplification.
Passed SPRT(-3,1) both at STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17051 W: 3132 L: 3005 D: 10914
and LTC:
LLR: 4.55 (-2.94,2.94) [-3.00,1.00]
Total: 24890 W: 3842 L: 3646 D: 17402
The rationale behind this is that I've never managed to add a
Queen on 7th rank bonus in DiscoCheck, because it never showed
to be positive (evne slightly) in testing. The only thing that
worked is Rook on 7th rank.
In terms of SF code, it seemed natural to group it with QueenOnPawn
as well as those are done together. I know you're against groupping
in general, but when it comes to non regression test, you are being
more conservative by groupping. If the group passes SPRT(-3,1) it's
safer to commit, than test every component in SPRT(-3,1) and end up
with the risk of commiting several -1 elo regression instead of just
one -1 elo regression.
In chess terms, perhaps it's just easier to manouver a Queen (which
can more also diagonaly) than a Rook. Therefore you can let the search
do its job without needing eval ad-hoc terms to guide it. For the Rook
which takes more moves to manouver such eval terms can be (marginally)
useful.
bench: 7473314
2014-04-03 07:31:42 -06:00
|
|
|
if (relative_rank(Us, s) >= RANK_5)
|
2016-04-20 22:23:40 -06:00
|
|
|
score += RookOnPawn * popcount(pos.pieces(Them, PAWN) & PseudoAttacks[ROOK][s]);
|
2011-01-03 14:32:57 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Bonus for rook on an open or semi-open file
|
2017-06-21 15:01:59 -06:00
|
|
|
if (pe->semiopen_file(Us, file_of(s)))
|
2017-12-03 10:29:55 -07:00
|
|
|
score += RookOnFile[bool(pe->semiopen_file(Them, file_of(s)))];
|
2008-09-24 08:45:19 -06:00
|
|
|
|
2017-01-17 19:40:31 -07:00
|
|
|
// Penalty when trapped by the king, even more if the king cannot castle
|
2015-12-30 04:29:25 -07:00
|
|
|
else if (mob <= 3)
|
2014-12-27 02:47:21 -07:00
|
|
|
{
|
2018-02-15 11:34:23 -07:00
|
|
|
File kf = file_of(pos.square<KING>(Us));
|
|
|
|
if ((kf < FILE_E) == (file_of(s) < kf))
|
2014-12-27 02:47:21 -07:00
|
|
|
score -= (TrappedRook - make_score(mob * 22, 0)) * (1 + !pos.can_castle(Us));
|
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
2016-06-04 07:57:17 -06:00
|
|
|
|
|
|
|
if (Pt == QUEEN)
|
|
|
|
{
|
|
|
|
// Penalty if any relative pin or discovered attack against the queen
|
2018-02-26 17:18:33 -07:00
|
|
|
Bitboard queenPinners;
|
|
|
|
if (pos.slider_blockers(pos.pieces(Them, ROOK, BISHOP), s, queenPinners))
|
2016-06-04 07:57:17 -06:00
|
|
|
score -= WeakQueen;
|
|
|
|
}
|
2008-09-24 08:45:19 -06:00
|
|
|
}
|
2017-06-21 15:01:59 -06:00
|
|
|
if (T)
|
2015-08-25 09:12:51 -06:00
|
|
|
Trace::add(Pt, Us, score);
|
2011-02-26 06:09:58 -07:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
return score;
|
2009-09-28 03:46:55 -06:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2009-09-28 05:27:05 -06:00
|
|
|
|
2018-02-20 09:10:37 -07: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 {
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
|
|
|
|
constexpr Bitboard Camp = (Us == WHITE ? AllSquares ^ Rank6BB ^ Rank7BB ^ Rank8BB
|
2018-03-27 08:44:47 -06:00
|
|
|
: AllSquares ^ Rank1BB ^ Rank2BB ^ Rank3BB);
|
2009-11-12 11:01:44 -07:00
|
|
|
|
2016-12-28 15:14:09 -07:00
|
|
|
const Square ksq = pos.square<KING>(Us);
|
2018-02-26 17:18:33 -07:00
|
|
|
Bitboard weak, b, b1, b2, safe, unsafeChecks, pinned;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2012-03-28 04:44:41 -06:00
|
|
|
// King shelter and enemy pawns storm
|
2017-06-21 15:01:59 -06:00
|
|
|
Score score = pe->king_safety<Us>(pos, ksq);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-10-18 09:42:52 -06:00
|
|
|
// Main king safety evaluation
|
2018-02-20 09:10:37 -07:00
|
|
|
if (kingAttackersCount[Them] > 1 - pos.count<QUEEN>(Them))
|
2008-09-25 08:43:37 -06:00
|
|
|
{
|
2018-03-15 22:34:38 -06:00
|
|
|
int kingDanger = 0;
|
|
|
|
unsafeChecks = 0;
|
2018-02-20 09:10:37 -07:00
|
|
|
|
2017-11-11 05:37:29 -07:00
|
|
|
// Attacked squares defended at most once by our queen or king
|
|
|
|
weak = attackedBy[Them][ALL_PIECES]
|
|
|
|
& ~attackedBy2[Us]
|
2018-02-20 09:10:37 -07:00
|
|
|
& (~attackedBy[Us][ALL_PIECES] | attackedBy[Us][KING] | attackedBy[Us][QUEEN]);
|
2010-05-06 12:10:04 -06:00
|
|
|
|
2017-01-17 19:40:31 -07:00
|
|
|
// Analyse the safe enemy's checks which are possible on next move
|
2017-01-30 14:05:43 -07:00
|
|
|
safe = ~pos.pieces(Them);
|
2017-11-11 05:37:29 -07:00
|
|
|
safe &= ~attackedBy[Us][ALL_PIECES] | (weak & attackedBy2[Them]);
|
Unsafe checks
Introducing a new multi-purpose penalty related to King safety, which
includes all kind of potential checks (from unsafe or unavailable
squares currently occupied by some other piece)
This will indirectly detect and reward some pins, discovered checks, and
motifs such as square vacation, or rook behind its pawn and aligned with
King (example Black Rg8, g7 against Kg1),
and penalize some pawn blockers (if they move, it allows a discovered
check by the pawn).
And since it looks also at protected squares, it detects some potential
defense overloading.
Finally, the rook contact checks had been removed some time ago. This
test will give a small bonus for them, as well as for bishop contact
checks.
Passed STC
http://tests.stockfishchess.org/tests/view/5729ec740ebc59301a354b36
LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 13306 W: 2477 L: 2296 D: 8533
and LTC
http://tests.stockfishchess.org/tests/view/572a5be00ebc59301a354b65
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 20369 W: 2750 L: 2565 D: 15054
bench: 9298175
2016-05-06 07:40:56 -06:00
|
|
|
|
2017-12-06 06:23:41 -07:00
|
|
|
b1 = attacks_bb<ROOK >(ksq, pos.pieces() ^ pos.pieces(Us, QUEEN));
|
|
|
|
b2 = attacks_bb<BISHOP>(ksq, pos.pieces() ^ pos.pieces(Us, QUEEN));
|
2010-05-06 12:10:04 -06:00
|
|
|
|
2010-05-07 01:39:28 -06:00
|
|
|
// Enemy queen safe checks
|
2017-11-11 05:37:29 -07:00
|
|
|
if ((b1 | b2) & attackedBy[Them][QUEEN] & safe & ~attackedBy[Us][QUEEN])
|
2017-12-10 08:13:28 -07:00
|
|
|
kingDanger += QueenSafeCheck;
|
Unsafe checks
Introducing a new multi-purpose penalty related to King safety, which
includes all kind of potential checks (from unsafe or unavailable
squares currently occupied by some other piece)
This will indirectly detect and reward some pins, discovered checks, and
motifs such as square vacation, or rook behind its pawn and aligned with
King (example Black Rg8, g7 against Kg1),
and penalize some pawn blockers (if they move, it allows a discovered
check by the pawn).
And since it looks also at protected squares, it detects some potential
defense overloading.
Finally, the rook contact checks had been removed some time ago. This
test will give a small bonus for them, as well as for bishop contact
checks.
Passed STC
http://tests.stockfishchess.org/tests/view/5729ec740ebc59301a354b36
LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 13306 W: 2477 L: 2296 D: 8533
and LTC
http://tests.stockfishchess.org/tests/view/572a5be00ebc59301a354b65
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 20369 W: 2750 L: 2565 D: 15054
bench: 9298175
2016-05-06 07:40:56 -06:00
|
|
|
|
2017-12-10 08:13:28 -07:00
|
|
|
b1 &= attackedBy[Them][ROOK];
|
|
|
|
b2 &= attackedBy[Them][BISHOP];
|
2017-01-17 19:40:31 -07:00
|
|
|
|
2017-12-10 08:13:28 -07:00
|
|
|
// Enemy rooks checks
|
|
|
|
if (b1 & safe)
|
|
|
|
kingDanger += RookSafeCheck;
|
|
|
|
else
|
|
|
|
unsafeChecks |= b1;
|
Unsafe checks
Introducing a new multi-purpose penalty related to King safety, which
includes all kind of potential checks (from unsafe or unavailable
squares currently occupied by some other piece)
This will indirectly detect and reward some pins, discovered checks, and
motifs such as square vacation, or rook behind its pawn and aligned with
King (example Black Rg8, g7 against Kg1),
and penalize some pawn blockers (if they move, it allows a discovered
check by the pawn).
And since it looks also at protected squares, it detects some potential
defense overloading.
Finally, the rook contact checks had been removed some time ago. This
test will give a small bonus for them, as well as for bishop contact
checks.
Passed STC
http://tests.stockfishchess.org/tests/view/5729ec740ebc59301a354b36
LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 13306 W: 2477 L: 2296 D: 8533
and LTC
http://tests.stockfishchess.org/tests/view/572a5be00ebc59301a354b65
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 20369 W: 2750 L: 2565 D: 15054
bench: 9298175
2016-05-06 07:40:56 -06:00
|
|
|
|
2017-12-10 08:13:28 -07:00
|
|
|
// Enemy bishops checks
|
|
|
|
if (b2 & safe)
|
|
|
|
kingDanger += BishopSafeCheck;
|
|
|
|
else
|
|
|
|
unsafeChecks |= b2;
|
Unsafe checks
Introducing a new multi-purpose penalty related to King safety, which
includes all kind of potential checks (from unsafe or unavailable
squares currently occupied by some other piece)
This will indirectly detect and reward some pins, discovered checks, and
motifs such as square vacation, or rook behind its pawn and aligned with
King (example Black Rg8, g7 against Kg1),
and penalize some pawn blockers (if they move, it allows a discovered
check by the pawn).
And since it looks also at protected squares, it detects some potential
defense overloading.
Finally, the rook contact checks had been removed some time ago. This
test will give a small bonus for them, as well as for bishop contact
checks.
Passed STC
http://tests.stockfishchess.org/tests/view/5729ec740ebc59301a354b36
LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 13306 W: 2477 L: 2296 D: 8533
and LTC
http://tests.stockfishchess.org/tests/view/572a5be00ebc59301a354b65
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 20369 W: 2750 L: 2565 D: 15054
bench: 9298175
2016-05-06 07:40:56 -06:00
|
|
|
|
2017-12-10 08:13:28 -07:00
|
|
|
// Enemy knights checks
|
2017-06-21 15:01:59 -06:00
|
|
|
b = pos.attacks_from<KNIGHT>(ksq) & attackedBy[Them][KNIGHT];
|
Unsafe checks
Introducing a new multi-purpose penalty related to King safety, which
includes all kind of potential checks (from unsafe or unavailable
squares currently occupied by some other piece)
This will indirectly detect and reward some pins, discovered checks, and
motifs such as square vacation, or rook behind its pawn and aligned with
King (example Black Rg8, g7 against Kg1),
and penalize some pawn blockers (if they move, it allows a discovered
check by the pawn).
And since it looks also at protected squares, it detects some potential
defense overloading.
Finally, the rook contact checks had been removed some time ago. This
test will give a small bonus for them, as well as for bishop contact
checks.
Passed STC
http://tests.stockfishchess.org/tests/view/5729ec740ebc59301a354b36
LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 13306 W: 2477 L: 2296 D: 8533
and LTC
http://tests.stockfishchess.org/tests/view/572a5be00ebc59301a354b65
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 20369 W: 2750 L: 2565 D: 15054
bench: 9298175
2016-05-06 07:40:56 -06:00
|
|
|
if (b & safe)
|
2017-12-10 08:13:28 -07:00
|
|
|
kingDanger += KnightSafeCheck;
|
|
|
|
else
|
|
|
|
unsafeChecks |= b;
|
|
|
|
|
|
|
|
// Unsafe or occupied checking squares will also be considered, as long as
|
2017-12-17 00:50:45 -07:00
|
|
|
// the square is in the attacker's mobility area.
|
|
|
|
unsafeChecks &= mobilityArea[Them];
|
2018-02-26 17:18:33 -07:00
|
|
|
pinned = pos.blockers_for_king(Us) & pos.pieces(Us);
|
2017-12-10 08:13:28 -07:00
|
|
|
|
|
|
|
kingDanger += kingAttackersCount[Them] * kingAttackersWeight[Them]
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
+ 102 * kingAttacksCount[Them]
|
2017-12-10 08:13:28 -07:00
|
|
|
+ 191 * popcount(kingRing[Us] & weak)
|
2018-02-26 17:18:33 -07:00
|
|
|
+ 143 * popcount(pinned | unsafeChecks)
|
2017-12-10 08:13:28 -07:00
|
|
|
- 848 * !pos.count<QUEEN>(Them)
|
|
|
|
- 9 * mg_value(score) / 8
|
|
|
|
+ 40;
|
2010-05-06 12:10:04 -06:00
|
|
|
|
2018-01-28 06:56:45 -07:00
|
|
|
// Transform the kingDanger units into a Score, and subtract it from the evaluation
|
2016-09-07 15:37:06 -06:00
|
|
|
if (kingDanger > 0)
|
2018-01-13 00:56:42 -07:00
|
|
|
{
|
|
|
|
int mobilityDanger = mg_value(mobility[Them] - mobility[Us]);
|
|
|
|
kingDanger = std::max(0, kingDanger + mobilityDanger);
|
2017-05-17 19:19:47 -06:00
|
|
|
score -= make_score(kingDanger * kingDanger / 4096, kingDanger / 16);
|
2018-01-13 00:56:42 -07:00
|
|
|
}
|
2010-08-25 13:16:27 -06:00
|
|
|
}
|
2011-02-26 06:09:58 -07:00
|
|
|
|
2018-02-27 11:10:40 -07:00
|
|
|
Bitboard kf = KingFlank[file_of(ksq)];
|
2016-08-27 16:16:28 -06:00
|
|
|
|
2018-02-27 11:10:40 -07:00
|
|
|
// Penalty when our king is on a pawnless flank
|
|
|
|
if (!(pos.pieces(PAWN) & kf))
|
|
|
|
score -= PawnlessFlank;
|
2016-08-27 16:16:28 -06:00
|
|
|
|
2018-03-07 14:12:29 -07:00
|
|
|
// Find the squares that opponent attacks in our king flank, and the squares
|
2018-02-27 11:10:40 -07:00
|
|
|
// 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];
|
2016-08-27 16:16:28 -06:00
|
|
|
|
2018-02-27 11:10:40 -07:00
|
|
|
// King tropism, to anticipate slow motion attacks on our king
|
|
|
|
score -= CloseEnemies * (popcount(b1) + popcount(b2));
|
2016-08-27 16:16:28 -06:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
if (T)
|
2015-08-25 09:12:51 -06:00
|
|
|
Trace::add(KING, Us, score);
|
2011-02-26 06:09:58 -07:00
|
|
|
|
2011-05-02 01:43:16 -06:00
|
|
|
return score;
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2014-10-23 11:10:11 -06:00
|
|
|
|
2018-02-20 09:10:37 -07: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 {
|
2013-10-18 09:42:52 -06:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
|
|
|
|
constexpr Direction Up = (Us == WHITE ? NORTH : SOUTH);
|
|
|
|
constexpr Bitboard TRank3BB = (Us == WHITE ? Rank3BB : Rank6BB);
|
2013-10-18 09:42:52 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
Bitboard b, weak, defended, nonPawnEnemies, stronglyProtected, safeThreats;
|
2013-10-18 09:42:52 -06:00
|
|
|
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
|
2018-02-20 09:10:37 -07:00
|
|
|
nonPawnEnemies = pos.pieces(Them) ^ pos.pieces(Them, PAWN);
|
2015-03-29 01:54:25 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// 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.
|
2017-06-21 15:01:59 -06:00
|
|
|
stronglyProtected = attackedBy[Them][PAWN]
|
|
|
|
| (attackedBy2[Them] & ~attackedBy2[Us]);
|
2017-02-25 18:43:54 -07:00
|
|
|
|
|
|
|
// Non-pawn enemies, strongly protected
|
2018-02-20 09:10:37 -07:00
|
|
|
defended = nonPawnEnemies & stronglyProtected;
|
2014-06-30 08:55:10 -06:00
|
|
|
|
2017-02-25 18:43:54 -07:00
|
|
|
// Enemies not strongly protected and under our attack
|
2018-02-20 09:10:37 -07:00
|
|
|
weak = pos.pieces(Them) & ~stronglyProtected & attackedBy[Us][ALL_PIECES];
|
2013-10-18 09:42:52 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Bonus according to the kind of attacking pieces
|
2015-10-18 20:17:37 -06:00
|
|
|
if (defended | weak)
|
2013-12-18 12:00:01 -07:00
|
|
|
{
|
2017-06-21 15:01:59 -06:00
|
|
|
b = (defended | weak) & (attackedBy[Us][KNIGHT] | attackedBy[Us][BISHOP]);
|
2014-11-04 08:40:37 -07:00
|
|
|
while (b)
|
2016-11-25 09:47:18 -07:00
|
|
|
{
|
|
|
|
Square s = pop_lsb(&b);
|
2016-12-28 15:14:09 -07:00
|
|
|
score += ThreatByMinor[type_of(pos.piece_on(s))];
|
2016-11-25 09:47:18 -07:00
|
|
|
if (type_of(pos.piece_on(s)) != PAWN)
|
|
|
|
score += ThreatByRank * (int)relative_rank(Them, s);
|
|
|
|
}
|
2013-12-18 12:00:01 -07:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
b = (pos.pieces(Them, QUEEN) | weak) & attackedBy[Us][ROOK];
|
2014-11-04 08:40:37 -07:00
|
|
|
while (b)
|
2016-11-25 09:47:18 -07:00
|
|
|
{
|
|
|
|
Square s = pop_lsb(&b);
|
2016-12-28 15:14:09 -07:00
|
|
|
score += ThreatByRook[type_of(pos.piece_on(s))];
|
2016-11-25 09:47:18 -07:00
|
|
|
if (type_of(pos.piece_on(s)) != PAWN)
|
|
|
|
score += ThreatByRank * (int)relative_rank(Them, s);
|
|
|
|
}
|
2014-04-26 17:35:46 -06:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
b = weak & attackedBy[Us][KING];
|
2014-09-19 08:33:42 -06:00
|
|
|
if (b)
|
2015-12-30 04:29:25 -07:00
|
|
|
score += ThreatByKing[more_than_one(b)];
|
2018-04-18 11:44:22 -06:00
|
|
|
|
|
|
|
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
|
|
|
}
|
2013-10-18 09:42:52 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Bonus for enemy unopposed weak pawns
|
2017-09-16 06:07:41 -06:00
|
|
|
if (pos.pieces(Us, ROOK, QUEEN))
|
|
|
|
score += WeakUnopposedPawn * pe->weak_unopposed(Them);
|
|
|
|
|
2018-04-18 11:44:22 -06:00
|
|
|
// 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);
|
|
|
|
|
2017-06-22 22:03:58 -06:00
|
|
|
// 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();
|
2015-02-02 20:16:50 -07:00
|
|
|
|
2017-06-22 22:03:58 -06:00
|
|
|
// Keep only the squares which are not completely unsafe
|
|
|
|
b &= ~attackedBy[Them][PAWN]
|
2017-06-21 15:01:59 -06:00
|
|
|
& (attackedBy[Us][ALL_PIECES] | ~attackedBy[Them][ALL_PIECES]);
|
2015-02-14 07:55:11 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Bonus for safe pawn threats on the next move
|
2018-02-21 14:31:38 -07:00
|
|
|
b = pawn_attacks_bb<Us>(b)
|
2015-02-02 20:16:50 -07:00
|
|
|
& pos.pieces(Them)
|
2017-06-21 15:01:59 -06:00
|
|
|
& ~attackedBy[Us][PAWN];
|
2015-02-02 20:16:50 -07:00
|
|
|
|
2016-04-20 22:23:40 -06:00
|
|
|
score += ThreatByPawnPush * popcount(b);
|
2015-02-02 20:16:50 -07:00
|
|
|
|
2018-03-08 18:04:33 -07:00
|
|
|
// Bonus for threats on the next moves against enemy queen
|
2018-03-07 14:12:29 -07:00
|
|
|
if (pos.count<QUEEN>(Them) == 1)
|
|
|
|
{
|
2018-03-08 18:04:33 -07:00
|
|
|
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));
|
2018-03-07 14:12:29 -07:00
|
|
|
|
2018-03-08 18:04:33 -07:00
|
|
|
score += SliderOnQueen * popcount(b & safeThreats & attackedBy2[Us]);
|
2018-03-07 14:12:29 -07:00
|
|
|
}
|
|
|
|
|
Implement an old Russian proverb
"Loose pieces drop, in blitz keep everything protected"
Adding a small S(2,2) bonus for knights, bishops, rooks, and
queens that are "connected" to each other (in the sense that
they are under attack by our own pieces) apparently is a good
thing. It probably helps the pieces work together a bit better.
STC
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12317 W: 2655 L: 2467 D: 7195
http://tests.stockfishchess.org/tests/view/5aa2d86b0ebc590297cb6474
LTC
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 35725 W: 5516 L: 5263 D: 24946
http://tests.stockfishchess.org/tests/view/5aa2fc6f0ebc590297cb64a8
How to continue from there (by Stefan Geschwentner)?
• First we should identify all other eval terms which have an overlap
with new connectivity bonus (like the outpost bonus). A simple way
would be subtract the connectivity bonus from them and look if this
better, or use a SPSA session for these terms.
• Tuning Connectivity himself with SPSA seems not so promising because
of the small range which is useful. Here manual testing changes of
Connectivity like +-1 seems better.
• The eg value is more important because in endgame the position gets
more open and so attacks on pieces are easier. Another important point
is that when defending/fortress-like positions each defending piece
needs a protection, otherwise attacks on them can break defense.
Closes https://github.com/official-stockfish/Stockfish/pull/1474
Bench: 5318575
2018-03-10 03:46:44 -07:00
|
|
|
// 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);
|
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
if (T)
|
2015-12-14 11:04:20 -07:00
|
|
|
Trace::add(THREAT, Us, score);
|
2013-10-18 09:42:52 -06:00
|
|
|
|
2015-12-14 11:04:20 -07:00
|
|
|
return score;
|
2013-10-18 09:42:52 -06:00
|
|
|
}
|
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Evaluation::passed() evaluates the passed pawns and candidate passed
|
2017-01-19 10:16:23 -07:00
|
|
|
// pawns of the given color.
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
template<Tracing T> template<Color Us>
|
|
|
|
Score Evaluation<T>::passed() const {
|
2009-01-06 07:49:33 -07:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
|
|
|
|
constexpr Direction Up = (Us == WHITE ? NORTH : SOUTH);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
auto king_proximity = [&](Color c, Square s) {
|
|
|
|
return std::min(distance(pos.square<KING>(c), s), 5);
|
|
|
|
};
|
|
|
|
|
2016-10-27 04:56:32 -06:00
|
|
|
Bitboard b, bb, squaresToQueen, defendedSquares, unsafeSquares;
|
2011-05-02 01:43:16 -06:00
|
|
|
Score score = SCORE_ZERO;
|
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
b = pe->passed_pawns(Us);
|
2009-10-10 03:31:43 -06:00
|
|
|
|
2013-05-25 03:57:18 -06:00
|
|
|
while (b)
|
|
|
|
{
|
2012-07-08 01:30:37 -06:00
|
|
|
Square s = pop_lsb(&b);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-06-22 22:03:58 -06:00
|
|
|
assert(!(pos.pieces(Them, PAWN) & forward_file_bb(Us, s + Up)));
|
2009-01-06 07:49:33 -07:00
|
|
|
|
2017-06-22 22:03:58 -06:00
|
|
|
bb = forward_file_bb(Us, s) & (attackedBy[Them][ALL_PIECES] | pos.pieces(Them));
|
2016-10-27 04:56:32 -06:00
|
|
|
score -= HinderPassedPawn * popcount(bb);
|
|
|
|
|
2018-01-28 06:56:45 -07:00
|
|
|
int r = relative_rank(Us, s);
|
2018-02-20 09:10:37 -07:00
|
|
|
int w = PassedDanger[r];
|
2009-01-06 07:49:33 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
Score bonus = PassedRank[r];
|
2009-01-06 07:49:33 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
if (w)
|
2009-10-10 03:31:43 -06:00
|
|
|
{
|
2017-06-22 22:03:58 -06:00
|
|
|
Square blockSq = s + Up;
|
2009-10-11 03:12:53 -06:00
|
|
|
|
2013-12-02 11:04:09 -07:00
|
|
|
// Adjust bonus based on the king's proximity
|
2018-02-20 09:10:37 -07:00
|
|
|
bonus += make_score(0, ( king_proximity(Them, blockSq) * 5
|
|
|
|
- king_proximity(Us, blockSq) * 2) * w);
|
2011-04-30 06:02:56 -06:00
|
|
|
|
|
|
|
// If blockSq is not the queening square then consider also a second push
|
2018-01-28 06:56:45 -07:00
|
|
|
if (r != RANK_7)
|
2018-02-20 09:10:37 -07:00
|
|
|
bonus -= make_score(0, king_proximity(Us, blockSq + Up) * w);
|
2009-01-06 07:49:33 -07:00
|
|
|
|
2013-12-02 11:04:09 -07:00
|
|
|
// If the pawn is free to advance, then increase the bonus
|
2013-09-28 06:43:50 -06:00
|
|
|
if (pos.empty(blockSq))
|
2009-01-06 07:49:33 -07:00
|
|
|
{
|
2014-07-14 07:15:07 -06:00
|
|
|
// 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.
|
2017-06-22 22:03:58 -06:00
|
|
|
defendedSquares = unsafeSquares = squaresToQueen = forward_file_bb(Us, s);
|
2014-07-14 07:15:07 -06:00
|
|
|
|
2017-06-22 22:03:58 -06:00
|
|
|
bb = forward_file_bb(Them, s) & pos.pieces(ROOK, QUEEN) & pos.attacks_from<ROOK>(s);
|
2014-07-14 07:15:07 -06:00
|
|
|
|
|
|
|
if (!(pos.pieces(Us) & bb))
|
2017-06-21 15:01:59 -06:00
|
|
|
defendedSquares &= attackedBy[Us][ALL_PIECES];
|
2014-07-14 07:15:07 -06:00
|
|
|
|
|
|
|
if (!(pos.pieces(Them) & bb))
|
2017-06-21 15:01:59 -06:00
|
|
|
unsafeSquares &= attackedBy[Them][ALL_PIECES] | pos.pieces(Them);
|
2013-08-22 08:19:58 -06:00
|
|
|
|
2014-04-17 22:41:22 -06:00
|
|
|
// If there aren't any enemy attacks, assign a big bonus. Otherwise
|
|
|
|
// assign a smaller bonus if the block square isn't attacked.
|
2018-02-08 07:13:26 -07:00
|
|
|
int k = !unsafeSquares ? 20 : !(unsafeSquares & blockSq) ? 9 : 0;
|
2014-04-17 22:41:22 -06:00
|
|
|
|
2016-01-16 14:34:29 -07:00
|
|
|
// If the path to the queen is fully defended, assign a big bonus.
|
2014-04-17 22:41:22 -06:00
|
|
|
// Otherwise assign a smaller bonus if the block square is defended.
|
2013-05-08 15:06:21 -06:00
|
|
|
if (defendedSquares == squaresToQueen)
|
|
|
|
k += 6;
|
2013-05-05 11:12:04 -06:00
|
|
|
|
2013-05-08 15:06:21 -06:00
|
|
|
else if (defendedSquares & blockSq)
|
2014-04-17 22:41:22 -06:00
|
|
|
k += 4;
|
2013-05-05 11:12:04 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
bonus += make_score(k * w, k * w);
|
2009-01-06 07:49:33 -07:00
|
|
|
}
|
2014-09-30 01:05:20 -06:00
|
|
|
else if (pos.pieces(Us) & blockSq)
|
2018-02-20 09:10:37 -07:00
|
|
|
bonus += make_score(w + r * 2, w + r * 2);
|
2018-03-31 19:13:29 -06:00
|
|
|
} // w != 0
|
2009-10-10 03:31:43 -06:00
|
|
|
|
2017-02-25 18:43:54 -07:00
|
|
|
// Scale down bonus for candidate passers which need more than one
|
2017-05-07 21:38:03 -06:00
|
|
|
// pawn push to become passed or have a pawn in front of them.
|
2018-02-20 09:10:37 -07:00
|
|
|
if ( !pos.pawn_passed(Us, s + Up)
|
|
|
|
|| (pos.pieces(PAWN) & forward_file_bb(Us, s)))
|
|
|
|
bonus = bonus / 2;
|
2017-01-19 10:16:23 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
score += bonus + PassedFile[file_of(s)];
|
2013-05-25 03:57:18 -06:00
|
|
|
}
|
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
if (T)
|
2016-02-07 13:58:20 -07:00
|
|
|
Trace::add(PASSED, Us, score);
|
2009-10-10 03:31:43 -06:00
|
|
|
|
2016-02-07 13:58:20 -07:00
|
|
|
return score;
|
2009-10-10 03:31:43 -06:00
|
|
|
}
|
|
|
|
|
2011-05-01 00:11:58 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Evaluation::space() computes the space evaluation for a given side. The
|
2008-12-21 08:26:36 -07:00
|
|
|
// 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
|
2014-12-31 02:41:20 -07:00
|
|
|
// twice. Finally, the space bonus is multiplied by a weight. The aim is to
|
|
|
|
// improve play on game opening.
|
2017-06-21 15:01:59 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
template<Tracing T> template<Color Us>
|
|
|
|
Score Evaluation<T>::space() const {
|
2008-12-21 08:26:36 -07:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
|
|
|
|
constexpr Bitboard SpaceMask =
|
2016-12-28 15:14:09 -07:00
|
|
|
Us == WHITE ? CenterFiles & (Rank2BB | Rank3BB | Rank4BB)
|
|
|
|
: CenterFiles & (Rank7BB | Rank6BB | Rank5BB);
|
2008-12-21 08:26:36 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
if (pos.non_pawn_material() < SpaceThreshold)
|
|
|
|
return SCORE_ZERO;
|
|
|
|
|
2008-12-21 08:26:36 -07:00
|
|
|
// Find the safe squares for our pieces inside the area defined by
|
2015-11-28 02:57:45 -07:00
|
|
|
// SpaceMask. A square is unsafe if it is attacked by an enemy
|
2008-12-21 08:26:36 -07:00
|
|
|
// pawn, or if it is undefended and attacked by an enemy piece.
|
2015-11-28 02:57:45 -07:00
|
|
|
Bitboard safe = SpaceMask
|
2012-05-01 05:01:38 -06:00
|
|
|
& ~pos.pieces(Us, PAWN)
|
2018-04-09 17:28:26 -06:00
|
|
|
& ~attackedBy[Them][PAWN];
|
2008-12-21 08:26:36 -07:00
|
|
|
|
2010-05-11 02:07:17 -06:00
|
|
|
// Find all squares which are at most three squares behind some friendly pawn
|
2012-05-01 05:01:38 -06:00
|
|
|
Bitboard behind = pos.pieces(Us, PAWN);
|
2014-04-21 12:54:55 -06:00
|
|
|
behind |= (Us == WHITE ? behind >> 8 : behind << 8);
|
|
|
|
behind |= (Us == WHITE ? behind >> 16 : behind << 16);
|
2008-12-21 08:26:36 -07:00
|
|
|
|
2018-03-05 06:10:13 -07:00
|
|
|
int bonus = popcount(safe) + popcount(behind & safe);
|
2017-06-21 15:01:59 -06:00
|
|
|
int weight = pos.count<ALL_PIECES>(Us) - 2 * pe->open_files();
|
2018-03-05 06:10:13 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
Score score = make_score(bonus * weight * weight / 16, 0);
|
2014-12-31 02:41:20 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
if (T)
|
|
|
|
Trace::add(SPACE, Us, score);
|
|
|
|
|
|
|
|
return score;
|
2008-12-21 08:26:36 -07:00
|
|
|
}
|
|
|
|
|
2015-10-15 22:27:52 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// 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.
|
2017-06-21 15:01:59 -06:00
|
|
|
|
|
|
|
template<Tracing T>
|
2018-02-20 09:10:37 -07:00
|
|
|
Score Evaluation<T>::initiative(Value eg) const {
|
2015-10-15 22:27:52 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
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);
|
2015-10-15 22:27:52 -06:00
|
|
|
|
|
|
|
// Compute the initiative bonus for the attacking side
|
2018-02-20 16:52:26 -07:00
|
|
|
int complexity = 8 * outflanking
|
2018-02-20 09:10:37 -07:00
|
|
|
+ 8 * pe->pawn_asymmetry()
|
|
|
|
+ 12 * pos.count<PAWN>()
|
|
|
|
+ 16 * pawnsOnBothFlanks
|
2018-03-12 03:09:02 -06:00
|
|
|
+ 48 * !pos.non_pawn_material()
|
2018-02-20 09:10:37 -07:00
|
|
|
-136 ;
|
2015-10-15 22:27:52 -06:00
|
|
|
|
2015-10-23 23:27:24 -06:00
|
|
|
// 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
|
2017-02-19 15:25:05 -07:00
|
|
|
// that the endgame score will never change sign after the bonus.
|
2018-02-20 16:52:26 -07:00
|
|
|
int v = ((eg > 0) - (eg < 0)) * std::max(complexity, -abs(eg));
|
2015-10-15 22:27:52 -06:00
|
|
|
|
2017-10-21 23:00:46 -06:00
|
|
|
if (T)
|
|
|
|
Trace::add(INITIATIVE, make_score(0, v));
|
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
return make_score(0, v);
|
2015-10-15 22:27:52 -06:00
|
|
|
}
|
|
|
|
|
2015-11-28 02:57:45 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// Evaluation::scale_factor() computes the scale factor for the winning side
|
2017-06-21 15:01:59 -06:00
|
|
|
|
|
|
|
template<Tracing T>
|
2018-02-20 09:10:37 -07:00
|
|
|
ScaleFactor Evaluation<T>::scale_factor(Value eg) const {
|
2015-11-28 02:57:45 -07:00
|
|
|
|
2016-02-25 11:38:35 -07:00
|
|
|
Color strongSide = eg > VALUE_DRAW ? WHITE : BLACK;
|
2018-02-20 09:10:37 -07:00
|
|
|
int sf = me->scale_factor(pos, strongSide);
|
2015-11-28 02:57:45 -07:00
|
|
|
|
|
|
|
// If we don't already have an unusual scale factor, check for certain
|
|
|
|
// types of endgames, and use a lower scale for those.
|
2017-02-05 17:02:02 -07:00
|
|
|
if (sf == SCALE_FACTOR_NORMAL || sf == SCALE_FACTOR_ONEPAWN)
|
2015-11-28 02:57:45 -07:00
|
|
|
{
|
|
|
|
if (pos.opposite_bishops())
|
|
|
|
{
|
2018-03-31 18:00:57 -06:00
|
|
|
// Endgame with opposite-colored bishops and no other pieces is almost a draw
|
2015-11-28 02:57:45 -07:00
|
|
|
if ( pos.non_pawn_material(WHITE) == BishopValueMg
|
|
|
|
&& pos.non_pawn_material(BLACK) == BishopValueMg)
|
2018-03-31 18:00:57 -06:00
|
|
|
sf = 31;
|
2015-11-28 02:57:45 -07:00
|
|
|
|
|
|
|
// Endgame with opposite-colored bishops, but also other pieces. Still
|
|
|
|
// a bit drawish, but not as drawish as with only the two bishops.
|
2018-02-20 09:10:37 -07:00
|
|
|
else
|
|
|
|
sf = 46;
|
2015-11-28 02:57:45 -07:00
|
|
|
}
|
2018-02-20 09:10:37 -07:00
|
|
|
// Endings where weaker side can place his king in front of the enemy's
|
2015-11-28 02:57:45 -07:00
|
|
|
// pawns are drawish.
|
2016-02-25 11:38:35 -07:00
|
|
|
else if ( abs(eg) <= BishopValueEg
|
2016-08-15 04:24:48 -06:00
|
|
|
&& pos.count<PAWN>(strongSide) <= 2
|
2015-11-28 02:57:45 -07:00
|
|
|
&& !pos.pawn_passed(~strongSide, pos.square<KING>(~strongSide)))
|
2018-02-20 09:10:37 -07:00
|
|
|
sf = 37 + 7 * pos.count<PAWN>(strongSide);
|
2015-11-28 02:57:45 -07:00
|
|
|
}
|
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
return ScaleFactor(sf);
|
2015-11-28 02:57:45 -07:00
|
|
|
}
|
|
|
|
|
2008-12-21 08:26:36 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// 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.
|
2014-04-12 00:32:52 -06:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
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;
|
2017-06-21 15:01:59 -06:00
|
|
|
|
|
|
|
// Probe the pawn hash table
|
|
|
|
pe = Pawns::probe(pos);
|
2018-02-20 09:10:37 -07:00
|
|
|
score += pe->pawn_score(WHITE) - pe->pawn_score(BLACK);
|
2017-06-21 15:01:59 -06:00
|
|
|
|
|
|
|
// 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>();
|
2014-04-12 00:32:52 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
// 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 >();
|
2017-06-21 15:01:59 -06:00
|
|
|
|
|
|
|
score += mobility[WHITE] - mobility[BLACK];
|
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
score += king< WHITE>() - king< BLACK>()
|
|
|
|
+ threats<WHITE>() - threats<BLACK>()
|
|
|
|
+ passed< WHITE>() - passed< BLACK>()
|
|
|
|
+ space< WHITE>() - space< BLACK>();
|
2017-06-21 15:01:59 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
score += initiative(eg_value(score));
|
2017-06-21 15:01:59 -06:00
|
|
|
|
|
|
|
// Interpolate between a middlegame and a (scaled by 'sf') endgame score
|
2018-02-20 09:10:37 -07:00
|
|
|
ScaleFactor sf = scale_factor(eg_value(score));
|
2017-06-21 15:01:59 -06:00
|
|
|
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());
|
2018-02-20 09:10:37 -07:00
|
|
|
Trace::add(PAWN, pe->pawn_score(WHITE), pe->pawn_score(BLACK));
|
2017-06-21 15:01:59 -06:00
|
|
|
Trace::add(MOBILITY, mobility[WHITE], mobility[BLACK]);
|
|
|
|
Trace::add(TOTAL, score);
|
|
|
|
}
|
|
|
|
|
2018-02-20 17:07:35 -07:00
|
|
|
return (pos.side_to_move() == WHITE ? v : -v) // Side to move point of view
|
|
|
|
+ Eval::Tempo;
|
2015-08-25 09:12:51 -06:00
|
|
|
}
|
2015-02-13 03:54:46 -07:00
|
|
|
|
2017-06-21 15:01:59 -06:00
|
|
|
} // namespace
|
|
|
|
|
2015-02-13 03:54:46 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
/// 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.
|
2015-02-13 03:54:46 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
Value Eval::evaluate(const Position& pos) {
|
2018-02-20 17:07:35 -07:00
|
|
|
return Evaluation<NO_TRACE>(pos).value();
|
2017-06-21 15:01:59 -06:00
|
|
|
}
|
2013-06-01 03:48:38 -06:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
|
2015-08-25 09:12:51 -06:00
|
|
|
/// 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.
|
2014-04-12 00:32:52 -06:00
|
|
|
|
2015-08-25 09:12:51 -06:00
|
|
|
std::string Eval::trace(const Position& pos) {
|
2014-04-12 00:32:52 -06:00
|
|
|
|
2015-08-25 09:12:51 -06:00
|
|
|
std::memset(scores, 0, sizeof(scores));
|
2014-04-12 00:32:52 -06:00
|
|
|
|
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
|
2018-02-08 17:10:27 -07:00
|
|
|
|
2018-02-20 17:07:35 -07:00
|
|
|
Value v = Evaluation<TRACE>(pos).value();
|
2018-02-08 17:10:27 -07:00
|
|
|
|
2018-02-20 09:10:37 -07:00
|
|
|
v = pos.side_to_move() == WHITE ? v : -v; // Trace scores are from white's point of view
|
2014-04-12 00:32:52 -06:00
|
|
|
|
2015-08-25 09:12:51 -06:00
|
|
|
std::stringstream ss;
|
|
|
|
ss << std::showpoint << std::noshowpos << std::fixed << std::setprecision(2)
|
2018-02-20 09:10:37 -07:00
|
|
|
<< " 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";
|
2014-04-12 00:32:52 -06:00
|
|
|
|
2015-08-25 09:12:51 -06:00
|
|
|
return ss.str();
|
|
|
|
}
|