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-11-19 03:18:21 -07:00
|
|
|
Copyright (C) 2015-2019 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/>.
|
|
|
|
*/
|
|
|
|
|
2019-03-31 04:02:19 -06:00
|
|
|
#include <algorithm>
|
2008-08-31 23:59:13 -06:00
|
|
|
#include <cassert>
|
2016-09-17 00:19:06 -06:00
|
|
|
#include <cstddef> // For offsetof()
|
|
|
|
#include <cstring> // For std::memset, std::memcmp
|
2013-02-19 00:54:16 -07:00
|
|
|
#include <iomanip>
|
2010-07-23 02:38:19 -06:00
|
|
|
#include <sstream>
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2016-04-08 11:52:15 -06:00
|
|
|
#include "bitboard.h"
|
2014-12-08 00:23:09 -07:00
|
|
|
#include "misc.h"
|
2008-08-31 23:59:13 -06:00
|
|
|
#include "movegen.h"
|
|
|
|
#include "position.h"
|
2011-04-24 02:20:03 -06:00
|
|
|
#include "thread.h"
|
2009-08-09 08:53:51 -06:00
|
|
|
#include "tt.h"
|
2014-10-26 00:16:16 -06:00
|
|
|
#include "uci.h"
|
2016-07-16 00:10:45 -06:00
|
|
|
#include "syzygy/tbprobe.h"
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2009-05-10 10:58:53 -06:00
|
|
|
using std::string;
|
|
|
|
|
2013-06-09 15:24:36 -06:00
|
|
|
namespace Zobrist {
|
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
Key psq[PIECE_NB][SQUARE_NB];
|
2013-06-09 15:24:36 -06:00
|
|
|
Key enpassant[FILE_NB];
|
2014-03-08 07:08:55 -07:00
|
|
|
Key castling[CASTLING_RIGHT_NB];
|
2016-11-21 08:17:47 -07:00
|
|
|
Key side, noPawns;
|
2013-06-09 15:24:36 -06:00
|
|
|
}
|
|
|
|
|
2012-09-15 02:50:23 -06:00
|
|
|
namespace {
|
|
|
|
|
2014-11-01 14:35:10 -06:00
|
|
|
const string PieceToChar(" PNBRQK pnbrqk");
|
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr Piece Pieces[] = { W_PAWN, W_KNIGHT, W_BISHOP, W_ROOK, W_QUEEN, W_KING,
|
|
|
|
B_PAWN, B_KNIGHT, B_BISHOP, B_ROOK, B_QUEEN, B_KING };
|
2017-05-07 02:26:09 -06:00
|
|
|
|
2016-11-07 15:34:11 -07:00
|
|
|
// min_attacker() is a helper function used by see_ge() to locate the least
|
2013-06-09 04:24:43 -06:00
|
|
|
// valuable attacker for the side to move, remove the attacker we just found
|
2013-07-20 03:44:55 -06:00
|
|
|
// from the bitboards and scan for new X-ray attacks behind it.
|
2012-09-01 03:45:14 -06:00
|
|
|
|
2019-06-09 07:07:36 -06:00
|
|
|
template<PieceType Pt>
|
2018-02-23 14:02:10 -07:00
|
|
|
PieceType min_attacker(const Bitboard* byTypeBB, Square to, Bitboard stmAttackers,
|
2013-07-20 03:44:55 -06:00
|
|
|
Bitboard& occupied, Bitboard& attackers) {
|
2012-09-01 03:45:14 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
Bitboard b = stmAttackers & byTypeBB[Pt];
|
2013-07-20 11:11:03 -06:00
|
|
|
if (!b)
|
2019-06-09 07:07:36 -06:00
|
|
|
return min_attacker<PieceType(Pt + 1)>(byTypeBB, to, stmAttackers, occupied, attackers);
|
2013-07-20 03:44:55 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
occupied ^= lsb(b); // Remove the attacker from occupied
|
2012-09-01 03:45:14 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
// Add any X-ray attack behind the just removed piece. For instance with
|
|
|
|
// rooks in a8 and a7 attacking a1, after removing a7 we add rook in a8.
|
|
|
|
// Note that new added attackers can be of any color.
|
2013-07-20 11:11:03 -06:00
|
|
|
if (Pt == PAWN || Pt == BISHOP || Pt == QUEEN)
|
2018-02-23 14:02:10 -07:00
|
|
|
attackers |= attacks_bb<BISHOP>(to, occupied) & (byTypeBB[BISHOP] | byTypeBB[QUEEN]);
|
2012-09-01 03:45:14 -06:00
|
|
|
|
2013-07-20 11:11:03 -06:00
|
|
|
if (Pt == ROOK || Pt == QUEEN)
|
2018-02-23 14:02:10 -07:00
|
|
|
attackers |= attacks_bb<ROOK>(to, occupied) & (byTypeBB[ROOK] | byTypeBB[QUEEN]);
|
2012-09-01 03:45:14 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
// X-ray may add already processed pieces because byTypeBB[] is constant: in
|
|
|
|
// the rook example, now attackers contains _again_ rook in a7, so remove it.
|
|
|
|
attackers &= occupied;
|
2019-06-09 07:07:36 -06:00
|
|
|
return Pt;
|
2012-09-01 03:45:14 -06:00
|
|
|
}
|
|
|
|
|
Retire FORCE_INLINE
No speed regression on my machine (i7-3770k, gcc 4.9.1, linux 3.16):
stat test master diff
mean 2,482,415 2,474,987 7,906
stdev 4,603 5,644 2,497
speedup 0.32%
P(speedup>0) 100.0%
Fishtest 9+0.03:
ELO: 0.26 +-1.8 (95%) LOS: 61.2%
Total: 60000 W: 12437 L: 12392 D: 35171
No functional change.
Resolves #334
2015-04-15 14:21:45 -06:00
|
|
|
template<>
|
2015-09-07 13:17:39 -06:00
|
|
|
PieceType min_attacker<KING>(const Bitboard*, Square, Bitboard, Bitboard&, Bitboard&) {
|
2013-12-02 11:04:09 -07:00
|
|
|
return KING; // No need to update bitboards: it is the last cycle
|
2012-09-01 03:45:14 -06:00
|
|
|
}
|
|
|
|
|
2012-09-15 02:50:23 -06:00
|
|
|
} // namespace
|
|
|
|
|
2012-09-01 03:45:14 -06:00
|
|
|
|
2014-11-01 11:50:27 -06:00
|
|
|
/// operator<<(Position) returns an ASCII representation of the position
|
|
|
|
|
2016-11-27 01:11:56 -07:00
|
|
|
std::ostream& operator<<(std::ostream& os, const Position& pos) {
|
2014-11-01 11:50:27 -06:00
|
|
|
|
|
|
|
os << "\n +---+---+---+---+---+---+---+---+\n";
|
|
|
|
|
|
|
|
for (Rank r = RANK_8; r >= RANK_1; --r)
|
|
|
|
{
|
|
|
|
for (File f = FILE_A; f <= FILE_H; ++f)
|
|
|
|
os << " | " << PieceToChar[pos.piece_on(make_square(f, r))];
|
|
|
|
|
|
|
|
os << " |\n +---+---+---+---+---+---+---+---+\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
os << "\nFen: " << pos.fen() << "\nKey: " << std::hex << std::uppercase
|
2016-07-16 00:10:45 -06:00
|
|
|
<< std::setfill('0') << std::setw(16) << pos.key()
|
|
|
|
<< std::setfill(' ') << std::dec << "\nCheckers: ";
|
2014-11-01 11:50:27 -06:00
|
|
|
|
|
|
|
for (Bitboard b = pos.checkers(); b; )
|
2014-12-14 01:31:13 -07:00
|
|
|
os << UCI::square(pop_lsb(&b)) << " ";
|
2014-11-01 11:50:27 -06:00
|
|
|
|
2016-07-16 00:10:45 -06:00
|
|
|
if ( int(Tablebases::MaxCardinality) >= popcount(pos.pieces())
|
|
|
|
&& !pos.can_castle(ANY_CASTLING))
|
|
|
|
{
|
2016-11-27 01:11:56 -07:00
|
|
|
StateInfo st;
|
|
|
|
Position p;
|
|
|
|
p.set(pos.fen(), pos.is_chess960(), &st, pos.this_thread());
|
2016-07-16 00:10:45 -06:00
|
|
|
Tablebases::ProbeState s1, s2;
|
2016-11-27 01:11:56 -07:00
|
|
|
Tablebases::WDLScore wdl = Tablebases::probe_wdl(p, &s1);
|
|
|
|
int dtz = Tablebases::probe_dtz(p, &s2);
|
2016-07-16 00:10:45 -06:00
|
|
|
os << "\nTablebases WDL: " << std::setw(4) << wdl << " (" << s1 << ")"
|
|
|
|
<< "\nTablebases DTZ: " << std::setw(4) << dtz << " (" << s2 << ")";
|
|
|
|
}
|
|
|
|
|
2014-11-01 11:50:27 -06:00
|
|
|
return os;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-05-21 01:37:16 -06:00
|
|
|
// Marcel van Kervinck's cuckoo algorithm for fast detection of "upcoming repetition"
|
|
|
|
// situations. Description of the algorithm in the following paper:
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
// https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
|
|
|
|
|
|
|
|
// First and second hash functions for indexing the cuckoo tables
|
2018-05-21 01:37:16 -06:00
|
|
|
inline int H1(Key h) { return h & 0x1fff; }
|
|
|
|
inline int H2(Key h) { return (h >> 16) & 0x1fff; }
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
|
|
|
|
// Cuckoo tables with Zobrist hashes of valid reversible moves, and the moves themselves
|
|
|
|
Key cuckoo[8192];
|
|
|
|
Move cuckooMove[8192];
|
|
|
|
|
|
|
|
|
2013-06-09 05:43:30 -06:00
|
|
|
/// Position::init() initializes at startup the various arrays used to compute
|
2015-05-01 18:36:39 -06:00
|
|
|
/// hash keys.
|
2013-06-09 05:43:30 -06:00
|
|
|
|
|
|
|
void Position::init() {
|
|
|
|
|
Simpler PRNG and faster magics search
This patch replaces RKISS by a simpler and faster PRNG, xorshift64* proposed
by S. Vigna (2014). It is extremely simple, has a large enough period for
Stockfish's needs (2^64), requires no warming-up (allowing such code to be
removed), and offers slightly better randomness than MT19937.
Paper: http://xorshift.di.unimi.it/
Reference source code (public domain):
http://xorshift.di.unimi.it/xorshift64star.c
The patch also simplifies how init_magics() searches for magics:
- Old logic: seed the PRNG always with the same seed,
then use optimized bit rotations to tailor the RNG sequence per rank.
- New logic: seed the PRNG with an optimized seed per rank.
This has two advantages:
1. Less code and less computation to perform during magics search (not ROTL).
2. More choices for random sequence tuning. The old logic only let us choose
from 4096 bit rotation pairs. With the new one, we can look for the best seeds
among 2^64 values. Indeed, the set of seeds[][] provided in the patch reduces
the effort needed to find the magics:
64-bit SF:
Old logic -> 5,783,789 rand64() calls needed to find the magics
New logic -> 4,420,086 calls
32-bit SF:
Old logic -> 2,175,518 calls
New logic -> 1,895,955 calls
In the 64-bit case, init_magics() take 25 ms less to complete (Intel Core i5).
Finally, when playing with strength handicap, non-determinism is achieved
by setting the seed of the static RNG only once. Afterwards, there is no need
to skip output values.
The bench only changes because the Zobrist keys are now different (since they
are random numbers straight out of the PRNG).
The RNG seed has been carefully chosen so that the
resulting Zobrist keys are particularly well-behaved:
1. All triplets of XORed keys are unique, implying that it
would take at least 7 keys to find a 64-bit collision
(test suggested by ceebo)
2. All pairs of XORed keys are unique modulo 2^32
3. The cardinality of { (key1 ^ key2) >> 48 } is as close
as possible to the maximum (65536)
Point 2 aims at ensuring a good distribution among the bits
that determine an TT entry's cluster, likewise point 3
among the bits that form the TT entry's key16 inside a
cluster.
Details:
Bitset card(key1^key2)
------ ---------------
RKISS
key16 64894 = 99.020% of theoretical maximum
low18 180117 = 99.293%
low32 305362 = 99.997%
Xorshift64*, old seed
key16 64918 = 99.057%
low18 179994 = 99.225%
low32 305350 = 99.993%
Xorshift64*, new seed
key16 65027 = 99.223%
low18 181118 = 99.845%
low32 305371 = 100.000%
Bench: 9324905
Resolves #148
2014-12-07 17:10:57 -07:00
|
|
|
PRNG rng(1070372);
|
2013-06-09 05:43:30 -06:00
|
|
|
|
2016-09-04 07:29:11 -06:00
|
|
|
for (Piece pc : Pieces)
|
|
|
|
for (Square s = SQ_A1; s <= SQ_H8; ++s)
|
|
|
|
Zobrist::psq[pc][s] = rng.rand<Key>();
|
2013-06-09 05:43:30 -06:00
|
|
|
|
2013-09-15 01:02:09 -06:00
|
|
|
for (File f = FILE_A; f <= FILE_H; ++f)
|
Simpler PRNG and faster magics search
This patch replaces RKISS by a simpler and faster PRNG, xorshift64* proposed
by S. Vigna (2014). It is extremely simple, has a large enough period for
Stockfish's needs (2^64), requires no warming-up (allowing such code to be
removed), and offers slightly better randomness than MT19937.
Paper: http://xorshift.di.unimi.it/
Reference source code (public domain):
http://xorshift.di.unimi.it/xorshift64star.c
The patch also simplifies how init_magics() searches for magics:
- Old logic: seed the PRNG always with the same seed,
then use optimized bit rotations to tailor the RNG sequence per rank.
- New logic: seed the PRNG with an optimized seed per rank.
This has two advantages:
1. Less code and less computation to perform during magics search (not ROTL).
2. More choices for random sequence tuning. The old logic only let us choose
from 4096 bit rotation pairs. With the new one, we can look for the best seeds
among 2^64 values. Indeed, the set of seeds[][] provided in the patch reduces
the effort needed to find the magics:
64-bit SF:
Old logic -> 5,783,789 rand64() calls needed to find the magics
New logic -> 4,420,086 calls
32-bit SF:
Old logic -> 2,175,518 calls
New logic -> 1,895,955 calls
In the 64-bit case, init_magics() take 25 ms less to complete (Intel Core i5).
Finally, when playing with strength handicap, non-determinism is achieved
by setting the seed of the static RNG only once. Afterwards, there is no need
to skip output values.
The bench only changes because the Zobrist keys are now different (since they
are random numbers straight out of the PRNG).
The RNG seed has been carefully chosen so that the
resulting Zobrist keys are particularly well-behaved:
1. All triplets of XORed keys are unique, implying that it
would take at least 7 keys to find a 64-bit collision
(test suggested by ceebo)
2. All pairs of XORed keys are unique modulo 2^32
3. The cardinality of { (key1 ^ key2) >> 48 } is as close
as possible to the maximum (65536)
Point 2 aims at ensuring a good distribution among the bits
that determine an TT entry's cluster, likewise point 3
among the bits that form the TT entry's key16 inside a
cluster.
Details:
Bitset card(key1^key2)
------ ---------------
RKISS
key16 64894 = 99.020% of theoretical maximum
low18 180117 = 99.293%
low32 305362 = 99.997%
Xorshift64*, old seed
key16 64918 = 99.057%
low18 179994 = 99.225%
low32 305350 = 99.993%
Xorshift64*, new seed
key16 65027 = 99.223%
low18 181118 = 99.845%
low32 305371 = 100.000%
Bench: 9324905
Resolves #148
2014-12-07 17:10:57 -07:00
|
|
|
Zobrist::enpassant[f] = rng.rand<Key>();
|
2013-06-09 05:43:30 -06:00
|
|
|
|
2014-12-07 16:53:33 -07:00
|
|
|
for (int cr = NO_CASTLING; cr <= ANY_CASTLING; ++cr)
|
2013-06-09 05:43:30 -06:00
|
|
|
{
|
2015-04-10 00:57:35 -06:00
|
|
|
Zobrist::castling[cr] = 0;
|
2014-12-07 16:53:33 -07:00
|
|
|
Bitboard b = cr;
|
2013-06-09 05:43:30 -06:00
|
|
|
while (b)
|
|
|
|
{
|
2013-12-01 02:25:10 -07:00
|
|
|
Key k = Zobrist::castling[1ULL << pop_lsb(&b)];
|
Simpler PRNG and faster magics search
This patch replaces RKISS by a simpler and faster PRNG, xorshift64* proposed
by S. Vigna (2014). It is extremely simple, has a large enough period for
Stockfish's needs (2^64), requires no warming-up (allowing such code to be
removed), and offers slightly better randomness than MT19937.
Paper: http://xorshift.di.unimi.it/
Reference source code (public domain):
http://xorshift.di.unimi.it/xorshift64star.c
The patch also simplifies how init_magics() searches for magics:
- Old logic: seed the PRNG always with the same seed,
then use optimized bit rotations to tailor the RNG sequence per rank.
- New logic: seed the PRNG with an optimized seed per rank.
This has two advantages:
1. Less code and less computation to perform during magics search (not ROTL).
2. More choices for random sequence tuning. The old logic only let us choose
from 4096 bit rotation pairs. With the new one, we can look for the best seeds
among 2^64 values. Indeed, the set of seeds[][] provided in the patch reduces
the effort needed to find the magics:
64-bit SF:
Old logic -> 5,783,789 rand64() calls needed to find the magics
New logic -> 4,420,086 calls
32-bit SF:
Old logic -> 2,175,518 calls
New logic -> 1,895,955 calls
In the 64-bit case, init_magics() take 25 ms less to complete (Intel Core i5).
Finally, when playing with strength handicap, non-determinism is achieved
by setting the seed of the static RNG only once. Afterwards, there is no need
to skip output values.
The bench only changes because the Zobrist keys are now different (since they
are random numbers straight out of the PRNG).
The RNG seed has been carefully chosen so that the
resulting Zobrist keys are particularly well-behaved:
1. All triplets of XORed keys are unique, implying that it
would take at least 7 keys to find a 64-bit collision
(test suggested by ceebo)
2. All pairs of XORed keys are unique modulo 2^32
3. The cardinality of { (key1 ^ key2) >> 48 } is as close
as possible to the maximum (65536)
Point 2 aims at ensuring a good distribution among the bits
that determine an TT entry's cluster, likewise point 3
among the bits that form the TT entry's key16 inside a
cluster.
Details:
Bitset card(key1^key2)
------ ---------------
RKISS
key16 64894 = 99.020% of theoretical maximum
low18 180117 = 99.293%
low32 305362 = 99.997%
Xorshift64*, old seed
key16 64918 = 99.057%
low18 179994 = 99.225%
low32 305350 = 99.993%
Xorshift64*, new seed
key16 65027 = 99.223%
low18 181118 = 99.845%
low32 305371 = 100.000%
Bench: 9324905
Resolves #148
2014-12-07 17:10:57 -07:00
|
|
|
Zobrist::castling[cr] ^= k ? k : rng.rand<Key>();
|
2013-06-09 05:43:30 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Simpler PRNG and faster magics search
This patch replaces RKISS by a simpler and faster PRNG, xorshift64* proposed
by S. Vigna (2014). It is extremely simple, has a large enough period for
Stockfish's needs (2^64), requires no warming-up (allowing such code to be
removed), and offers slightly better randomness than MT19937.
Paper: http://xorshift.di.unimi.it/
Reference source code (public domain):
http://xorshift.di.unimi.it/xorshift64star.c
The patch also simplifies how init_magics() searches for magics:
- Old logic: seed the PRNG always with the same seed,
then use optimized bit rotations to tailor the RNG sequence per rank.
- New logic: seed the PRNG with an optimized seed per rank.
This has two advantages:
1. Less code and less computation to perform during magics search (not ROTL).
2. More choices for random sequence tuning. The old logic only let us choose
from 4096 bit rotation pairs. With the new one, we can look for the best seeds
among 2^64 values. Indeed, the set of seeds[][] provided in the patch reduces
the effort needed to find the magics:
64-bit SF:
Old logic -> 5,783,789 rand64() calls needed to find the magics
New logic -> 4,420,086 calls
32-bit SF:
Old logic -> 2,175,518 calls
New logic -> 1,895,955 calls
In the 64-bit case, init_magics() take 25 ms less to complete (Intel Core i5).
Finally, when playing with strength handicap, non-determinism is achieved
by setting the seed of the static RNG only once. Afterwards, there is no need
to skip output values.
The bench only changes because the Zobrist keys are now different (since they
are random numbers straight out of the PRNG).
The RNG seed has been carefully chosen so that the
resulting Zobrist keys are particularly well-behaved:
1. All triplets of XORed keys are unique, implying that it
would take at least 7 keys to find a 64-bit collision
(test suggested by ceebo)
2. All pairs of XORed keys are unique modulo 2^32
3. The cardinality of { (key1 ^ key2) >> 48 } is as close
as possible to the maximum (65536)
Point 2 aims at ensuring a good distribution among the bits
that determine an TT entry's cluster, likewise point 3
among the bits that form the TT entry's key16 inside a
cluster.
Details:
Bitset card(key1^key2)
------ ---------------
RKISS
key16 64894 = 99.020% of theoretical maximum
low18 180117 = 99.293%
low32 305362 = 99.997%
Xorshift64*, old seed
key16 64918 = 99.057%
low18 179994 = 99.225%
low32 305350 = 99.993%
Xorshift64*, new seed
key16 65027 = 99.223%
low18 181118 = 99.845%
low32 305371 = 100.000%
Bench: 9324905
Resolves #148
2014-12-07 17:10:57 -07:00
|
|
|
Zobrist::side = rng.rand<Key>();
|
2016-11-21 08:17:47 -07:00
|
|
|
Zobrist::noPawns = rng.rand<Key>();
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
|
|
|
|
// Prepare the cuckoo tables
|
2018-07-17 15:13:12 -06:00
|
|
|
std::memset(cuckoo, 0, sizeof(cuckoo));
|
|
|
|
std::memset(cuckooMove, 0, sizeof(cuckooMove));
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
int count = 0;
|
|
|
|
for (Piece pc : Pieces)
|
|
|
|
for (Square s1 = SQ_A1; s1 <= SQ_H8; ++s1)
|
|
|
|
for (Square s2 = Square(s1 + 1); s2 <= SQ_H8; ++s2)
|
|
|
|
if (PseudoAttacks[type_of(pc)][s1] & s2)
|
|
|
|
{
|
|
|
|
Move move = make_move(s1, s2);
|
|
|
|
Key key = Zobrist::psq[pc][s1] ^ Zobrist::psq[pc][s2] ^ Zobrist::side;
|
2018-05-21 01:37:16 -06:00
|
|
|
int i = H1(key);
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
while (true)
|
|
|
|
{
|
|
|
|
std::swap(cuckoo[i], key);
|
|
|
|
std::swap(cuckooMove[i], move);
|
2019-01-01 06:10:26 -07:00
|
|
|
if (move == MOVE_NONE) // Arrived at empty slot?
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
break;
|
|
|
|
i = (i == H1(key)) ? H2(key) : H1(key); // Push victim to alternative slot
|
|
|
|
}
|
|
|
|
count++;
|
|
|
|
}
|
|
|
|
assert(count == 3668);
|
2013-06-09 05:43:30 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-11-11 05:18:10 -07:00
|
|
|
/// Position::set() initializes the position object with the given FEN string.
|
|
|
|
/// This function is not very robust - make sure that input FENs are correct,
|
|
|
|
/// this is assumed to be the responsibility of the GUI.
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2016-04-11 08:45:36 -06:00
|
|
|
Position& Position::set(const string& fenStr, bool isChess960, StateInfo* si, Thread* th) {
|
2010-07-23 02:38:19 -06:00
|
|
|
/*
|
|
|
|
A FEN string defines a particular position using only the ASCII character set.
|
|
|
|
|
2011-10-30 08:46:00 -06:00
|
|
|
A FEN string contains six fields separated by a space. The fields are:
|
2010-07-23 02:38:19 -06:00
|
|
|
|
2011-10-30 08:46:00 -06:00
|
|
|
1) Piece placement (from white's perspective). Each rank is described, starting
|
2013-12-02 11:04:09 -07:00
|
|
|
with rank 8 and ending with rank 1. Within each rank, the contents of each
|
2011-10-30 08:46:00 -06:00
|
|
|
square are described from file A through file H. Following the Standard
|
|
|
|
Algebraic Notation (SAN), each piece is identified by a single letter taken
|
|
|
|
from the standard English names. White pieces are designated using upper-case
|
2013-12-02 11:04:09 -07:00
|
|
|
letters ("PNBRQK") whilst Black uses lowercase ("pnbrqk"). Blank squares are
|
2011-10-30 08:46:00 -06:00
|
|
|
noted using digits 1 through 8 (the number of blank squares), and "/"
|
|
|
|
separates ranks.
|
2010-07-23 02:38:19 -06:00
|
|
|
|
|
|
|
2) Active color. "w" means white moves next, "b" means black.
|
|
|
|
|
2011-10-30 08:46:00 -06:00
|
|
|
3) Castling availability. If neither side can castle, this is "-". Otherwise,
|
|
|
|
this has one or more letters: "K" (White can castle kingside), "Q" (White
|
|
|
|
can castle queenside), "k" (Black can castle kingside), and/or "q" (Black
|
|
|
|
can castle queenside).
|
2010-07-23 02:38:19 -06:00
|
|
|
|
2011-10-30 08:46:00 -06:00
|
|
|
4) En passant target square (in algebraic notation). If there's no en passant
|
|
|
|
target square, this is "-". If a pawn has just made a 2-square move, this
|
2016-11-09 08:42:27 -07:00
|
|
|
is the position "behind" the pawn. This is recorded only if there is a pawn
|
|
|
|
in position to make an en passant capture, and if there really is a pawn
|
|
|
|
that might have advanced two squares.
|
2010-07-23 02:38:19 -06:00
|
|
|
|
2011-10-30 08:46:00 -06:00
|
|
|
5) Halfmove clock. This is the number of halfmoves since the last pawn advance
|
|
|
|
or capture. This is used to determine if a draw can be claimed under the
|
|
|
|
fifty-move rule.
|
2010-07-23 02:38:19 -06:00
|
|
|
|
2011-10-30 08:46:00 -06:00
|
|
|
6) Fullmove number. The number of the full move. It starts at 1, and is
|
|
|
|
incremented after Black's move.
|
2010-07-23 02:38:19 -06:00
|
|
|
*/
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2014-06-06 17:16:31 -06:00
|
|
|
unsigned char col, row, token;
|
2013-12-03 02:09:17 -07:00
|
|
|
size_t idx;
|
2011-01-14 01:20:23 -07:00
|
|
|
Square sq = SQ_A8;
|
2012-11-11 05:18:10 -07:00
|
|
|
std::istringstream ss(fenStr);
|
2010-07-23 02:38:19 -06:00
|
|
|
|
2016-04-11 08:45:36 -06:00
|
|
|
std::memset(this, 0, sizeof(Position));
|
|
|
|
std::memset(si, 0, sizeof(StateInfo));
|
2016-09-03 10:14:01 -06:00
|
|
|
std::fill_n(&pieceList[0][0], sizeof(pieceList) / sizeof(Square), SQ_NONE);
|
2016-04-11 08:45:36 -06:00
|
|
|
st = si;
|
|
|
|
|
2012-11-11 05:18:10 -07:00
|
|
|
ss >> std::noskipws;
|
2010-07-23 02:38:19 -06:00
|
|
|
|
2011-06-27 03:07:57 -06:00
|
|
|
// 1. Piece placement
|
2012-11-11 05:18:10 -07:00
|
|
|
while ((ss >> token) && !isspace(token))
|
2008-09-27 05:28:58 -06:00
|
|
|
{
|
2012-01-12 10:12:25 -07:00
|
|
|
if (isdigit(token))
|
2017-12-04 09:52:31 -07:00
|
|
|
sq += (token - '0') * EAST; // Advance the given number of files
|
2011-06-27 03:07:57 -06:00
|
|
|
|
2012-01-12 10:12:25 -07:00
|
|
|
else if (token == '/')
|
2017-12-04 09:52:31 -07:00
|
|
|
sq += 2 * SOUTH;
|
2011-06-27 03:07:57 -06:00
|
|
|
|
2013-12-03 02:09:17 -07:00
|
|
|
else if ((idx = PieceToChar.find(token)) != string::npos)
|
2008-09-27 05:28:58 -06:00
|
|
|
{
|
2016-09-03 10:14:01 -06:00
|
|
|
put_piece(Piece(idx), sq);
|
2013-09-15 01:02:09 -06:00
|
|
|
++sq;
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-07-23 02:38:19 -06:00
|
|
|
// 2. Active color
|
2012-11-11 05:18:10 -07:00
|
|
|
ss >> token;
|
2010-07-23 02:38:19 -06:00
|
|
|
sideToMove = (token == 'w' ? WHITE : BLACK);
|
2012-11-11 05:18:10 -07:00
|
|
|
ss >> token;
|
2010-07-23 02:38:19 -06:00
|
|
|
|
2011-10-29 05:23:54 -06:00
|
|
|
// 3. Castling availability. Compatible with 3 standards: Normal FEN standard,
|
|
|
|
// Shredder-FEN that uses the letters of the columns on which the rooks began
|
|
|
|
// the game instead of KQkq and also X-FEN standard that, in case of Chess960,
|
|
|
|
// if an inner rook is associated with the castling right, the castling tag is
|
|
|
|
// replaced by the file letter of the involved rook, as for the Shredder-FEN.
|
2012-11-11 05:18:10 -07:00
|
|
|
while ((ss >> token) && !isspace(token))
|
2011-10-29 05:23:54 -06:00
|
|
|
{
|
|
|
|
Square rsq;
|
|
|
|
Color c = islower(token) ? BLACK : WHITE;
|
2015-05-28 21:38:40 -06:00
|
|
|
Piece rook = make_piece(c, ROOK);
|
2011-10-29 05:23:54 -06:00
|
|
|
|
|
|
|
token = char(toupper(token));
|
|
|
|
|
|
|
|
if (token == 'K')
|
2015-05-28 21:38:40 -06:00
|
|
|
for (rsq = relative_square(c, SQ_H1); piece_on(rsq) != rook; --rsq) {}
|
2011-10-29 05:23:54 -06:00
|
|
|
|
|
|
|
else if (token == 'Q')
|
2015-05-28 21:38:40 -06:00
|
|
|
for (rsq = relative_square(c, SQ_A1); piece_on(rsq) != rook; ++rsq) {}
|
2011-10-29 05:23:54 -06:00
|
|
|
|
|
|
|
else if (token >= 'A' && token <= 'H')
|
2014-03-22 16:35:30 -06:00
|
|
|
rsq = make_square(File(token - 'A'), relative_rank(c, RANK_1));
|
2011-10-29 05:23:54 -06:00
|
|
|
|
|
|
|
else
|
|
|
|
continue;
|
|
|
|
|
2014-03-08 07:08:55 -07:00
|
|
|
set_castling_right(c, rsq);
|
2011-10-29 05:23:54 -06:00
|
|
|
}
|
2011-06-27 03:07:57 -06:00
|
|
|
|
|
|
|
// 4. En passant square. Ignore if no pawn capture is possible
|
2012-11-11 05:18:10 -07:00
|
|
|
if ( ((ss >> col) && (col >= 'a' && col <= 'h'))
|
|
|
|
&& ((ss >> row) && (row == '3' || row == '6')))
|
2010-01-06 01:58:41 -07:00
|
|
|
{
|
2014-03-22 16:35:30 -06:00
|
|
|
st->epSquare = make_square(File(col - 'a'), Rank(row - '1'));
|
2010-07-23 02:38:19 -06:00
|
|
|
|
2016-11-09 08:42:27 -07:00
|
|
|
if ( !(attackers_to(st->epSquare) & pieces(sideToMove, PAWN))
|
|
|
|
|| !(pieces(~sideToMove, PAWN) & (st->epSquare + pawn_push(~sideToMove))))
|
2011-01-14 01:20:23 -07:00
|
|
|
st->epSquare = SQ_NONE;
|
2010-01-06 01:58:41 -07:00
|
|
|
}
|
2016-04-11 08:45:36 -06:00
|
|
|
else
|
|
|
|
st->epSquare = SQ_NONE;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2011-06-27 03:07:57 -06:00
|
|
|
// 5-6. Halfmove clock and fullmove number
|
2013-02-16 04:42:22 -07:00
|
|
|
ss >> std::skipws >> st->rule50 >> gamePly;
|
2011-07-20 02:01:12 -06:00
|
|
|
|
Let ss->ply denote the number of plies from the root to the current node
This patch lets ss->ply be equal to 0 at the root of the search.
Currently, the root has ss->ply == 1, which is less intuitive:
- Setting the rootNode bool has to check (ss-1)->ply == 0.
- All mate values are off by one: the code seems to assume that mated-in-0
is -VALUE_MATE, mate-1-in-ply is VALUE_MATE-1, mated-in-2-ply is VALUE_MATE+2, etc.
But the mate_in() and mated_in() functions are called with ss->ply, which is 1 in
at the root.
- The is_draw() function currently needs to explain why it has "ply - 1 > i" instead
of simply "ply > i".
- The ss->ply >= MAX_PLY tests in search() and qsearch() already assume that
ss->ply == 0 at the root. If we start at ss->ply == 1, it would make more sense to
go up to and including ss->ply == MAX_PLY, so stop at ss->ply > MAX_PLY. See also
the asserts testing for 0 <= ss->ply && ss->ply < MAX_PLY.
The reason for ss->ply == 1 at the root is the line "ss->ply = (ss-1)->ply + 1" at
the start for search() and qsearch(). By replacing this with "(ss+1)->ply = ss->ply + 1"
we keep ss->ply == 0 at the root. Note that search() already clears killers in (ss+2),
so there is no danger in accessing ss+1.
I have NOT changed pv[MAX_PLY + 1] to pv[MAX_PLY + 2] in search() and qsearch().
It seems to me that MAX_PLY + 1 is exactly right:
- MAX_PLY entries for ss->ply running from 0 to MAX_PLY-1, and 1 entry for the
final MOVE_NONE.
I have verified that mate scores are reported correctly. (They were already reported
correctly due to the extra ply being rounded down when converting to moves.)
The value of seldepth output to the user should probably not change, so I add 1 to it.
(Humans count from 1, computers from 0.)
A small optimisation I did not include: instead of setting ss->ply in every invocation
of search() and qsearch(), it could be set once for all plies at the start of
Thread::search(). This saves a couple of instructions per node.
No functional change (unless the search searches a branch MAX_PLY deep), so bench
does not change.
2017-09-16 13:49:29 -06:00
|
|
|
// Convert from fullmove starting from 1 to gamePly starting from 0,
|
2011-07-20 02:01:12 -06:00
|
|
|
// handle also common incorrect FEN with fullmove = 0.
|
2014-04-27 03:40:44 -06:00
|
|
|
gamePly = std::max(2 * (gamePly - 1), 0) + (sideToMove == BLACK);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2011-10-29 05:23:54 -06:00
|
|
|
chess960 = isChess960;
|
2012-04-06 11:36:46 -06:00
|
|
|
thisThread = th;
|
2014-03-12 15:46:17 -06:00
|
|
|
set_state(st);
|
2011-07-16 03:42:27 -06:00
|
|
|
|
2011-10-16 16:56:25 -06:00
|
|
|
assert(pos_is_ok());
|
2016-04-11 08:45:36 -06:00
|
|
|
|
|
|
|
return *this;
|
2010-07-23 02:38:19 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-03-08 07:08:55 -07:00
|
|
|
/// Position::set_castling_right() is a helper function used to set castling
|
|
|
|
/// rights given the corresponding color and the rook starting square.
|
2011-06-27 09:06:15 -06:00
|
|
|
|
2014-03-08 07:08:55 -07:00
|
|
|
void Position::set_castling_right(Color c, Square rfrom) {
|
2011-10-29 05:23:54 -06:00
|
|
|
|
2015-08-04 01:00:52 -06:00
|
|
|
Square kfrom = square<KING>(c);
|
2012-04-08 04:32:01 -06:00
|
|
|
CastlingSide cs = kfrom < rfrom ? KING_SIDE : QUEEN_SIDE;
|
2014-03-08 07:08:55 -07:00
|
|
|
CastlingRight cr = (c | cs);
|
2011-06-27 09:06:15 -06:00
|
|
|
|
2014-03-08 07:08:55 -07:00
|
|
|
st->castlingRights |= cr;
|
|
|
|
castlingRightsMask[kfrom] |= cr;
|
|
|
|
castlingRightsMask[rfrom] |= cr;
|
|
|
|
castlingRookSquare[cr] = rfrom;
|
2012-02-27 04:11:18 -07:00
|
|
|
|
2012-04-08 04:32:01 -06:00
|
|
|
Square kto = relative_square(c, cs == KING_SIDE ? SQ_G1 : SQ_C1);
|
|
|
|
Square rto = relative_square(c, cs == KING_SIDE ? SQ_F1 : SQ_D1);
|
2012-02-27 04:11:18 -07:00
|
|
|
|
2019-03-31 04:02:19 -06:00
|
|
|
castlingPath[cr] = (between_bb(rfrom, rto) | between_bb(kfrom, kto) | rto | kto)
|
|
|
|
& ~(square_bb(kfrom) | rfrom);
|
2011-06-27 09:06:15 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-07-03 02:35:44 -06:00
|
|
|
/// Position::set_check_info() sets king attacks to detect if a move gives check
|
|
|
|
|
2016-08-27 02:05:42 -06:00
|
|
|
void Position::set_check_info(StateInfo* si) const {
|
2016-07-03 02:35:44 -06:00
|
|
|
|
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
|
|
|
si->blockersForKing[WHITE] = slider_blockers(pieces(BLACK), square<KING>(WHITE), si->pinners[BLACK]);
|
|
|
|
si->blockersForKing[BLACK] = slider_blockers(pieces(WHITE), square<KING>(BLACK), si->pinners[WHITE]);
|
2016-07-03 02:35:44 -06:00
|
|
|
|
2016-08-27 02:05:42 -06:00
|
|
|
Square ksq = square<KING>(~sideToMove);
|
2016-07-03 02:35:44 -06:00
|
|
|
|
2016-08-27 02:05:42 -06:00
|
|
|
si->checkSquares[PAWN] = attacks_from<PAWN>(ksq, ~sideToMove);
|
|
|
|
si->checkSquares[KNIGHT] = attacks_from<KNIGHT>(ksq);
|
|
|
|
si->checkSquares[BISHOP] = attacks_from<BISHOP>(ksq);
|
|
|
|
si->checkSquares[ROOK] = attacks_from<ROOK>(ksq);
|
|
|
|
si->checkSquares[QUEEN] = si->checkSquares[BISHOP] | si->checkSquares[ROOK];
|
|
|
|
si->checkSquares[KING] = 0;
|
2016-07-03 02:35:44 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-03-12 15:46:17 -06:00
|
|
|
/// Position::set_state() computes the hash keys of the position, and other
|
|
|
|
/// data that once computed is updated incrementally as moves are made.
|
|
|
|
/// The function is only used when a new position is set up, and to verify
|
|
|
|
/// the correctness of the StateInfo data when running in debug mode.
|
|
|
|
|
|
|
|
void Position::set_state(StateInfo* si) const {
|
|
|
|
|
2016-11-21 08:17:47 -07:00
|
|
|
si->key = si->materialKey = 0;
|
|
|
|
si->pawnKey = Zobrist::noPawns;
|
2014-12-07 16:53:33 -07:00
|
|
|
si->nonPawnMaterial[WHITE] = si->nonPawnMaterial[BLACK] = VALUE_ZERO;
|
2015-08-04 01:00:52 -06:00
|
|
|
si->checkersBB = attackers_to(square<KING>(sideToMove)) & pieces(~sideToMove);
|
2014-03-12 15:46:17 -06:00
|
|
|
|
2016-08-27 02:05:42 -06:00
|
|
|
set_check_info(si);
|
2016-07-03 02:35:44 -06:00
|
|
|
|
2014-03-12 15:46:17 -06:00
|
|
|
for (Bitboard b = pieces(); b; )
|
|
|
|
{
|
|
|
|
Square s = pop_lsb(&b);
|
|
|
|
Piece pc = piece_on(s);
|
2016-09-03 10:14:01 -06:00
|
|
|
si->key ^= Zobrist::psq[pc][s];
|
2019-05-16 06:11:00 -06:00
|
|
|
|
|
|
|
if (type_of(pc) == PAWN)
|
|
|
|
si->pawnKey ^= Zobrist::psq[pc][s];
|
|
|
|
|
2019-05-02 11:36:25 -06:00
|
|
|
else if (type_of(pc) != KING)
|
2019-05-16 06:11:00 -06:00
|
|
|
si->nonPawnMaterial[color_of(pc)] += PieceValue[MG][pc];
|
2014-03-12 15:46:17 -06:00
|
|
|
}
|
|
|
|
|
2015-02-08 05:21:50 -07:00
|
|
|
if (si->epSquare != SQ_NONE)
|
|
|
|
si->key ^= Zobrist::enpassant[file_of(si->epSquare)];
|
2014-03-12 15:46:17 -06:00
|
|
|
|
|
|
|
if (sideToMove == BLACK)
|
|
|
|
si->key ^= Zobrist::side;
|
|
|
|
|
2015-02-07 11:34:24 -07:00
|
|
|
si->key ^= Zobrist::castling[si->castlingRights];
|
2014-03-12 15:46:17 -06:00
|
|
|
|
2016-09-04 07:29:11 -06:00
|
|
|
for (Piece pc : Pieces)
|
|
|
|
for (int cnt = 0; cnt < pieceCount[pc]; ++cnt)
|
|
|
|
si->materialKey ^= Zobrist::psq[pc][cnt];
|
2014-03-12 15:46:17 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-07-16 00:10:45 -06:00
|
|
|
/// Position::set() is an overload to initialize the position object with
|
2017-03-08 19:35:23 -07:00
|
|
|
/// the given endgame code string like "KBPKN". It is mainly a helper to
|
2017-06-24 04:36:07 -06:00
|
|
|
/// get the material key out of an endgame code.
|
2016-07-16 00:10:45 -06:00
|
|
|
|
|
|
|
Position& Position::set(const string& code, Color c, StateInfo* si) {
|
|
|
|
|
|
|
|
assert(code.length() > 0 && code.length() < 8);
|
|
|
|
assert(code[0] == 'K');
|
|
|
|
|
|
|
|
string sides[] = { code.substr(code.find('K', 1)), // Weak
|
|
|
|
code.substr(0, code.find('K', 1)) }; // Strong
|
|
|
|
|
|
|
|
std::transform(sides[c].begin(), sides[c].end(), sides[c].begin(), tolower);
|
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
string fenStr = "8/" + sides[0] + char(8 - sides[0].length() + '0') + "/8/8/8/8/"
|
|
|
|
+ sides[1] + char(8 - sides[1].length() + '0') + "/8 w - - 0 10";
|
2016-07-16 00:10:45 -06:00
|
|
|
|
|
|
|
return set(fenStr, false, si, nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-12-02 11:04:09 -07:00
|
|
|
/// Position::fen() returns a FEN representation of the position. In case of
|
|
|
|
/// Chess960 the Shredder-FEN notation is used. This is mainly a debugging function.
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2012-11-11 05:18:10 -07:00
|
|
|
const string Position::fen() const {
|
2008-09-29 11:02:48 -06:00
|
|
|
|
2013-12-03 02:09:17 -07:00
|
|
|
int emptyCnt;
|
2012-11-11 05:18:10 -07:00
|
|
|
std::ostringstream ss;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2014-04-06 02:50:27 -06:00
|
|
|
for (Rank r = RANK_8; r >= RANK_1; --r)
|
2008-09-29 11:02:48 -06:00
|
|
|
{
|
2014-04-06 02:50:27 -06:00
|
|
|
for (File f = FILE_A; f <= FILE_H; ++f)
|
2008-09-29 11:02:48 -06:00
|
|
|
{
|
2014-04-06 02:50:27 -06:00
|
|
|
for (emptyCnt = 0; f <= FILE_H && empty(make_square(f, r)); ++f)
|
2013-12-03 02:09:17 -07:00
|
|
|
++emptyCnt;
|
2013-01-04 04:32:13 -07:00
|
|
|
|
2013-12-03 02:09:17 -07:00
|
|
|
if (emptyCnt)
|
2013-01-04 04:32:13 -07:00
|
|
|
ss << emptyCnt;
|
2013-12-03 02:09:17 -07:00
|
|
|
|
2014-04-06 02:50:27 -06:00
|
|
|
if (f <= FILE_H)
|
|
|
|
ss << PieceToChar[piece_on(make_square(f, r))];
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
2011-01-29 05:14:01 -07:00
|
|
|
|
2014-04-06 02:50:27 -06:00
|
|
|
if (r > RANK_1)
|
2012-11-11 05:18:10 -07:00
|
|
|
ss << '/';
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
2010-07-24 10:59:18 -06:00
|
|
|
|
2012-11-11 05:18:10 -07:00
|
|
|
ss << (sideToMove == WHITE ? " w " : " b ");
|
2010-07-24 10:59:18 -06:00
|
|
|
|
2011-10-30 08:46:00 -06:00
|
|
|
if (can_castle(WHITE_OO))
|
2019-01-01 06:10:26 -07:00
|
|
|
ss << (chess960 ? char('A' + file_of(castling_rook_square(WHITE_OO ))) : 'K');
|
2011-10-30 08:46:00 -06:00
|
|
|
|
|
|
|
if (can_castle(WHITE_OOO))
|
2019-01-01 06:10:26 -07:00
|
|
|
ss << (chess960 ? char('A' + file_of(castling_rook_square(WHITE_OOO))) : 'Q');
|
2010-07-24 10:59:18 -06:00
|
|
|
|
2011-10-30 08:46:00 -06:00
|
|
|
if (can_castle(BLACK_OO))
|
2019-01-01 06:10:26 -07:00
|
|
|
ss << (chess960 ? char('a' + file_of(castling_rook_square(BLACK_OO ))) : 'k');
|
2010-07-24 10:59:18 -06:00
|
|
|
|
2011-10-30 08:46:00 -06:00
|
|
|
if (can_castle(BLACK_OOO))
|
2019-01-01 06:10:26 -07:00
|
|
|
ss << (chess960 ? char('a' + file_of(castling_rook_square(BLACK_OOO))) : 'q');
|
2010-07-24 10:59:18 -06:00
|
|
|
|
2018-12-11 05:47:56 -07:00
|
|
|
if (!can_castle(ANY_CASTLING))
|
2012-11-11 05:18:10 -07:00
|
|
|
ss << '-';
|
2011-07-03 04:32:34 -06:00
|
|
|
|
2014-12-14 01:31:13 -07:00
|
|
|
ss << (ep_square() == SQ_NONE ? " - " : " " + UCI::square(ep_square()) + " ")
|
2014-04-27 03:40:44 -06:00
|
|
|
<< st->rule50 << " " << 1 + (gamePly - (sideToMove == BLACK)) / 2;
|
2008-09-29 11:02:48 -06:00
|
|
|
|
2012-11-11 05:18:10 -07:00
|
|
|
return ss.str();
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-09-12 00:47:19 -06:00
|
|
|
/// Position::slider_blockers() returns a bitboard of all the pieces (both colors)
|
|
|
|
/// that are blocking attacks on the square 's' from 'sliders'. A piece blocks a
|
|
|
|
/// slider if removing that piece from the board would result in a position where
|
|
|
|
/// square 's' is attacked. For example, a king-attack blocking piece can be either
|
|
|
|
/// a pinned or a discovered check piece, according if its color is the opposite
|
2016-09-19 00:21:41 -06:00
|
|
|
/// or the same of the color of the slider.
|
2014-01-11 02:58:09 -07:00
|
|
|
|
2016-09-12 00:47:19 -06:00
|
|
|
Bitboard Position::slider_blockers(Bitboard sliders, Square s, Bitboard& pinners) const {
|
2013-06-23 00:08:16 -06:00
|
|
|
|
2018-02-26 17:18:33 -07:00
|
|
|
Bitboard blockers = 0;
|
2016-09-19 00:21:41 -06:00
|
|
|
pinners = 0;
|
2013-06-23 00:08:16 -06:00
|
|
|
|
Change pinning logic in Static Exchange Evaluation (SEE)
This changes 2 parts with regards to static exchange evaluation.
Currently, we do not allow pinned pieces to recapture if *all* opponent
pinners are still in their starting squares. This changes that to having
a less strict requirement, checking if *any* pinners are still in their
starting square. This makes our SEE give more respect to the pinning
side with regards to exchanges, which makes sense because it helps our
search explore more tactical options.
Furthermore, we change the logic for saving pinners into our state
variable when computing slider_blockers. We will include double pinners,
where two sliders may be looking at the same blocker, a similar concept
to our mobility calculation for sliders in our evaluation section.
Interestingly, I think SEE is the only place where the pinners bitboard
is actually used, so as far as I know there are no other side effects
to this change.
An example and some insights:
White Bf2, Kg1
Black Qe3, Bc5
The move Qg3 will be given the correct value of 0. (Previously < 0)
The move Qd4 will be incorrectly given a value of 0. (Previously < 0)
It seems the tradeoff in search is worth it. Qd4 will likely be pruned
soon by something like probcut anyway, while Qg3 could help us spot
tactics at an earlier depth.
STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 62162 W: 13879 L: 13408 D: 34875
http://tests.stockfishchess.org/tests/view/5c4ba1a70ebc593af5d49c55
LTC: (Thanks to @alayant)
LLR: 3.40 (-2.94,2.94) [0.00,3.50]
Total: 140285 W: 23416 L: 22825 D: 94044
http://tests.stockfishchess.org/tests/view/5c4bcfba0ebc593af5d49ea8
Bench: 3937213
2019-01-24 23:37:03 -07:00
|
|
|
// Snipers are sliders that attack 's' when a piece and other snipers are removed
|
2017-06-11 15:31:15 -06:00
|
|
|
Bitboard snipers = ( (PseudoAttacks[ ROOK][s] & pieces(QUEEN, ROOK))
|
2016-09-19 00:21:41 -06:00
|
|
|
| (PseudoAttacks[BISHOP][s] & pieces(QUEEN, BISHOP))) & sliders;
|
2019-05-02 11:36:25 -06:00
|
|
|
Bitboard occupancy = pieces() ^ snipers;
|
2008-10-23 04:59:20 -06:00
|
|
|
|
2016-09-19 00:21:41 -06:00
|
|
|
while (snipers)
|
2009-03-04 04:04:28 -07:00
|
|
|
{
|
2016-09-19 00:21:41 -06:00
|
|
|
Square sniperSq = pop_lsb(&snipers);
|
Change pinning logic in Static Exchange Evaluation (SEE)
This changes 2 parts with regards to static exchange evaluation.
Currently, we do not allow pinned pieces to recapture if *all* opponent
pinners are still in their starting squares. This changes that to having
a less strict requirement, checking if *any* pinners are still in their
starting square. This makes our SEE give more respect to the pinning
side with regards to exchanges, which makes sense because it helps our
search explore more tactical options.
Furthermore, we change the logic for saving pinners into our state
variable when computing slider_blockers. We will include double pinners,
where two sliders may be looking at the same blocker, a similar concept
to our mobility calculation for sliders in our evaluation section.
Interestingly, I think SEE is the only place where the pinners bitboard
is actually used, so as far as I know there are no other side effects
to this change.
An example and some insights:
White Bf2, Kg1
Black Qe3, Bc5
The move Qg3 will be given the correct value of 0. (Previously < 0)
The move Qd4 will be incorrectly given a value of 0. (Previously < 0)
It seems the tradeoff in search is worth it. Qd4 will likely be pruned
soon by something like probcut anyway, while Qg3 could help us spot
tactics at an earlier depth.
STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 62162 W: 13879 L: 13408 D: 34875
http://tests.stockfishchess.org/tests/view/5c4ba1a70ebc593af5d49c55
LTC: (Thanks to @alayant)
LLR: 3.40 (-2.94,2.94) [0.00,3.50]
Total: 140285 W: 23416 L: 22825 D: 94044
http://tests.stockfishchess.org/tests/view/5c4bcfba0ebc593af5d49ea8
Bench: 3937213
2019-01-24 23:37:03 -07:00
|
|
|
Bitboard b = between_bb(s, sniperSq) & occupancy;
|
2016-09-19 00:21:41 -06:00
|
|
|
|
2018-02-26 17:18:33 -07:00
|
|
|
if (b && !more_than_one(b))
|
2016-09-19 00:21:41 -06:00
|
|
|
{
|
2018-02-26 17:18:33 -07:00
|
|
|
blockers |= b;
|
2016-09-19 00:21:41 -06:00
|
|
|
if (b & pieces(color_of(piece_on(s))))
|
|
|
|
pinners |= sniperSq;
|
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
2018-02-26 17:18:33 -07:00
|
|
|
return blockers;
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2009-03-04 15:11:23 -07:00
|
|
|
|
2011-10-30 11:59:12 -06:00
|
|
|
/// Position::attackers_to() computes a bitboard of all pieces which attack a
|
2014-12-07 16:53:33 -07:00
|
|
|
/// given square. Slider attacks use the occupied bitboard to indicate occupancy.
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2014-12-07 16:53:33 -07:00
|
|
|
Bitboard Position::attackers_to(Square s, Bitboard occupied) const {
|
2011-05-22 03:57:06 -06:00
|
|
|
|
2014-12-07 16:53:33 -07:00
|
|
|
return (attacks_from<PAWN>(s, BLACK) & pieces(WHITE, PAWN))
|
|
|
|
| (attacks_from<PAWN>(s, WHITE) & pieces(BLACK, PAWN))
|
|
|
|
| (attacks_from<KNIGHT>(s) & pieces(KNIGHT))
|
2017-06-11 15:31:15 -06:00
|
|
|
| (attacks_bb< ROOK>(s, occupied) & pieces( ROOK, QUEEN))
|
2014-12-07 16:53:33 -07:00
|
|
|
| (attacks_bb<BISHOP>(s, occupied) & pieces(BISHOP, QUEEN))
|
|
|
|
| (attacks_from<KING>(s) & pieces(KING));
|
2011-05-22 03:57:06 -06:00
|
|
|
}
|
|
|
|
|
2011-10-30 11:16:28 -06:00
|
|
|
|
2013-09-28 06:43:50 -06:00
|
|
|
/// Position::legal() tests whether a pseudo-legal move is legal
|
2009-02-28 01:18:29 -07:00
|
|
|
|
2016-07-03 02:35:44 -06:00
|
|
|
bool Position::legal(Move m) const {
|
2008-10-23 14:51:26 -06:00
|
|
|
|
2011-10-03 02:56:49 -06:00
|
|
|
assert(is_ok(m));
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2012-01-12 11:31:18 -07:00
|
|
|
Color us = sideToMove;
|
2012-01-01 08:00:00 -07:00
|
|
|
Square from = from_sq(m);
|
2019-01-02 00:31:03 -07:00
|
|
|
Square to = to_sq(m);
|
2011-05-22 03:57:06 -06:00
|
|
|
|
2013-09-28 06:43:50 -06:00
|
|
|
assert(color_of(moved_piece(m)) == us);
|
2015-08-04 01:00:52 -06:00
|
|
|
assert(piece_on(square<KING>(us)) == make_piece(us, KING));
|
2011-05-22 03:57:06 -06:00
|
|
|
|
2011-07-14 05:12:49 -06:00
|
|
|
// En passant captures are a tricky special case. Because they are rather
|
|
|
|
// uncommon, we do it simply by testing whether the king is attacked after
|
|
|
|
// the move is made.
|
2012-06-24 03:08:16 -06:00
|
|
|
if (type_of(m) == ENPASSANT)
|
2008-10-23 14:51:26 -06:00
|
|
|
{
|
2015-08-04 01:00:52 -06:00
|
|
|
Square ksq = square<KING>(us);
|
2014-03-14 02:43:19 -06:00
|
|
|
Square capsq = to - pawn_push(us);
|
2014-12-07 16:53:33 -07:00
|
|
|
Bitboard occupied = (pieces() ^ from ^ capsq) | to;
|
2008-10-23 14:51:26 -06:00
|
|
|
|
|
|
|
assert(to == ep_square());
|
2013-09-28 06:43:50 -06:00
|
|
|
assert(moved_piece(m) == make_piece(us, PAWN));
|
2014-03-14 02:43:19 -06:00
|
|
|
assert(piece_on(capsq) == make_piece(~us, PAWN));
|
2011-12-27 11:26:27 -07:00
|
|
|
assert(piece_on(to) == NO_PIECE);
|
2008-10-23 14:51:26 -06:00
|
|
|
|
2014-12-07 16:53:33 -07:00
|
|
|
return !(attacks_bb< ROOK>(ksq, occupied) & pieces(~us, QUEEN, ROOK))
|
|
|
|
&& !(attacks_bb<BISHOP>(ksq, occupied) & pieces(~us, QUEEN, BISHOP));
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2019-01-02 00:31:03 -07:00
|
|
|
// Castling moves generation does not check if the castling path is clear of
|
|
|
|
// enemy attacks, it is delayed at a later time: now!
|
|
|
|
if (type_of(m) == CASTLING)
|
|
|
|
{
|
|
|
|
// After castling, the rook and king final positions are the same in
|
|
|
|
// Chess960 as they would be in standard chess.
|
|
|
|
to = relative_square(us, to > from ? SQ_G1 : SQ_C1);
|
|
|
|
Direction step = to > from ? WEST : EAST;
|
|
|
|
|
|
|
|
for (Square s = to; s != from; s += step)
|
|
|
|
if (attackers_to(s) & pieces(~us))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// In case of Chess960, verify that when moving the castling rook we do
|
|
|
|
// not discover some hidden checker.
|
|
|
|
// For instance an enemy queen in SQ_A1 when castling rook is in SQ_B1.
|
|
|
|
return !chess960
|
|
|
|
|| !(attacks_bb<ROOK>(to, pieces() ^ to_sq(m)) & pieces(~us, ROOK, QUEEN));
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the moving piece is a king, check whether the destination square is
|
|
|
|
// attacked by the opponent.
|
2011-10-02 01:33:40 -06:00
|
|
|
if (type_of(piece_on(from)) == KING)
|
2019-01-02 00:31:03 -07:00
|
|
|
return !(attackers_to(to) & pieces(~us));
|
2008-08-31 23:59:13 -06:00
|
|
|
|
|
|
|
// A non-king move is legal if and only if it is not pinned or it
|
|
|
|
// is moving along the ray towards or away from the king.
|
2018-02-26 17:18:33 -07:00
|
|
|
return !(blockers_for_king(us) & from)
|
2019-01-02 00:31:03 -07:00
|
|
|
|| aligned(from, to, square<KING>(us));
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-09-28 06:43:50 -06:00
|
|
|
/// Position::pseudo_legal() takes a random move and tests whether the move is
|
|
|
|
/// pseudo legal. It is used to validate moves from TT that can be corrupted
|
2011-10-03 02:56:49 -06:00
|
|
|
/// due to SMP concurrent access or hash position key aliasing.
|
2011-04-13 03:54:41 -06:00
|
|
|
|
2013-09-28 06:43:50 -06:00
|
|
|
bool Position::pseudo_legal(const Move m) const {
|
2011-04-13 03:54:41 -06:00
|
|
|
|
|
|
|
Color us = sideToMove;
|
2012-01-01 08:00:00 -07:00
|
|
|
Square from = from_sq(m);
|
|
|
|
Square to = to_sq(m);
|
2013-09-28 06:43:50 -06:00
|
|
|
Piece pc = moved_piece(m);
|
2011-04-13 03:54:41 -06:00
|
|
|
|
|
|
|
// Use a slower but simpler function for uncommon cases
|
2012-06-24 03:08:16 -06:00
|
|
|
if (type_of(m) != NORMAL)
|
2012-12-25 03:40:28 -07:00
|
|
|
return MoveList<LEGAL>(*this).contains(m);
|
2011-04-13 03:54:41 -06:00
|
|
|
|
2011-05-22 01:35:14 -06:00
|
|
|
// Is not a promotion, so promotion piece must be empty
|
2015-02-08 05:21:50 -07:00
|
|
|
if (promotion_type(m) - KNIGHT != NO_PIECE_TYPE)
|
2011-05-22 01:35:14 -06:00
|
|
|
return false;
|
|
|
|
|
2013-12-04 23:18:12 -07:00
|
|
|
// If the 'from' square is not occupied by a piece belonging to the side to
|
2011-04-13 03:54:41 -06:00
|
|
|
// move, the move is obviously not legal.
|
2011-12-27 11:26:27 -07:00
|
|
|
if (pc == NO_PIECE || color_of(pc) != us)
|
2011-04-13 03:54:41 -06:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// The destination square cannot be occupied by a friendly piece
|
2013-07-22 04:47:59 -06:00
|
|
|
if (pieces(us) & to)
|
2011-04-13 03:54:41 -06:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// Handle the special case of a pawn move
|
2011-10-02 01:33:40 -06:00
|
|
|
if (type_of(pc) == PAWN)
|
2011-04-13 03:54:41 -06:00
|
|
|
{
|
|
|
|
// We have already handled promotion moves, so destination
|
2013-12-02 15:47:38 -07:00
|
|
|
// cannot be on the 8th/1st rank.
|
2019-03-31 03:47:36 -06:00
|
|
|
if ((Rank8BB | Rank1BB) & to)
|
2011-04-13 03:54:41 -06:00
|
|
|
return false;
|
|
|
|
|
2014-03-10 01:38:23 -06:00
|
|
|
if ( !(attacks_from<PAWN>(from, us) & pieces(~us) & to) // Not a capture
|
|
|
|
&& !((from + pawn_push(us) == to) && empty(to)) // Not a single push
|
|
|
|
&& !( (from + 2 * pawn_push(us) == to) // Not a double push
|
|
|
|
&& (rank_of(from) == relative_rank(us, RANK_2))
|
|
|
|
&& empty(to)
|
|
|
|
&& empty(to - pawn_push(us))))
|
2011-05-22 02:35:34 -06:00
|
|
|
return false;
|
2011-04-13 03:54:41 -06:00
|
|
|
}
|
2017-04-28 21:33:30 -06:00
|
|
|
else if (!(attacks_from(type_of(pc), from) & to))
|
2011-04-13 03:54:41 -06:00
|
|
|
return false;
|
|
|
|
|
2011-10-22 07:53:35 -06:00
|
|
|
// Evasions generator already takes care to avoid some kind of illegal moves
|
2014-03-10 01:38:23 -06:00
|
|
|
// and legal() relies on this. We therefore have to take care that the same
|
|
|
|
// kind of moves are filtered out here.
|
2012-12-25 09:59:35 -07:00
|
|
|
if (checkers())
|
2011-05-22 03:57:06 -06:00
|
|
|
{
|
2012-02-26 09:34:24 -07:00
|
|
|
if (type_of(pc) != KING)
|
2011-05-22 03:57:06 -06:00
|
|
|
{
|
2012-12-25 03:22:55 -07:00
|
|
|
// Double check? In this case a king move is required
|
|
|
|
if (more_than_one(checkers()))
|
2011-05-22 03:57:06 -06:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// Our move must be a blocking evasion or a capture of the checking piece
|
2015-08-04 01:00:52 -06:00
|
|
|
if (!((between_bb(lsb(checkers()), square<KING>(us)) | checkers()) & to))
|
2011-05-22 03:57:06 -06:00
|
|
|
return false;
|
|
|
|
}
|
2013-12-04 23:18:12 -07:00
|
|
|
// In case of king moves under check we have to remove king so as to catch
|
|
|
|
// invalid moves like b1a1 when opposite queen is on c1.
|
2012-03-18 04:10:12 -06:00
|
|
|
else if (attackers_to(to, pieces() ^ from) & pieces(~us))
|
2012-02-26 09:34:24 -07:00
|
|
|
return false;
|
2011-05-22 03:57:06 -06:00
|
|
|
}
|
|
|
|
|
2011-05-23 04:04:59 -06:00
|
|
|
return true;
|
2011-04-13 03:54:41 -06:00
|
|
|
}
|
|
|
|
|
2009-11-05 04:52:40 -07:00
|
|
|
|
2014-01-06 22:25:35 -07:00
|
|
|
/// Position::gives_check() tests whether a pseudo-legal move gives a check
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2016-07-03 02:35:44 -06:00
|
|
|
bool Position::gives_check(Move m) const {
|
2009-11-09 13:02:07 -07:00
|
|
|
|
2011-10-03 02:56:49 -06:00
|
|
|
assert(is_ok(m));
|
2013-09-28 06:43:50 -06:00
|
|
|
assert(color_of(moved_piece(m)) == sideToMove);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2012-01-01 08:00:00 -07:00
|
|
|
Square from = from_sq(m);
|
|
|
|
Square to = to_sq(m);
|
2008-10-23 14:51:26 -06:00
|
|
|
|
2013-12-04 23:18:12 -07:00
|
|
|
// Is there a direct check?
|
2016-08-27 02:05:42 -06:00
|
|
|
if (st->checkSquares[type_of(piece_on(from))] & to)
|
2012-11-11 03:04:58 -07:00
|
|
|
return true;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-12-04 23:18:12 -07:00
|
|
|
// Is there a discovered check?
|
2018-02-26 17:18:33 -07:00
|
|
|
if ( (st->blockersForKing[~sideToMove] & from)
|
2016-08-27 02:05:42 -06:00
|
|
|
&& !aligned(from, to, square<KING>(~sideToMove)))
|
2013-12-01 02:07:16 -07:00
|
|
|
return true;
|
2008-10-26 06:23:27 -06:00
|
|
|
|
2012-11-17 04:57:58 -07:00
|
|
|
switch (type_of(m))
|
|
|
|
{
|
2014-03-11 15:58:08 -06:00
|
|
|
case NORMAL:
|
|
|
|
return false;
|
|
|
|
|
2012-11-17 04:57:58 -07:00
|
|
|
case PROMOTION:
|
2017-04-28 21:33:30 -06:00
|
|
|
return attacks_bb(promotion_type(m), to, pieces() ^ from) & square<KING>(~sideToMove);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-12-04 23:18:12 -07:00
|
|
|
// En passant capture with check? We have already handled the case
|
2013-12-02 11:04:09 -07:00
|
|
|
// of direct checks and ordinary discovered check, so the only case we
|
2010-06-29 04:14:44 -06:00
|
|
|
// need to handle is the unusual case of a discovered check through
|
|
|
|
// the captured pawn.
|
2012-11-17 04:57:58 -07:00
|
|
|
case ENPASSANT:
|
2009-11-09 13:29:22 -07:00
|
|
|
{
|
2014-03-22 16:35:30 -06:00
|
|
|
Square capsq = make_square(file_of(to), rank_of(from));
|
2012-03-18 04:10:12 -06:00
|
|
|
Bitboard b = (pieces() ^ from ^ capsq) | to;
|
2012-02-26 09:34:24 -07:00
|
|
|
|
2016-08-27 02:05:42 -06:00
|
|
|
return (attacks_bb< ROOK>(square<KING>(~sideToMove), b) & pieces(sideToMove, QUEEN, ROOK))
|
|
|
|
| (attacks_bb<BISHOP>(square<KING>(~sideToMove), b) & pieces(sideToMove, QUEEN, BISHOP));
|
2009-11-09 13:29:22 -07:00
|
|
|
}
|
2013-12-01 02:25:10 -07:00
|
|
|
case CASTLING:
|
2009-11-09 13:29:22 -07:00
|
|
|
{
|
2012-02-26 09:34:24 -07:00
|
|
|
Square kfrom = from;
|
2013-12-01 02:25:10 -07:00
|
|
|
Square rfrom = to; // Castling is encoded as 'King captures the rook'
|
2014-01-07 08:55:32 -07:00
|
|
|
Square kto = relative_square(sideToMove, rfrom > kfrom ? SQ_G1 : SQ_C1);
|
|
|
|
Square rto = relative_square(sideToMove, rfrom > kfrom ? SQ_F1 : SQ_D1);
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2016-08-27 02:05:42 -06:00
|
|
|
return (PseudoAttacks[ROOK][rto] & square<KING>(~sideToMove))
|
|
|
|
&& (attacks_bb<ROOK>(rto, (pieces() ^ kfrom ^ rfrom) | rto | kto) & square<KING>(~sideToMove));
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
2012-11-17 04:57:58 -07:00
|
|
|
default:
|
|
|
|
assert(false);
|
|
|
|
return false;
|
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-02-22 12:16:21 -07:00
|
|
|
/// Position::do_move() makes a move, and saves all information necessary
|
2011-04-26 03:19:57 -06:00
|
|
|
/// to a StateInfo object. The move is assumed to be legal. Pseudo-legal
|
|
|
|
/// moves should be filtered out before this function is called.
|
2008-08-31 23:59:13 -06:00
|
|
|
|
Compute checkers from scratch
This micro-optimization only complicates the code and provides no benefit.
Removing it is even a speedup on my machine (i7-3770k, linux, gcc 4.9.1):
stat test master diff
mean 2,403,118 2,390,904 12,214
stdev 12,043 10,620 3,677
speedup 0.51%
P(speedup>0) 100.0%
No functional change.
2015-02-15 00:49:20 -07:00
|
|
|
void Position::do_move(Move m, StateInfo& newSt, bool givesCheck) {
|
2009-03-02 08:20:00 -07:00
|
|
|
|
2011-10-03 02:56:49 -06:00
|
|
|
assert(is_ok(m));
|
2011-01-09 03:22:59 -07:00
|
|
|
assert(&newSt != st);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-06-23 23:15:46 -06:00
|
|
|
thisThread->nodes.fetch_add(1, std::memory_order_relaxed);
|
2015-02-07 11:34:24 -07:00
|
|
|
Key k = st->key ^ Zobrist::side;
|
2009-08-17 01:57:09 -06:00
|
|
|
|
2013-12-04 23:18:12 -07:00
|
|
|
// Copy some fields of the old state to our new StateInfo object except the
|
|
|
|
// ones which are going to be recalculated from scratch anyway and then switch
|
|
|
|
// our state pointer to point to the new (ready to be updated) state.
|
2015-02-07 11:34:24 -07:00
|
|
|
std::memcpy(&newSt, st, offsetof(StateInfo, key));
|
2009-02-28 01:18:29 -07:00
|
|
|
newSt.previous = st;
|
2009-02-22 12:16:21 -07:00
|
|
|
st = &newSt;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-12-04 23:18:12 -07:00
|
|
|
// Increment ply counters. In particular, rule50 will be reset to zero later on
|
2013-02-16 04:42:22 -07:00
|
|
|
// in case of a capture or a pawn move.
|
2013-10-02 22:01:38 -06:00
|
|
|
++gamePly;
|
|
|
|
++st->rule50;
|
|
|
|
++st->pliesFromNull;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2012-01-12 11:31:18 -07:00
|
|
|
Color us = sideToMove;
|
|
|
|
Color them = ~us;
|
2012-01-01 08:00:00 -07:00
|
|
|
Square from = from_sq(m);
|
|
|
|
Square to = to_sq(m);
|
2016-09-03 10:14:01 -06:00
|
|
|
Piece pc = piece_on(from);
|
|
|
|
Piece captured = type_of(m) == ENPASSANT ? make_piece(them, PAWN) : piece_on(to);
|
2009-08-16 07:49:15 -06:00
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
assert(color_of(pc) == us);
|
|
|
|
assert(captured == NO_PIECE || color_of(captured) == (type_of(m) != CASTLING ? them : us));
|
|
|
|
assert(type_of(captured) != KING);
|
2009-02-22 10:31:24 -07:00
|
|
|
|
2013-12-01 02:25:10 -07:00
|
|
|
if (type_of(m) == CASTLING)
|
2013-01-27 10:48:27 -07:00
|
|
|
{
|
2016-09-03 10:14:01 -06:00
|
|
|
assert(pc == make_piece(us, KING));
|
|
|
|
assert(captured == make_piece(us, ROOK));
|
2013-01-27 10:48:27 -07:00
|
|
|
|
2014-03-13 05:53:03 -06:00
|
|
|
Square rfrom, rto;
|
2015-02-08 05:21:50 -07:00
|
|
|
do_castling<true>(us, from, to, rfrom, rto);
|
2013-01-27 10:48:27 -07:00
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
k ^= Zobrist::psq[captured][rfrom] ^ Zobrist::psq[captured][rto];
|
|
|
|
captured = NO_PIECE;
|
2013-01-27 10:48:27 -07:00
|
|
|
}
|
|
|
|
|
2013-09-28 06:43:50 -06:00
|
|
|
if (captured)
|
2011-10-30 03:57:00 -06:00
|
|
|
{
|
|
|
|
Square capsq = to;
|
|
|
|
|
2011-10-30 04:26:06 -06:00
|
|
|
// If the captured piece is a pawn, update pawn hash key, otherwise
|
2011-10-30 03:57:00 -06:00
|
|
|
// update non-pawn material.
|
2016-09-03 10:14:01 -06:00
|
|
|
if (type_of(captured) == PAWN)
|
2011-10-30 03:57:00 -06:00
|
|
|
{
|
2012-06-24 03:08:16 -06:00
|
|
|
if (type_of(m) == ENPASSANT)
|
2011-10-30 03:57:00 -06:00
|
|
|
{
|
2015-02-07 11:34:24 -07:00
|
|
|
capsq -= pawn_push(us);
|
2011-10-30 03:57:00 -06:00
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
assert(pc == make_piece(us, PAWN));
|
2011-10-30 03:57:00 -06:00
|
|
|
assert(to == st->epSquare);
|
|
|
|
assert(relative_rank(us, to) == RANK_6);
|
2011-12-27 11:26:27 -07:00
|
|
|
assert(piece_on(to) == NO_PIECE);
|
2011-10-30 03:57:00 -06:00
|
|
|
assert(piece_on(capsq) == make_piece(them, PAWN));
|
|
|
|
|
2015-02-07 11:34:24 -07:00
|
|
|
board[capsq] = NO_PIECE; // Not done by remove_piece()
|
2011-10-30 03:57:00 -06:00
|
|
|
}
|
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
st->pawnKey ^= Zobrist::psq[captured][capsq];
|
2011-10-30 03:57:00 -06:00
|
|
|
}
|
|
|
|
else
|
2014-12-07 16:53:33 -07:00
|
|
|
st->nonPawnMaterial[them] -= PieceValue[MG][captured];
|
2011-10-30 03:57:00 -06:00
|
|
|
|
2013-08-01 07:58:38 -06:00
|
|
|
// Update board and piece lists
|
2016-09-03 10:14:01 -06:00
|
|
|
remove_piece(captured, capsq);
|
2011-10-30 04:26:06 -06:00
|
|
|
|
2013-01-27 02:15:59 -07:00
|
|
|
// Update material hash key and prefetch access to materialTable
|
2016-09-03 10:14:01 -06:00
|
|
|
k ^= Zobrist::psq[captured][capsq];
|
|
|
|
st->materialKey ^= Zobrist::psq[captured][pieceCount[captured]];
|
2015-02-07 11:13:41 -07:00
|
|
|
prefetch(thisThread->materialTable[st->materialKey]);
|
2011-10-30 03:57:00 -06:00
|
|
|
|
|
|
|
// Reset rule 50 counter
|
|
|
|
st->rule50 = 0;
|
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2009-08-17 01:57:09 -06:00
|
|
|
// Update hash key
|
2016-09-03 10:14:01 -06:00
|
|
|
k ^= Zobrist::psq[pc][from] ^ Zobrist::psq[pc][to];
|
2009-02-12 04:12:46 -07:00
|
|
|
|
2009-08-17 01:57:09 -06:00
|
|
|
// Reset en passant square
|
|
|
|
if (st->epSquare != SQ_NONE)
|
|
|
|
{
|
2012-08-20 11:09:57 -06:00
|
|
|
k ^= Zobrist::enpassant[file_of(st->epSquare)];
|
2009-08-17 01:57:09 -06:00
|
|
|
st->epSquare = SQ_NONE;
|
|
|
|
}
|
2009-08-09 08:53:51 -06:00
|
|
|
|
2014-03-08 07:08:55 -07:00
|
|
|
// Update castling rights if needed
|
|
|
|
if (st->castlingRights && (castlingRightsMask[from] | castlingRightsMask[to]))
|
2009-08-17 01:57:09 -06:00
|
|
|
{
|
2014-03-08 07:08:55 -07:00
|
|
|
int cr = castlingRightsMask[from] | castlingRightsMask[to];
|
|
|
|
k ^= Zobrist::castling[st->castlingRights & cr];
|
|
|
|
st->castlingRights &= ~cr;
|
2009-08-17 01:57:09 -06:00
|
|
|
}
|
2009-08-09 08:53:51 -06:00
|
|
|
|
2013-12-01 02:25:10 -07:00
|
|
|
// Move the piece. The tricky Chess960 castling is handled earlier
|
|
|
|
if (type_of(m) != CASTLING)
|
2016-09-03 10:14:01 -06:00
|
|
|
move_piece(pc, from, to);
|
2009-08-09 08:53:51 -06:00
|
|
|
|
2011-10-30 04:26:06 -06:00
|
|
|
// If the moving piece is a pawn do some special extra work
|
2016-09-03 10:14:01 -06:00
|
|
|
if (type_of(pc) == PAWN)
|
2009-08-17 01:57:09 -06:00
|
|
|
{
|
2013-12-02 11:04:09 -07:00
|
|
|
// Set en-passant square if the moved pawn can be captured
|
2012-02-26 09:34:24 -07:00
|
|
|
if ( (int(to) ^ int(from)) == 16
|
2015-02-07 11:34:24 -07:00
|
|
|
&& (attacks_from<PAWN>(to - pawn_push(us), us) & pieces(them, PAWN)))
|
2009-08-17 01:57:09 -06:00
|
|
|
{
|
2017-12-04 09:52:31 -07:00
|
|
|
st->epSquare = to - pawn_push(us);
|
2012-08-20 11:09:57 -06:00
|
|
|
k ^= Zobrist::enpassant[file_of(st->epSquare)];
|
2009-08-17 01:57:09 -06:00
|
|
|
}
|
2010-05-31 05:01:33 -06:00
|
|
|
|
2014-04-26 16:25:18 -06:00
|
|
|
else if (type_of(m) == PROMOTION)
|
2010-05-31 05:01:33 -06:00
|
|
|
{
|
2016-09-03 10:14:01 -06:00
|
|
|
Piece promotion = make_piece(us, promotion_type(m));
|
2010-05-31 05:01:33 -06:00
|
|
|
|
2011-10-30 04:26:06 -06:00
|
|
|
assert(relative_rank(us, to) == RANK_8);
|
2016-09-03 10:14:01 -06:00
|
|
|
assert(type_of(promotion) >= KNIGHT && type_of(promotion) <= QUEEN);
|
2010-05-31 05:01:33 -06:00
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
remove_piece(pc, to);
|
|
|
|
put_piece(promotion, to);
|
2010-05-31 05:01:33 -06:00
|
|
|
|
2011-10-30 04:26:06 -06:00
|
|
|
// Update hash keys
|
2016-09-03 10:14:01 -06:00
|
|
|
k ^= Zobrist::psq[pc][to] ^ Zobrist::psq[promotion][to];
|
|
|
|
st->pawnKey ^= Zobrist::psq[pc][to];
|
|
|
|
st->materialKey ^= Zobrist::psq[promotion][pieceCount[promotion]-1]
|
|
|
|
^ Zobrist::psq[pc][pieceCount[pc]];
|
2010-05-31 05:01:33 -06:00
|
|
|
|
|
|
|
// Update material
|
2014-12-07 16:53:33 -07:00
|
|
|
st->nonPawnMaterial[us] += PieceValue[MG][promotion];
|
2010-05-31 05:01:33 -06:00
|
|
|
}
|
2011-10-30 04:26:06 -06:00
|
|
|
|
2013-01-27 02:15:59 -07:00
|
|
|
// Update pawn hash key and prefetch access to pawnsTable
|
2016-09-03 10:14:01 -06:00
|
|
|
st->pawnKey ^= Zobrist::psq[pc][from] ^ Zobrist::psq[pc][to];
|
2011-10-30 04:26:06 -06:00
|
|
|
|
|
|
|
// Reset rule 50 draw counter
|
|
|
|
st->rule50 = 0;
|
2009-08-17 01:57:09 -06:00
|
|
|
}
|
2009-08-16 07:49:15 -06:00
|
|
|
|
2009-11-08 09:56:41 -07:00
|
|
|
// Set capture piece
|
2016-09-03 10:14:01 -06:00
|
|
|
st->capturedPiece = captured;
|
2009-11-08 09:56:41 -07:00
|
|
|
|
2009-08-17 01:57:09 -06:00
|
|
|
// Update the key with the final value
|
2011-12-25 03:50:59 -07:00
|
|
|
st->key = k;
|
2009-08-17 01:57:09 -06:00
|
|
|
|
2015-02-15 04:20:47 -07:00
|
|
|
// Calculate checkers bitboard (if move gives check)
|
2015-08-04 01:00:52 -06:00
|
|
|
st->checkersBB = givesCheck ? attackers_to(square<KING>(them)) & pieces(us) : 0;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2012-01-12 11:31:18 -07:00
|
|
|
sideToMove = ~sideToMove;
|
2009-08-20 09:30:34 -06:00
|
|
|
|
2016-08-27 02:05:42 -06:00
|
|
|
// Update king attacks used for fast check detection
|
|
|
|
set_check_info(st);
|
2016-07-03 02:35:44 -06:00
|
|
|
|
2019-05-15 02:22:21 -06:00
|
|
|
// Calculate the repetition info. It is the ply distance from the previous
|
|
|
|
// occurrence of the same position, negative in the 3-fold case, or zero
|
|
|
|
// if the position was not repeated.
|
|
|
|
st->repetition = 0;
|
|
|
|
int end = std::min(st->rule50, st->pliesFromNull);
|
|
|
|
if (end >= 4)
|
|
|
|
{
|
|
|
|
StateInfo* stp = st->previous->previous;
|
2019-08-14 14:15:41 -06:00
|
|
|
for (int i = 4; i <= end; i += 2)
|
2019-05-15 02:22:21 -06:00
|
|
|
{
|
|
|
|
stp = stp->previous->previous;
|
|
|
|
if (stp->key == st->key)
|
|
|
|
{
|
|
|
|
st->repetition = stp->repetition ? -i : i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-10-16 16:56:25 -06:00
|
|
|
assert(pos_is_ok());
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2009-02-12 04:43:14 -07:00
|
|
|
|
2011-10-30 04:26:06 -06:00
|
|
|
/// Position::undo_move() unmakes a move. When it returns, the position should
|
|
|
|
/// be restored to exactly the same state as before the move was made.
|
|
|
|
|
|
|
|
void Position::undo_move(Move m) {
|
|
|
|
|
|
|
|
assert(is_ok(m));
|
|
|
|
|
2012-01-12 11:31:18 -07:00
|
|
|
sideToMove = ~sideToMove;
|
2011-10-30 04:26:06 -06:00
|
|
|
|
2012-01-12 11:31:18 -07:00
|
|
|
Color us = sideToMove;
|
2012-01-01 08:00:00 -07:00
|
|
|
Square from = from_sq(m);
|
|
|
|
Square to = to_sq(m);
|
2016-09-03 10:14:01 -06:00
|
|
|
Piece pc = piece_on(to);
|
2011-10-30 04:26:06 -06:00
|
|
|
|
2013-12-01 02:25:10 -07:00
|
|
|
assert(empty(from) || type_of(m) == CASTLING);
|
2016-09-03 10:14:01 -06:00
|
|
|
assert(type_of(st->capturedPiece) != KING);
|
2011-10-30 04:26:06 -06:00
|
|
|
|
2012-06-24 03:08:16 -06:00
|
|
|
if (type_of(m) == PROMOTION)
|
2011-10-30 04:26:06 -06:00
|
|
|
{
|
|
|
|
assert(relative_rank(us, to) == RANK_8);
|
2016-09-03 10:14:01 -06:00
|
|
|
assert(type_of(pc) == promotion_type(m));
|
|
|
|
assert(type_of(pc) >= KNIGHT && type_of(pc) <= QUEEN);
|
2011-10-30 04:26:06 -06:00
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
remove_piece(pc, to);
|
|
|
|
pc = make_piece(us, PAWN);
|
|
|
|
put_piece(pc, to);
|
2011-10-30 04:26:06 -06:00
|
|
|
}
|
|
|
|
|
2013-12-01 02:25:10 -07:00
|
|
|
if (type_of(m) == CASTLING)
|
2013-01-27 10:48:27 -07:00
|
|
|
{
|
2014-03-13 05:53:03 -06:00
|
|
|
Square rfrom, rto;
|
2015-02-08 05:21:50 -07:00
|
|
|
do_castling<false>(us, from, to, rfrom, rto);
|
2013-01-27 10:48:27 -07:00
|
|
|
}
|
|
|
|
else
|
2011-10-30 04:26:06 -06:00
|
|
|
{
|
2016-09-03 10:14:01 -06:00
|
|
|
move_piece(pc, to, from); // Put the piece back at the source square
|
2011-10-30 04:26:06 -06:00
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
if (st->capturedPiece)
|
2011-10-30 04:26:06 -06:00
|
|
|
{
|
2014-03-15 04:21:47 -06:00
|
|
|
Square capsq = to;
|
2011-10-30 04:26:06 -06:00
|
|
|
|
2014-03-15 04:21:47 -06:00
|
|
|
if (type_of(m) == ENPASSANT)
|
|
|
|
{
|
|
|
|
capsq -= pawn_push(us);
|
2011-10-30 04:26:06 -06:00
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
assert(type_of(pc) == PAWN);
|
2014-03-15 04:21:47 -06:00
|
|
|
assert(to == st->previous->epSquare);
|
|
|
|
assert(relative_rank(us, to) == RANK_6);
|
|
|
|
assert(piece_on(capsq) == NO_PIECE);
|
2016-09-03 10:14:01 -06:00
|
|
|
assert(st->capturedPiece == make_piece(~us, PAWN));
|
2014-03-15 04:21:47 -06:00
|
|
|
}
|
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
put_piece(st->capturedPiece, capsq); // Restore the captured piece
|
2014-03-15 04:21:47 -06:00
|
|
|
}
|
2011-10-30 04:26:06 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// Finally point our state pointer back to the previous state
|
|
|
|
st = st->previous;
|
2013-10-02 22:01:38 -06:00
|
|
|
--gamePly;
|
2011-10-30 04:26:06 -06:00
|
|
|
|
|
|
|
assert(pos_is_ok());
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-12-01 02:25:10 -07:00
|
|
|
/// Position::do_castling() is a helper used to do/undo a castling move. This
|
2016-09-03 10:14:01 -06:00
|
|
|
/// is a bit tricky in Chess960 where from/to squares can overlap.
|
2014-03-13 05:53:03 -06:00
|
|
|
template<bool Do>
|
2015-02-08 05:21:50 -07:00
|
|
|
void Position::do_castling(Color us, Square from, Square& to, Square& rfrom, Square& rto) {
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2014-03-13 05:53:03 -06:00
|
|
|
bool kingSide = to > from;
|
|
|
|
rfrom = to; // Castling is encoded as "king captures friendly rook"
|
2015-02-08 05:21:50 -07:00
|
|
|
rto = relative_square(us, kingSide ? SQ_F1 : SQ_D1);
|
|
|
|
to = relative_square(us, kingSide ? SQ_G1 : SQ_C1);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-08-03 06:42:58 -06:00
|
|
|
// Remove both pieces first since squares could overlap in Chess960
|
2016-09-03 10:14:01 -06:00
|
|
|
remove_piece(make_piece(us, KING), Do ? from : to);
|
|
|
|
remove_piece(make_piece(us, ROOK), Do ? rfrom : rto);
|
2014-03-13 05:53:03 -06:00
|
|
|
board[Do ? from : to] = board[Do ? rfrom : rto] = NO_PIECE; // Since remove_piece doesn't do it for us
|
2016-09-03 10:14:01 -06:00
|
|
|
put_piece(make_piece(us, KING), Do ? to : from);
|
|
|
|
put_piece(make_piece(us, ROOK), Do ? rto : rfrom);
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-01-27 03:45:01 -07:00
|
|
|
/// Position::do(undo)_null_move() is used to do(undo) a "null move": It flips
|
|
|
|
/// the side to move without executing any move on the board.
|
2008-10-25 02:06:52 -06:00
|
|
|
|
2013-01-27 03:45:01 -07:00
|
|
|
void Position::do_null_move(StateInfo& newSt) {
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2013-01-27 03:45:01 -07:00
|
|
|
assert(!checkers());
|
2015-02-07 11:34:24 -07:00
|
|
|
assert(&newSt != st);
|
2011-10-29 10:49:20 -06:00
|
|
|
|
2015-02-07 11:34:24 -07:00
|
|
|
std::memcpy(&newSt, st, sizeof(StateInfo));
|
2013-01-27 03:45:01 -07:00
|
|
|
newSt.previous = st;
|
|
|
|
st = &newSt;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-01-27 03:45:01 -07:00
|
|
|
if (st->epSquare != SQ_NONE)
|
2011-10-29 10:49:20 -06:00
|
|
|
{
|
2013-01-27 03:45:01 -07:00
|
|
|
st->key ^= Zobrist::enpassant[file_of(st->epSquare)];
|
2011-10-29 10:49:20 -06:00
|
|
|
st->epSquare = SQ_NONE;
|
|
|
|
}
|
2011-07-16 03:42:27 -06:00
|
|
|
|
2013-01-27 03:45:01 -07:00
|
|
|
st->key ^= Zobrist::side;
|
2015-02-07 11:13:41 -07:00
|
|
|
prefetch(TT.first_entry(st->key));
|
2013-01-27 03:45:01 -07:00
|
|
|
|
2013-10-02 22:01:38 -06:00
|
|
|
++st->rule50;
|
2013-01-27 03:45:01 -07:00
|
|
|
st->pliesFromNull = 0;
|
|
|
|
|
|
|
|
sideToMove = ~sideToMove;
|
|
|
|
|
2016-08-27 02:05:42 -06:00
|
|
|
set_check_info(st);
|
2016-07-03 02:35:44 -06:00
|
|
|
|
2019-05-15 02:22:21 -06:00
|
|
|
st->repetition = 0;
|
|
|
|
|
2011-10-16 16:56:25 -06:00
|
|
|
assert(pos_is_ok());
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2013-01-27 03:45:01 -07:00
|
|
|
void Position::undo_null_move() {
|
|
|
|
|
|
|
|
assert(!checkers());
|
|
|
|
|
|
|
|
st = st->previous;
|
|
|
|
sideToMove = ~sideToMove;
|
|
|
|
}
|
2011-10-29 10:49:20 -06:00
|
|
|
|
2014-10-03 22:07:55 -06:00
|
|
|
|
2014-11-18 15:39:17 -07:00
|
|
|
/// Position::key_after() computes the new hash key after the given move. Needed
|
2014-10-03 22:07:55 -06:00
|
|
|
/// for speculative prefetch. It doesn't recognize special moves like castling,
|
|
|
|
/// en-passant and promotions.
|
|
|
|
|
|
|
|
Key Position::key_after(Move m) const {
|
|
|
|
|
|
|
|
Square from = from_sq(m);
|
|
|
|
Square to = to_sq(m);
|
2016-09-03 10:14:01 -06:00
|
|
|
Piece pc = piece_on(from);
|
|
|
|
Piece captured = piece_on(to);
|
2014-10-03 22:07:55 -06:00
|
|
|
Key k = st->key ^ Zobrist::side;
|
|
|
|
|
|
|
|
if (captured)
|
2016-09-03 10:14:01 -06:00
|
|
|
k ^= Zobrist::psq[captured][to];
|
2014-10-03 22:07:55 -06:00
|
|
|
|
2016-09-03 10:14:01 -06:00
|
|
|
return k ^ Zobrist::psq[pc][to] ^ Zobrist::psq[pc][from];
|
2014-10-02 15:19:14 -06:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2014-10-03 22:07:55 -06:00
|
|
|
|
2016-10-06 11:55:10 -06:00
|
|
|
/// Position::see_ge (Static Exchange Evaluation Greater or Equal) tests if the
|
2017-06-24 04:36:07 -06:00
|
|
|
/// SEE value of move is greater or equal to the given threshold. We'll use an
|
2016-10-06 11:55:10 -06:00
|
|
|
/// algorithm similar to alpha-beta pruning with a null window.
|
2008-12-09 03:20:47 -07:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
bool Position::see_ge(Move m, Value threshold) const {
|
2009-07-11 02:54:30 -06:00
|
|
|
|
2011-10-03 02:56:49 -06:00
|
|
|
assert(is_ok(m));
|
2009-07-11 02:54:30 -06:00
|
|
|
|
2017-08-25 07:15:26 -06:00
|
|
|
// Only deal with normal moves, assume others pass a simple see
|
|
|
|
if (type_of(m) != NORMAL)
|
2017-06-24 04:36:07 -06:00
|
|
|
return VALUE_ZERO >= threshold;
|
2016-10-06 11:55:10 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
Bitboard stmAttackers;
|
2016-10-06 11:55:10 -06:00
|
|
|
Square from = from_sq(m), to = to_sq(m);
|
|
|
|
PieceType nextVictim = type_of(piece_on(from));
|
2018-02-23 14:02:10 -07:00
|
|
|
Color us = color_of(piece_on(from));
|
|
|
|
Color stm = ~us; // First consider opponent's move
|
|
|
|
Value balance; // Values of the pieces taken by us minus opponent's ones
|
2013-07-20 11:11:03 -06:00
|
|
|
|
2017-11-08 10:21:46 -07:00
|
|
|
// The opponent may be able to recapture so this is the best result
|
|
|
|
// we can hope for.
|
|
|
|
balance = PieceValue[MG][piece_on(to)] - threshold;
|
2008-12-21 00:29:46 -07:00
|
|
|
|
2017-11-08 10:21:46 -07:00
|
|
|
if (balance < VALUE_ZERO)
|
2016-10-06 11:55:10 -06:00
|
|
|
return false;
|
2008-12-09 03:20:47 -07:00
|
|
|
|
2017-11-08 10:21:46 -07:00
|
|
|
// Now assume the worst possible result: that the opponent can
|
|
|
|
// capture our piece for free.
|
2016-10-06 11:55:10 -06:00
|
|
|
balance -= PieceValue[MG][nextVictim];
|
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
// If it is enough (like in PxQ) then return immediately. Note that
|
|
|
|
// in case nextVictim == KING we always return here, this is ok
|
|
|
|
// if the given move is legal.
|
|
|
|
if (balance >= VALUE_ZERO)
|
2016-10-06 11:55:10 -06:00
|
|
|
return true;
|
2008-10-25 13:44:10 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
// Find all attackers to the destination square, with the moving piece
|
|
|
|
// removed, but possibly an X-ray attacker added behind it.
|
|
|
|
Bitboard occupied = pieces() ^ from ^ to;
|
2016-10-06 11:55:10 -06:00
|
|
|
Bitboard attackers = attackers_to(to, occupied) & occupied;
|
2016-09-12 00:47:19 -06:00
|
|
|
|
2016-10-06 11:55:10 -06:00
|
|
|
while (true)
|
|
|
|
{
|
|
|
|
stmAttackers = attackers & pieces(stm);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
// Don't allow pinned pieces to attack (except the king) as long as
|
Change pinning logic in Static Exchange Evaluation (SEE)
This changes 2 parts with regards to static exchange evaluation.
Currently, we do not allow pinned pieces to recapture if *all* opponent
pinners are still in their starting squares. This changes that to having
a less strict requirement, checking if *any* pinners are still in their
starting square. This makes our SEE give more respect to the pinning
side with regards to exchanges, which makes sense because it helps our
search explore more tactical options.
Furthermore, we change the logic for saving pinners into our state
variable when computing slider_blockers. We will include double pinners,
where two sliders may be looking at the same blocker, a similar concept
to our mobility calculation for sliders in our evaluation section.
Interestingly, I think SEE is the only place where the pinners bitboard
is actually used, so as far as I know there are no other side effects
to this change.
An example and some insights:
White Bf2, Kg1
Black Qe3, Bc5
The move Qg3 will be given the correct value of 0. (Previously < 0)
The move Qd4 will be incorrectly given a value of 0. (Previously < 0)
It seems the tradeoff in search is worth it. Qd4 will likely be pruned
soon by something like probcut anyway, while Qg3 could help us spot
tactics at an earlier depth.
STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 62162 W: 13879 L: 13408 D: 34875
http://tests.stockfishchess.org/tests/view/5c4ba1a70ebc593af5d49c55
LTC: (Thanks to @alayant)
LLR: 3.40 (-2.94,2.94) [0.00,3.50]
Total: 140285 W: 23416 L: 22825 D: 94044
http://tests.stockfishchess.org/tests/view/5c4bcfba0ebc593af5d49ea8
Bench: 3937213
2019-01-24 23:37:03 -07:00
|
|
|
// any pinners are on their original square.
|
|
|
|
if (st->pinners[~stm] & occupied)
|
2016-10-06 11:55:10 -06:00
|
|
|
stmAttackers &= ~st->blockersForKing[stm];
|
2012-09-01 03:45:14 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
// If stm has no more attackers then give up: stm loses
|
2016-10-06 11:55:10 -06:00
|
|
|
if (!stmAttackers)
|
2017-11-08 10:21:46 -07:00
|
|
|
break;
|
2012-09-01 03:45:14 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
// Locate and remove the next least valuable attacker, and add to
|
|
|
|
// the bitboard 'attackers' the possibly X-ray attackers behind it.
|
2016-09-19 00:21:41 -06:00
|
|
|
nextVictim = min_attacker<PAWN>(byTypeBB, to, stmAttackers, occupied, attackers);
|
2016-09-21 01:32:00 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
stm = ~stm; // Switch side to move
|
2013-07-20 07:26:52 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
// Negamax the balance with alpha = balance, beta = balance+1 and
|
|
|
|
// add nextVictim's value.
|
|
|
|
//
|
|
|
|
// (balance, balance+1) -> (-balance-1, -balance)
|
|
|
|
//
|
|
|
|
assert(balance < VALUE_ZERO);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
balance = -balance - 1 - PieceValue[MG][nextVictim];
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-02-23 14:02:10 -07:00
|
|
|
// If balance is still non-negative after giving away nextVictim then we
|
|
|
|
// win. The only thing to be careful about it is that we should revert
|
|
|
|
// stm if we captured with the king when the opponent still has attackers.
|
|
|
|
if (balance >= VALUE_ZERO)
|
|
|
|
{
|
|
|
|
if (nextVictim == KING && (attackers & pieces(stm)))
|
|
|
|
stm = ~stm;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
assert(nextVictim != KING);
|
2016-10-06 11:55:10 -06:00
|
|
|
}
|
2018-02-23 14:02:10 -07:00
|
|
|
return us != stm; // We break the above loop when stm loses
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-03-17 10:42:29 -06:00
|
|
|
/// Position::is_draw() tests whether the position is drawn by 50-move rule
|
|
|
|
/// or by repetition. It does not detect stalemates.
|
2013-12-03 03:37:29 -07:00
|
|
|
|
Threefold repetition detection
Implement a threefold repetition detection. Below are the examples of
problems fixed by this change.
Loosing move in a drawn position.
position fen 8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - 0 1 moves a1a2 a7a8 a2a1
The old code suggested a loosing move "bestmove a8a7", the new code suggests "bestmove a8b7" leading to a draw.
Incorrect evaluation (happened in a real game in TCEC Season 9).
position fen 4rbkr/1q3pp1/b3pn2/7p/1pN5/1P1BBP1P/P1R2QP1/3R2K1 w - - 5 31 moves e3d4 h8h6 d4e3
The old code evaluated it as "cp 0", the new code evaluation is around "cp -50" which is adequate.
Brings 0.5-1 ELO gain. Passes [-3.00,1.00].
STC: http://tests.stockfishchess.org/tests/view/584ece040ebc5903140c5aea
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 47744 W: 8537 L: 8461 D: 30746
LTC: http://tests.stockfishchess.org/tests/view/584f134d0ebc5903140c5b37
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 36775 W: 4739 L: 4639 D: 27397
Patch has been rewritten into current form for simplification and
logic slightly changed so that return a draw score if the position
repeats once earlier but after or at the root, or repeats twice
strictly before the root. In its original form, repetition at root
was not returned as an immediate draw.
After retestimng testing both version with SPRT[-3, 1], both passed
succesfully, but this version was chosen becuase more natural. There is
an argument about MultiPV in which an extended draw at root may be sensible.
See discussion here:
https://github.com/official-stockfish/Stockfish/pull/925
For documentation, current version passed both at STC and LTC:
STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 51562 W: 9314 L: 9245 D: 33003
LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 115663 W: 14904 L: 14906 D: 85853
bench: 5468995
2016-12-12 08:04:16 -07:00
|
|
|
bool Position::is_draw(int ply) const {
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2012-12-25 09:59:35 -07:00
|
|
|
if (st->rule50 > 99 && (!checkers() || MoveList<LEGAL>(*this).size()))
|
2008-10-25 02:06:52 -06:00
|
|
|
return true;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2019-05-15 02:22:21 -06:00
|
|
|
// Return a draw score if a position repeats once earlier but strictly
|
|
|
|
// after the root, or repeats twice before or at the root.
|
|
|
|
if (st->repetition && st->repetition < ply)
|
|
|
|
return true;
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-04-18 10:38:38 -06:00
|
|
|
// Position::has_repeated() tests whether there has been at least one repetition
|
|
|
|
// of positions since the last capture or pawn move.
|
|
|
|
|
|
|
|
bool Position::has_repeated() const {
|
|
|
|
|
|
|
|
StateInfo* stc = st;
|
2019-05-15 02:22:21 -06:00
|
|
|
int end = std::min(st->rule50, st->pliesFromNull);
|
|
|
|
while (end-- >= 4)
|
2018-04-18 10:38:38 -06:00
|
|
|
{
|
2019-05-15 02:22:21 -06:00
|
|
|
if (stc->repetition)
|
|
|
|
return true;
|
2018-04-18 10:38:38 -06:00
|
|
|
|
|
|
|
stc = stc->previous;
|
|
|
|
}
|
2019-05-15 02:22:21 -06:00
|
|
|
return false;
|
2018-04-18 10:38:38 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
/// Position::has_game_cycle() tests if the position has a move which draws by repetition,
|
|
|
|
/// or an earlier position has a move that directly reaches the current position.
|
|
|
|
|
|
|
|
bool Position::has_game_cycle(int ply) const {
|
|
|
|
|
2018-05-21 01:37:16 -06:00
|
|
|
int j;
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
|
|
|
|
int end = std::min(st->rule50, st->pliesFromNull);
|
|
|
|
|
|
|
|
if (end < 3)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
Key originalKey = st->key;
|
|
|
|
StateInfo* stp = st->previous;
|
|
|
|
|
|
|
|
for (int i = 3; i <= end; i += 2)
|
|
|
|
{
|
2018-05-21 01:37:16 -06:00
|
|
|
stp = stp->previous->previous;
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
|
2018-05-21 01:37:16 -06:00
|
|
|
Key moveKey = originalKey ^ stp->key;
|
|
|
|
if ( (j = H1(moveKey), cuckoo[j] == moveKey)
|
|
|
|
|| (j = H2(moveKey), cuckoo[j] == moveKey))
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
{
|
2018-05-21 01:37:16 -06:00
|
|
|
Move move = cuckooMove[j];
|
2018-06-02 09:41:37 -06:00
|
|
|
Square s1 = from_sq(move);
|
|
|
|
Square s2 = to_sq(move);
|
2018-05-21 01:37:16 -06:00
|
|
|
|
2018-06-02 09:41:37 -06:00
|
|
|
if (!(between_bb(s1, s2) & pieces()))
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
{
|
2018-05-21 01:37:16 -06:00
|
|
|
if (ply > i)
|
|
|
|
return true;
|
|
|
|
|
2019-05-02 11:36:25 -06:00
|
|
|
// For nodes before or at the root, check that the move is a
|
|
|
|
// repetition rather than a move to the current position.
|
|
|
|
// In the cuckoo table, both moves Rc1c5 and Rc5c1 are stored in
|
|
|
|
// the same location, so we have to select which square to check.
|
2019-04-14 06:50:37 -06:00
|
|
|
if (color_of(piece_on(empty(s1) ? s2 : s1)) != side_to_move())
|
|
|
|
continue;
|
|
|
|
|
2018-05-21 01:37:16 -06:00
|
|
|
// For repetitions before or at the root, require one more
|
2019-05-15 02:22:21 -06:00
|
|
|
if (stp->repetition)
|
|
|
|
return true;
|
Use cycle detection to bound search value
A position which has a move which draws by repetition, or which could have
been reached from an earlier position in the game tree, is considered to be
at least a draw for the side to move.
Cycle detection algorithm by Marcel van Kervink:
https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf
----------------------------
How does the algorithm work in practice? The algorithm is an efficient
method to detect if the side to move has a drawing move, without doing any
move generation, thus possibly giving a cheap cutoffThe most interesting
conditions are both on line 1195:
```
if ( originalKey == (progressKey ^ stp->key)
|| progressKey == Zobrist::side)
```
This uses the position keys as a sort-of Bloom filter, to avoid the expensive
checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1.
The XOR of this position's key with the starting position gives their difference,
which can be used to look up black's repeating move (Ng8). But that look-up is
expensive, so line 1195 checks that the white pieces are on their original squares.
This is the subtlest part of the algorithm, but the basic idea in the above game
is there are 4 positions (starting position and the one after each move). An XOR
of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of
the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But
since the difference in each pair is the location of the white knight those keys
are "identical" (not quite because while there are 4 keys the the side to move
changed 3 times, so the keys differ by Zobrist::side). The loop containing line
1195 does this pair-wise XOR-ing.
Continuing the example, after line 1195 determines that the white pieces are
back where they started we still need to make sure the changes in the black
pieces represents a legal move. This is done by looking up the "moveKey" to
see if it corresponds to possible move, and that there are no pieces blocking
its way. There is the additional complication that, to match the behavior of
is_draw(), if the repetition is not inside the search tree then there must be
an additional repetition in the game history. Since a position can have more
than one upcoming repetition a simple count does not suffice. So there is a
search loop ending on line 1215.
On the other hand, the "no-progress' is the same thing but offset by 1 ply.
I like the concept but think it currently has minimal or negative benefit,
and I'd be happy to remove it if that would get the patch accepted. This
will not, however, save many lines of code.
-----------------------------
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 36430 W: 7446 L: 7150 D: 21834
http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12998 W: 2045 L: 1876 D: 9077
http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c
How could we continue after the patch:
• The code in search() that checks for cycles has numerous possible variants.
Perhaps the check need could be done in qsearch() too.
• The biggest improvement would be to get "no progress" to be of actual benefit,
and it would be helpful understand why it (probably) isn't. Perhaps there is an
interaction with the transposition table or the (fantastically complex) tree
search. Perhaps this would be hard to fix, but there may be a simple oversight.
Closes https://github.com/official-stockfish/Stockfish/pull/1575
Bench: 4550412
2018-05-16 14:47:41 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-04-02 11:21:17 -06:00
|
|
|
/// Position::flip() flips position with the white and black sides reversed. This
|
2013-12-02 11:04:09 -07:00
|
|
|
/// is only useful for debugging e.g. for finding evaluation symmetry bugs.
|
2011-04-26 03:19:57 -06:00
|
|
|
|
2012-04-02 11:21:17 -06:00
|
|
|
void Position::flip() {
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-08-05 03:06:23 -06:00
|
|
|
string f, token;
|
|
|
|
std::stringstream ss(fen());
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2014-04-06 02:50:27 -06:00
|
|
|
for (Rank r = RANK_8; r >= RANK_1; --r) // Piece placement
|
2013-08-05 03:06:23 -06:00
|
|
|
{
|
2014-04-06 02:50:27 -06:00
|
|
|
std::getline(ss, token, r > RANK_1 ? '/' : ' ');
|
2013-08-05 05:25:21 -06:00
|
|
|
f.insert(0, token + (f.empty() ? " " : "/"));
|
2013-08-05 03:06:23 -06:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-08-05 05:25:21 -06:00
|
|
|
ss >> token; // Active color
|
|
|
|
f += (token == "w" ? "B " : "W "); // Will be lowercased later
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-08-05 05:25:21 -06:00
|
|
|
ss >> token; // Castling availability
|
2013-08-05 03:06:23 -06:00
|
|
|
f += token + " ";
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2015-01-21 03:33:53 -07:00
|
|
|
std::transform(f.begin(), f.end(), f.begin(),
|
|
|
|
[](char c) { return char(islower(c) ? toupper(c) : tolower(c)); });
|
2013-08-05 05:25:21 -06:00
|
|
|
|
|
|
|
ss >> token; // En passant square
|
2013-08-05 03:06:23 -06:00
|
|
|
f += (token == "-" ? token : token.replace(1, 1, token[1] == '3' ? "6" : "3"));
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2013-08-05 05:25:21 -06:00
|
|
|
std::getline(ss, token); // Half and full moves
|
2013-08-05 03:06:23 -06:00
|
|
|
f += token;
|
2012-04-09 04:35:47 -06:00
|
|
|
|
2016-04-11 08:45:36 -06:00
|
|
|
set(f, is_chess960(), st, this_thread());
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2011-10-16 16:56:25 -06:00
|
|
|
assert(pos_is_ok());
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
/// Position::pos_is_ok() performs some consistency checks for the
|
|
|
|
/// position object and raises an asserts if something wrong is detected.
|
2008-08-31 23:59:13 -06:00
|
|
|
/// This is meant to be helpful when debugging.
|
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
bool Position::pos_is_ok() const {
|
2015-02-07 11:34:24 -07:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr bool Fast = true; // Quick (default) or full check?
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
if ( (sideToMove != WHITE && sideToMove != BLACK)
|
|
|
|
|| piece_on(square<KING>(WHITE)) != W_KING
|
|
|
|
|| piece_on(square<KING>(BLACK)) != B_KING
|
|
|
|
|| ( ep_square() != SQ_NONE
|
|
|
|
&& relative_rank(sideToMove, ep_square()) != RANK_6))
|
|
|
|
assert(0 && "pos_is_ok: Default");
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
if (Fast)
|
|
|
|
return true;
|
2008-09-23 16:32:53 -06:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
if ( pieceCount[W_KING] != 1
|
|
|
|
|| pieceCount[B_KING] != 1
|
|
|
|
|| attackers_to(square<KING>(~sideToMove)) & pieces(sideToMove))
|
|
|
|
assert(0 && "pos_is_ok: Kings");
|
2014-03-14 02:43:19 -06:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
if ( (pieces(PAWN) & (Rank1BB | Rank8BB))
|
|
|
|
|| pieceCount[W_PAWN] > 8
|
|
|
|
|| pieceCount[B_PAWN] > 8)
|
|
|
|
assert(0 && "pos_is_ok: Pawns");
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
if ( (pieces(WHITE) & pieces(BLACK))
|
|
|
|
|| (pieces(WHITE) | pieces(BLACK)) != pieces()
|
|
|
|
|| popcount(pieces(WHITE)) > 16
|
|
|
|
|| popcount(pieces(BLACK)) > 16)
|
|
|
|
assert(0 && "pos_is_ok: Bitboards");
|
2010-01-24 08:09:32 -07:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
for (PieceType p1 = PAWN; p1 <= KING; ++p1)
|
|
|
|
for (PieceType p2 = PAWN; p2 <= KING; ++p2)
|
|
|
|
if (p1 != p2 && (pieces(p1) & pieces(p2)))
|
|
|
|
assert(0 && "pos_is_ok: Bitboards");
|
2011-06-27 09:06:15 -06:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
StateInfo si = *st;
|
|
|
|
set_state(&si);
|
|
|
|
if (std::memcmp(&si, st, sizeof(StateInfo)))
|
|
|
|
assert(0 && "pos_is_ok: State");
|
2016-09-03 10:14:01 -06:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
for (Piece pc : Pieces)
|
|
|
|
{
|
|
|
|
if ( pieceCount[pc] != popcount(pieces(color_of(pc), type_of(pc)))
|
|
|
|
|| pieceCount[pc] != std::count(board, board + SQUARE_NB, pc))
|
|
|
|
assert(0 && "pos_is_ok: Pieces");
|
2015-02-07 06:34:35 -07:00
|
|
|
|
2017-06-24 04:36:07 -06:00
|
|
|
for (int i = 0; i < pieceCount[pc]; ++i)
|
|
|
|
if (board[pieceList[pc][i]] != pc || index[pieceList[pc][i]] != i)
|
|
|
|
assert(0 && "pos_is_ok: Index");
|
2015-02-07 06:34:35 -07:00
|
|
|
}
|
2010-01-24 08:09:32 -07:00
|
|
|
|
2019-07-16 06:08:58 -06:00
|
|
|
for (Color c : { WHITE, BLACK })
|
|
|
|
for (CastlingSide s : {KING_SIDE, QUEEN_SIDE})
|
2017-06-24 04:36:07 -06:00
|
|
|
{
|
|
|
|
if (!can_castle(c | s))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if ( piece_on(castlingRookSquare[c | s]) != make_piece(c, ROOK)
|
|
|
|
|| castlingRightsMask[castlingRookSquare[c | s]] != (c | s)
|
|
|
|
|| (castlingRightsMask[square<KING>(c)] & (c | s)) != (c | s))
|
|
|
|
assert(0 && "pos_is_ok: Castling");
|
|
|
|
}
|
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
return true;
|
|
|
|
}
|