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-07-25 10:11:51 -06:00
|
|
|
QueenSide ^ FileDBB, QueenSide, QueenSide,
|
2018-02-20 09:10:37 -07:00
|
|
|
CenterFiles, CenterFiles,
|
2018-07-25 10:11:51 -06:00
|
|
|
KingSide, KingSide, KingSide ^ FileEBB
|
2018-02-20 09:10:37 -07:00
|
|
|
};
|
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-05-12 23:20:39 -06:00
|
|
|
constexpr int KingAttackWeights[PIECE_TYPE_NB] = { 0, 0, 77, 55, 44, 10 };
|
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] = {
|
2018-10-26 06:17:42 -06:00
|
|
|
{ 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) },
|
2017-02-19 14:56:17 -07:00
|
|
|
{ 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-11-02 15:04:43 -06:00
|
|
|
constexpr Score RookOnFile[] = { S(18, 7), S(44, 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] = {
|
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)
|
2009-11-12 09:42:43 -07:00
|
|
|
};
|
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
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)
|
2016-12-28 15:14:09 -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-07-14 00:08:32 -06:00
|
|
|
S(0, 0), S(5, 18), S(12, 23), S(10, 31), S(57, 62), S(163, 167), S(271, 250)
|
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-07-14 00:08:32 -06:00
|
|
|
S( -1, 7), S( 0, 9), S(-9, -8), S(-30,-14),
|
|
|
|
S(-30,-14), S(-9, -8), S( 0, 9), S( -1, 7)
|
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-07-14 00:08:32 -06:00
|
|
|
constexpr int PassedDanger[RANK_NB] = { 0, 0, 0, 3, 7, 11, 20 };
|
2018-02-20 09:10:37 -07:00
|
|
|
|
|
|
|
// Assorted bonuses and penalties
|
2018-07-14 00:08:32 -06:00
|
|
|
constexpr Score BishopPawns = S( 3, 7);
|
|
|
|
constexpr Score CloseEnemies = S( 6, 0);
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score CorneredBishop = S( 50, 50);
|
2018-08-12 02:02:51 -06:00
|
|
|
constexpr Score Hanging = S( 57, 32);
|
Use single value for KingProtector.
After some recent big tuning session, the values for King Protector were
simplified to only be used on minor pieces. This patch tries to further
simplify by just using a single value, since current S(6,5) and S(5,6)
are close to each other. The value S(6,6) ended up passing, although
S(5,5) was also tried and failed STC.
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14261 W: 3288 L: 3151 D: 7822
http://tests.stockfishchess.org/tests/view/5b4ccdf50ebc5902bdb77f65
LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19606 W: 3396 L: 3273 D: 12937
http://tests.stockfishchess.org/tests/view/5b4ce4280ebc5902bdb7803b
Bench: 5448998
2018-07-16 10:51:43 -06:00
|
|
|
constexpr Score KingProtector = S( 6, 6);
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score KnightOnQueen = S( 21, 11);
|
2018-08-31 07:30:16 -06:00
|
|
|
constexpr Score LongDiagonalBishop = S( 46, 0);
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score MinorBehindPawn = S( 16, 0);
|
2018-07-23 14:06:24 -06:00
|
|
|
constexpr Score Overload = S( 13, 6);
|
2018-07-27 10:23:53 -06:00
|
|
|
constexpr Score PawnlessFlank = S( 19, 84);
|
2018-11-02 15:04:43 -06:00
|
|
|
constexpr Score RookOnPawn = S( 10, 29);
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score SliderOnQueen = S( 42, 21);
|
Combo
Combo of two parameter tweaks and tuned values for Queen and ThreatByKing.
STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 20180 W: 4439 L: 4198 D: 11543
http://tests.stockfishchess.org/tests/view/5bd7b8250ebc595e0ae22e97
LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 86312 W: 14106 L: 13685 D: 58521
http://tests.stockfishchess.org/tests/view/5bd803560ebc595e0ae23213
This combo consists of the following:
Queen Value (tuned values)
Iter: 72056, A: 5000, alpha 0.602000, gamma 0.101000, clipping old, rounding deterministic
param: QueenValueMg, best: 2528.91, start: 2528.00
param: QueenValueEg, best: 2687.12, start: 2698.00
ThreatByKing (tuned values)
Green STC (50.8k games)
http://tests.stockfishchess.org/tests/view/5bd1d5a00ebc595e0ae1cbec
LTC (I stopped this test at 71.2k games. It's likely yellow.)
http://tests.stockfishchess.org/tests/view/5bd263e70ebc595e0ae1d77e
WeakUnopposedPawn (tweak) by xoto (https://github.com/xoto10)
Green STC (102.8k games)
http://tests.stockfishchess.org/tests/view/5bd306bb0ebc595e0ae1e146
Yellow LTC (90.8k games)
http://tests.stockfishchess.org/tests/view/5bd3ea660ebc595e0ae1f16b
aspiTune1 (tweak) by vondele (https://github.com/vondele)
Green STC (125.9k games)
http://tests.stockfishchess.org/tests/view/5bd2ae100ebc595e0ae1dab0
Yellow LTC (107.9k games)
http://tests.stockfishchess.org/tests/view/5bd3eb700ebc595e0ae1f16f
Thank you @31m059 (Mark Tenzer) for helping me! Also, thank you very much
for recognizing my efforts. I genuinely appreciate it.
Bench: 3556672
2018-10-31 10:48:16 -06:00
|
|
|
constexpr Score ThreatByKing = S( 22, 78);
|
2018-07-14 00:08:32 -06:00
|
|
|
constexpr Score ThreatByPawnPush = S( 45, 40);
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score ThreatByRank = S( 16, 3);
|
2018-07-14 00:08:32 -06:00
|
|
|
constexpr Score ThreatBySafePawn = S(173,102);
|
2018-11-02 15:04:43 -06:00
|
|
|
constexpr Score TrappedRook = S( 96, 5);
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Score WeakQueen = S( 50, 10);
|
Combo
Combo of two parameter tweaks and tuned values for Queen and ThreatByKing.
STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 20180 W: 4439 L: 4198 D: 11543
http://tests.stockfishchess.org/tests/view/5bd7b8250ebc595e0ae22e97
LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 86312 W: 14106 L: 13685 D: 58521
http://tests.stockfishchess.org/tests/view/5bd803560ebc595e0ae23213
This combo consists of the following:
Queen Value (tuned values)
Iter: 72056, A: 5000, alpha 0.602000, gamma 0.101000, clipping old, rounding deterministic
param: QueenValueMg, best: 2528.91, start: 2528.00
param: QueenValueEg, best: 2687.12, start: 2698.00
ThreatByKing (tuned values)
Green STC (50.8k games)
http://tests.stockfishchess.org/tests/view/5bd1d5a00ebc595e0ae1cbec
LTC (I stopped this test at 71.2k games. It's likely yellow.)
http://tests.stockfishchess.org/tests/view/5bd263e70ebc595e0ae1d77e
WeakUnopposedPawn (tweak) by xoto (https://github.com/xoto10)
Green STC (102.8k games)
http://tests.stockfishchess.org/tests/view/5bd306bb0ebc595e0ae1e146
Yellow LTC (90.8k games)
http://tests.stockfishchess.org/tests/view/5bd3ea660ebc595e0ae1f16b
aspiTune1 (tweak) by vondele (https://github.com/vondele)
Green STC (125.9k games)
http://tests.stockfishchess.org/tests/view/5bd2ae100ebc595e0ae1dab0
Yellow LTC (107.9k games)
http://tests.stockfishchess.org/tests/view/5bd3eb700ebc595e0ae1f16f
Thank you @31m059 (Mark Tenzer) for helping me! Also, thank you very much
for recognizing my efforts. I genuinely appreciate it.
Bench: 3556672
2018-10-31 10:48:16 -06:00
|
|
|
constexpr Score WeakUnopposedPawn = S( 15, 19);
|
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);
|
|
|
|
|
2018-04-23 13:49:34 -06:00
|
|
|
// Squares occupied by those pawns, by our king or queen, or controlled by enemy pawns
|
2017-01-17 19:40:31 -07:00
|
|
|
// are excluded from the mobility area.
|
2018-04-23 13:49:34 -06:00
|
|
|
mobilityArea[Us] = ~(b | pos.pieces(Us, KING, QUEEN) | 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-05-12 23:20:39 -06:00
|
|
|
kingAttackersCount[Them] = popcount(kingRing[Us] & 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-04-30 23:12:17 -06:00
|
|
|
constexpr Color Them = (Us == WHITE ? BLACK : WHITE);
|
|
|
|
constexpr Direction Down = (Us == WHITE ? SOUTH : NORTH);
|
2018-03-18 16:38:58 -06:00
|
|
|
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;
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2018-04-23 13:49:34 -06:00
|
|
|
int mob = 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
|
|
|
|
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
|
|
|
|
2018-07-14 00:26:57 -06:00
|
|
|
// Knight and Bishop bonus for being right behind a pawn
|
|
|
|
if (shift<Down>(pos.pieces(PAWN)) & s)
|
2013-08-17 03:05:55 -06:00
|
|
|
score += MinorBehindPawn;
|
2014-12-27 02:47:21 -07:00
|
|
|
|
2018-06-24 09:07:38 -06:00
|
|
|
// Penalty if the piece is far from the king
|
Use single value for KingProtector.
After some recent big tuning session, the values for King Protector were
simplified to only be used on minor pieces. This patch tries to further
simplify by just using a single value, since current S(6,5) and S(5,6)
are close to each other. The value S(6,6) ended up passing, although
S(5,5) was also tried and failed STC.
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14261 W: 3288 L: 3151 D: 7822
http://tests.stockfishchess.org/tests/view/5b4ccdf50ebc5902bdb77f65
LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19606 W: 3396 L: 3273 D: 12937
http://tests.stockfishchess.org/tests/view/5b4ce4280ebc5902bdb7803b
Bench: 5448998
2018-07-16 10:51:43 -06:00
|
|
|
score -= KingProtector * distance(s, pos.square<KING>(Us));
|
2018-06-24 09:07:38 -06:00
|
|
|
|
2014-12-27 02:47:21 -07:00
|
|
|
if (Pt == BISHOP)
|
2017-10-01 16:41:06 -06:00
|
|
|
{
|
2018-04-30 23:12:17 -06:00
|
|
|
// 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 * pe->pawns_on_same_color_squares(Us, s)
|
|
|
|
* (1 + popcount(blocked & CenterFiles));
|
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
|
2018-08-31 07:30:16 -06:00
|
|
|
if (more_than_one(attacks_bb<BISHOP>(s, pos.pieces(PAWN)) & Center))
|
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-07-29 17:41:04 -06:00
|
|
|
Bitboard kingFlank, weak, b, b1, b2, safe, unsafeChecks;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2012-03-28 04:44:41 -06:00
|
|
|
// King shelter and enemy pawns storm
|
2018-11-10 20:49:13 -07:00
|
|
|
Score score = pe->king_safety<Us>(pos);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-07-29 17:41:04 -06:00
|
|
|
// Find the squares that opponent attacks in our king flank, and the squares
|
|
|
|
// which are attacked twice in that flank but not defended by our pawns.
|
|
|
|
kingFlank = KingFlank[file_of(ksq)];
|
|
|
|
b1 = attackedBy[Them][ALL_PIECES] & kingFlank & Camp;
|
2018-11-11 14:14:28 -07:00
|
|
|
b2 = b1 & attackedBy2[Them];
|
2018-07-29 17:41:04 -06:00
|
|
|
|
|
|
|
int tropism = popcount(b1) + popcount(b2);
|
|
|
|
|
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-06-23 00:57:05 -06:00
|
|
|
int kingDanger = 0;
|
2018-03-15 22:34:38 -06:00
|
|
|
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];
|
2017-12-10 08:13:28 -07:00
|
|
|
|
|
|
|
kingDanger += kingAttackersCount[Them] * kingAttackersWeight[Them]
|
2018-07-14 00:08:32 -06:00
|
|
|
+ 69 * kingAttacksCount[Them]
|
|
|
|
+ 185 * popcount(kingRing[Us] & weak)
|
2018-09-20 01:12:12 -06:00
|
|
|
+ 150 * popcount(pos.blockers_for_king(Us) | unsafeChecks)
|
2018-07-29 17:41:04 -06:00
|
|
|
+ 4 * tropism
|
2018-07-14 00:08:32 -06:00
|
|
|
- 873 * !pos.count<QUEEN>(Them)
|
|
|
|
- 6 * mg_value(score) / 8
|
2018-11-02 08:24:14 -06:00
|
|
|
+ mg_value(mobility[Them] - mobility[Us])
|
2018-07-29 17:41:04 -06:00
|
|
|
- 30;
|
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)
|
2017-05-17 19:19:47 -06:00
|
|
|
score -= make_score(kingDanger * kingDanger / 4096, kingDanger / 16);
|
2010-08-25 13:16:27 -06:00
|
|
|
}
|
2011-02-26 06:09:58 -07:00
|
|
|
|
2018-02-27 11:10:40 -07:00
|
|
|
// Penalty when our king is on a pawnless flank
|
2018-07-29 17:41:04 -06:00
|
|
|
if (!(pos.pieces(PAWN) & kingFlank))
|
2018-02-27 11:10:40 -07:00
|
|
|
score -= PawnlessFlank;
|
2016-08-27 16:16:28 -06:00
|
|
|
|
2018-07-29 17:41:04 -06:00
|
|
|
// King tropism bonus, to anticipate slow motion attacks on our king
|
|
|
|
score -= CloseEnemies * tropism;
|
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
|
|
|
|
Small reformat in evaluate threats (non functional)
When evaluating threat by safe pawn and pawn push the same expression is used.
STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19444 W: 4540 L: 4309 D: 10595
http://tests.stockfishchess.org/tests/view/5b5a6e150ebc5902bdb8c5c0
Closes https://github.com/official-stockfish/Stockfish/pull/1709
No functional change.
--------------------
Comments by Stéphane Nicolet:
I don't measure any speed-up on my system, with two parallel benches at depth 22:
Total time (ms) : 74989
Nodes searched : 144830258
Nodes/second : 1931353
master
Total time (ms) : 75341
Nodes searched : 144830258
Nodes/second : 1922329
testedpatch
And anyway, like Stefan Geschwentner, I don't think that a 0.3% speed-up would
be enough to pass a [0..5] LTC test -- as a first approximation, we have this
rule of thumb that 1% speed-up gives about 1 Elo point.
However, considering the facts that the reformatting by itself is interesting,
that this is your first green test and that you played by the rules by running
the SPRT[0..5] test before opening the pull request, I will commit the change.
I will only take the liberty to change the occurrences of safe in lines 590 and
591 to b, to make the code more similar to lines 584 and 585.
So approved, and congrats :-)
2018-07-27 02:24:49 -06:00
|
|
|
Bitboard b, weak, defended, nonPawnEnemies, stronglyProtected, safe;
|
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
|
|
|
|
Small reformat in evaluate threats (non functional)
When evaluating threat by safe pawn and pawn push the same expression is used.
STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19444 W: 4540 L: 4309 D: 10595
http://tests.stockfishchess.org/tests/view/5b5a6e150ebc5902bdb8c5c0
Closes https://github.com/official-stockfish/Stockfish/pull/1709
No functional change.
--------------------
Comments by Stéphane Nicolet:
I don't measure any speed-up on my system, with two parallel benches at depth 22:
Total time (ms) : 74989
Nodes searched : 144830258
Nodes/second : 1931353
master
Total time (ms) : 75341
Nodes searched : 144830258
Nodes/second : 1922329
testedpatch
And anyway, like Stefan Geschwentner, I don't think that a 0.3% speed-up would
be enough to pass a [0..5] LTC test -- as a first approximation, we have this
rule of thumb that 1% speed-up gives about 1 Elo point.
However, considering the facts that the reformatting by itself is interesting,
that this is your first green test and that you played by the rules by running
the SPRT[0..5] test before opening the pull request, I will commit the change.
I will only take the liberty to change the occurrences of safe in lines 590 and
591 to b, to make the code more similar to lines 584 and 585.
So approved, and congrats :-)
2018-07-27 02:24:49 -06:00
|
|
|
// Safe or protected squares
|
|
|
|
safe = ~attackedBy[Them][ALL_PIECES] | attackedBy[Us][ALL_PIECES];
|
|
|
|
|
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
|
|
|
|
2018-07-22 16:02:37 -06:00
|
|
|
b = 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
|
|
|
|
Simplify ThreatByKing to be a single Score.
In the current master, ThreatByKing is an array of two Scores, one for
when we have a single attack and one for when we have many. The latter
case is very rarely called during bench and was recently given a strange
negative value during a tuning run, as pointed out by @candirufish on
commit efd4ca2. Here, we simplify away this second case entirely, and
increase the remaining ThreatByKing to compensate.
Although I derived the parameter tweak independently, with the goal of
preserving the same average bonus, I later noticed that a very similar
Score had already been derived by an ongoing SPSA tuning session.
I therefore recognize @candirufish for first discovering these values.
I would also like to thank @Rocky640 for valuable feedback that pointed
me in the direction of ThreatByKing.
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7677 W: 1772 L: 1623 D: 4282
http://tests.stockfishchess.org/tests/view/5b3db0320ebc5902b9ffe97a
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 108031 W: 18329 L: 18350 D: 71352
http://tests.stockfishchess.org/tests/view/5b3dbf4b0ebc5902b9ffe9db
Closes https://github.com/official-stockfish/Stockfish/pull/1666
Bench: 4678861
2018-07-04 20:18:52 -06:00
|
|
|
if (weak & attackedBy[Us][KING])
|
|
|
|
score += ThreatByKing;
|
2018-04-18 11:44:22 -06:00
|
|
|
|
|
|
|
score += Hanging * popcount(weak & ~attackedBy[Them][ALL_PIECES]);
|
|
|
|
|
2018-07-22 16:02:37 -06:00
|
|
|
b = weak & nonPawnEnemies & attackedBy[Them][ALL_PIECES];
|
2018-04-18 11:44:22 -06:00
|
|
|
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);
|
|
|
|
|
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
|
|
|
|
2018-07-25 10:31:02 -06:00
|
|
|
// Keep only the squares which are relatively safe
|
Small reformat in evaluate threats (non functional)
When evaluating threat by safe pawn and pawn push the same expression is used.
STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19444 W: 4540 L: 4309 D: 10595
http://tests.stockfishchess.org/tests/view/5b5a6e150ebc5902bdb8c5c0
Closes https://github.com/official-stockfish/Stockfish/pull/1709
No functional change.
--------------------
Comments by Stéphane Nicolet:
I don't measure any speed-up on my system, with two parallel benches at depth 22:
Total time (ms) : 74989
Nodes searched : 144830258
Nodes/second : 1931353
master
Total time (ms) : 75341
Nodes searched : 144830258
Nodes/second : 1922329
testedpatch
And anyway, like Stefan Geschwentner, I don't think that a 0.3% speed-up would
be enough to pass a [0..5] LTC test -- as a first approximation, we have this
rule of thumb that 1% speed-up gives about 1 Elo point.
However, considering the facts that the reformatting by itself is interesting,
that this is your first green test and that you played by the rules by running
the SPRT[0..5] test before opening the pull request, I will commit the change.
I will only take the liberty to change the occurrences of safe in lines 590 and
591 to b, to make the code more similar to lines 584 and 585.
So approved, and congrats :-)
2018-07-27 02:24:49 -06:00
|
|
|
b &= ~attackedBy[Them][PAWN] & safe;
|
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-07-26 01:34:14 -06:00
|
|
|
b = pawn_attacks_bb<Us>(b) & pos.pieces(Them);
|
2016-04-20 22:23:40 -06:00
|
|
|
score += ThreatByPawnPush * popcount(b);
|
2015-02-02 20:16:50 -07:00
|
|
|
|
Small reformat in evaluate threats (non functional)
When evaluating threat by safe pawn and pawn push the same expression is used.
STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19444 W: 4540 L: 4309 D: 10595
http://tests.stockfishchess.org/tests/view/5b5a6e150ebc5902bdb8c5c0
Closes https://github.com/official-stockfish/Stockfish/pull/1709
No functional change.
--------------------
Comments by Stéphane Nicolet:
I don't measure any speed-up on my system, with two parallel benches at depth 22:
Total time (ms) : 74989
Nodes searched : 144830258
Nodes/second : 1931353
master
Total time (ms) : 75341
Nodes searched : 144830258
Nodes/second : 1922329
testedpatch
And anyway, like Stefan Geschwentner, I don't think that a 0.3% speed-up would
be enough to pass a [0..5] LTC test -- as a first approximation, we have this
rule of thumb that 1% speed-up gives about 1 Elo point.
However, considering the facts that the reformatting by itself is interesting,
that this is your first green test and that you played by the rules by running
the SPRT[0..5] test before opening the pull request, I will commit the change.
I will only take the liberty to change the occurrences of safe in lines 590 and
591 to b, to make the code more similar to lines 584 and 585.
So approved, and congrats :-)
2018-07-27 02:24:49 -06:00
|
|
|
// Our safe or protected pawns
|
|
|
|
b = pos.pieces(Us, PAWN) & safe;
|
|
|
|
|
|
|
|
b = pawn_attacks_bb<Us>(b) & nonPawnEnemies;
|
|
|
|
score += ThreatBySafePawn * popcount(b);
|
|
|
|
|
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);
|
Small reformat in evaluate threats (non functional)
When evaluating threat by safe pawn and pawn push the same expression is used.
STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19444 W: 4540 L: 4309 D: 10595
http://tests.stockfishchess.org/tests/view/5b5a6e150ebc5902bdb8c5c0
Closes https://github.com/official-stockfish/Stockfish/pull/1709
No functional change.
--------------------
Comments by Stéphane Nicolet:
I don't measure any speed-up on my system, with two parallel benches at depth 22:
Total time (ms) : 74989
Nodes searched : 144830258
Nodes/second : 1931353
master
Total time (ms) : 75341
Nodes searched : 144830258
Nodes/second : 1922329
testedpatch
And anyway, like Stefan Geschwentner, I don't think that a 0.3% speed-up would
be enough to pass a [0..5] LTC test -- as a first approximation, we have this
rule of thumb that 1% speed-up gives about 1 Elo point.
However, considering the facts that the reformatting by itself is interesting,
that this is your first green test and that you played by the rules by running
the SPRT[0..5] test before opening the pull request, I will commit the change.
I will only take the liberty to change the occurrences of safe in lines 590 and
591 to b, to make the code more similar to lines 584 and 585.
So approved, and congrats :-)
2018-07-27 02:24:49 -06:00
|
|
|
safe = mobilityArea[Us] & ~stronglyProtected;
|
2018-03-08 18:04:33 -07:00
|
|
|
|
|
|
|
b = attackedBy[Us][KNIGHT] & pos.attacks_from<KNIGHT>(s);
|
|
|
|
|
Small reformat in evaluate threats (non functional)
When evaluating threat by safe pawn and pawn push the same expression is used.
STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19444 W: 4540 L: 4309 D: 10595
http://tests.stockfishchess.org/tests/view/5b5a6e150ebc5902bdb8c5c0
Closes https://github.com/official-stockfish/Stockfish/pull/1709
No functional change.
--------------------
Comments by Stéphane Nicolet:
I don't measure any speed-up on my system, with two parallel benches at depth 22:
Total time (ms) : 74989
Nodes searched : 144830258
Nodes/second : 1931353
master
Total time (ms) : 75341
Nodes searched : 144830258
Nodes/second : 1922329
testedpatch
And anyway, like Stefan Geschwentner, I don't think that a 0.3% speed-up would
be enough to pass a [0..5] LTC test -- as a first approximation, we have this
rule of thumb that 1% speed-up gives about 1 Elo point.
However, considering the facts that the reformatting by itself is interesting,
that this is your first green test and that you played by the rules by running
the SPRT[0..5] test before opening the pull request, I will commit the change.
I will only take the liberty to change the occurrences of safe in lines 590 and
591 to b, to make the code more similar to lines 584 and 585.
So approved, and congrats :-)
2018-07-27 02:24:49 -06:00
|
|
|
score += KnightOnQueen * popcount(b & safe);
|
2018-03-08 18:04:33 -07:00
|
|
|
|
|
|
|
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
|
|
|
|
Small reformat in evaluate threats (non functional)
When evaluating threat by safe pawn and pawn push the same expression is used.
STC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 19444 W: 4540 L: 4309 D: 10595
http://tests.stockfishchess.org/tests/view/5b5a6e150ebc5902bdb8c5c0
Closes https://github.com/official-stockfish/Stockfish/pull/1709
No functional change.
--------------------
Comments by Stéphane Nicolet:
I don't measure any speed-up on my system, with two parallel benches at depth 22:
Total time (ms) : 74989
Nodes searched : 144830258
Nodes/second : 1931353
master
Total time (ms) : 75341
Nodes searched : 144830258
Nodes/second : 1922329
testedpatch
And anyway, like Stefan Geschwentner, I don't think that a 0.3% speed-up would
be enough to pass a [0..5] LTC test -- as a first approximation, we have this
rule of thumb that 1% speed-up gives about 1 Elo point.
However, considering the facts that the reformatting by itself is interesting,
that this is your first green test and that you played by the rules by running
the SPRT[0..5] test before opening the pull request, I will commit the change.
I will only take the liberty to change the occurrences of safe in lines 590 and
591 to b, to make the code more similar to lines 584 and 585.
So approved, and congrats :-)
2018-07-27 02:24:49 -06:00
|
|
|
score += SliderOnQueen * popcount(b & safe & attackedBy2[Us]);
|
2018-03-07 14:12:29 -07:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
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
|
|
|
}
|
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
|
2018-04-28 22:48:18 -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-08-08 06:27:28 -06:00
|
|
|
if (pos.non_pawn_material() < SpaceThreshold)
|
|
|
|
return SCORE_ZERO;
|
|
|
|
|
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-04-28 22:48:18 -06:00
|
|
|
// Find the available squares for our pieces inside the area defined by SpaceMask
|
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));
|
|
|
|
|
2018-09-03 04:46:05 -06:00
|
|
|
bool pawnsOnBothFlanks = (pos.pieces(PAWN) & QueenSide)
|
2018-09-01 02:39:29 -06:00
|
|
|
&& (pos.pieces(PAWN) & KingSide);
|
|
|
|
|
2015-10-15 22:27:52 -06:00
|
|
|
// Compute the initiative bonus for the attacking side
|
2018-06-21 17:28:02 -06:00
|
|
|
int complexity = 8 * pe->pawn_asymmetry()
|
2018-02-20 09:10:37 -07:00
|
|
|
+ 12 * pos.count<PAWN>()
|
2018-06-21 17:28:02 -06:00
|
|
|
+ 12 * outflanking
|
2018-09-01 02:39:29 -06:00
|
|
|
+ 16 * pawnsOnBothFlanks
|
2018-03-12 03:09:02 -06:00
|
|
|
+ 48 * !pos.non_pawn_material()
|
2018-09-01 02:39:29 -06:00
|
|
|
-118 ;
|
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
|
|
|
|
2018-04-28 23:23:32 -06:00
|
|
|
// If scale is not already specific, scale down the endgame via general heuristics
|
|
|
|
if (sf == SCALE_FACTOR_NORMAL)
|
2015-11-28 02:57:45 -07:00
|
|
|
{
|
Slight simplification in scale factor computation
[STC](http://tests.stockfishchess.org/tests/view/5b2614000ebc5902b8d17193)
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 17733 W: 3996 L: 3866 D: 9871
[LTC](http://tests.stockfishchess.org/tests/view/5b264d0f0ebc5902b8d17206)
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 55524 W: 9535 L: 9471 D: 36518
Use pawn count scaling also for opposite bishops endings with additional material, with a slope of 2 instead of 7. This simplifies slightly the code.
This PR is a functionally equivalent refactoring of the version which was submitted.
Four versions tried, 2 passed both STC and LTC. I picked the one which seemed more promising at LTC.
Slope 4 passed STC (-0.54 Elo), LTC not attempted
Slope 3 passed STC (+2.51 Elo), LTC (-0.44 Elo)
Slope 2 passed STC (+2.09 Elo), LTC (+0.04 Elo)
Slope 1 passed STC (+0.90 Elo), failed LTC (-3.40 Elo)
Bench: 4761613
2018-06-19 21:24:24 -06:00
|
|
|
if ( pos.opposite_bishops()
|
|
|
|
&& pos.non_pawn_material(WHITE) == BishopValueMg
|
|
|
|
&& pos.non_pawn_material(BLACK) == BishopValueMg)
|
2018-09-10 04:02:43 -06:00
|
|
|
sf = 8 + 4 * pe->pawn_asymmetry();
|
2018-04-28 23:23:32 -06:00
|
|
|
else
|
2018-06-21 02:20:31 -06:00
|
|
|
sf = std::min(40 + (pos.opposite_bishops() ? 2 : 7) * pos.count<PAWN>(strongSide), sf);
|
2018-09-10 04:02:43 -06:00
|
|
|
|
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();
|
|
|
|
}
|