pb00067andDisservin d2d046c2a4 Improve stalemate detection during search
Currently SF’s quiescence search like most alpha-beta based engines
doesn’t verify for stalemate because doing it each leaf position is to
expensive and costs elo. However in certain positions this creates a
blindspot for SF, not recognizing soon enough that the opponent can
reach a stalemate by sacrifycing his last mobile heavy piece(s). This
tactical motif & it’s measure are similar to zugzwang & verification
search: the measure itself does not gain elo, but prevents SF from
loosing/drawing games in an awkward way.

The fix consists of 3 measures:

1. Make qsearch verify for stalemate on transitions to pure KP-material
   for the side to move with our last Rook/Queen just been captured. In
    fact this is the scenario where stalemate happens with highest
    frequency. The stalemate-verification itself is optimized by merely
    checking for pawn pushes & king mobility (captures were already
    tried by qssearch)

2. Another culprit for the issue figured out to be SEE based pruning for
   checks in step 14. Here often the move forcing the stalemate (or
   forcing the opponent to not retake) get pruned away and it need to
   much time to reach enough depth. To encounter this we verify
   following conditions:

-   a) side to move is happy with a draw (alpha < 0)
-   b) we are about to sacrify our last heavy & unique mobile piece in
    this position.
-   c) this piece doesn’t move away from our kingring giving the king a
    new square to move.
     When all 3 conditions meet we don’t prune the move, because there
     is a good chance that capturing the piece means stalemate.

3. Store terminal nodes (mates & stalemates) in TT with higher depth
   than searched depth. This prevents SF from:
- reanalyzing the node  (=trying to generate legal moves) in vain at
  each iterative deepening step.
- overwriting an already correct draw-evaluation from a previous shallow
  normal search by a qsearch which doesn’t recognize stalemate and might
  store a verry erratic evaluation.
 This is due to the 4 constant in the TT-overwrite condition: d -
 DEPTH_ENTRY_OFFSET + 2 * pv > depth8 – 4 which allows qs to override
 entries made by normal searches with depth <=4.
This 3hrd measure however is not essential for fixing the issue, but
tests (one of vdv & one  of mine) seem to suggest that this measure
brings some small benefit.

Another other position where SF benefits from this fix is for instance
Position FEN 8/8/8/1B6/6p1/8/3K1Ppp/3N2kr w - - 0 1 bm f4 +M9

P.S.: Also this issue higly depends on the used net, how good the net is
at evaluate such mobility restricted positions. SF16 was pretty good in
solving 2rr4/5pBk/PqP3p1/1N3pPp/1PQ1bP1P/8/3R4/R4K2 b - - 0 40 bm Rxc6
(< 1 second) while SF16_1 with introduction of the dual net needs about
1,5 minutes and SF17.1 requires 3 minutes to find the drawing move Rxc6.

P.S.2: Using more threads produces indeterminism & using high hash
pressure makes SF reevaluate explored positions more often which makes
it more likely to solve the position. To have stable meaningful results
I tested therfore with one single thread and low hash pressure.

Preliminary LTC test at 30k games
https://tests.stockfishchess.org/tests/view/67ece7a931d7cf8afdc44e18 Elo: 0.04 ± 2.0 (95%) LOS: 51.7%
Total: 24416 W: 6226 L: 6223 D: 11967
Ptnml(0-2): 12, 2497, 7185, 2504, 10
nElo: 0.09 ± 4.4 (95%) PairsRatio: 1.00

Passed LTC no-regression sprt
https://tests.stockfishchess.org/tests/view/67ee8e4631d7cf8afdc452fb
LLR: 2.94 (-2.94,2.94) <-1.75,0.25>
Total: 401556 W: 101612 L: 101776 D: 198168
Ptnml(0-2): 152, 42241, 116170, 42049, 166

closes https://github.com/official-stockfish/Stockfish/pull/5983
fixes https://github.com/official-stockfish/Stockfish/issues/5899

Bench: 1721673
2025-04-18 14:32:26 +02:00
2025-03-21 11:03:31 +01:00
2023-10-22 16:06:27 +02:00
2024-09-17 20:24:17 +02:00
2025-04-18 14:32:19 +02:00
2023-03-05 16:16:16 +01:00
2023-10-08 07:38:13 +02:00
2024-12-08 19:56:01 +01:00

Stockfish

Stockfish

A free and strong UCI chess engine.
Explore Stockfish docs »

Report bug · Open a discussion · Discord · Blog

Build License
Release Commits
Website Fishtest Discord

Overview

Stockfish is a free and strong UCI chess engine derived from Glaurung 2.1 that analyzes chess positions and computes the optimal moves.

Stockfish does not include a graphical user interface (GUI) that is required to display a chessboard and to make it easy to input moves. These GUIs are developed independently from Stockfish and are available online. Read the documentation for your GUI of choice for information about how to use Stockfish with it.

See also the Stockfish documentation for further usage help.

Files

This distribution of Stockfish consists of the following files:

  • README.md, the file you are currently reading.

  • Copying.txt, a text file containing the GNU General Public License version 3.

  • AUTHORS, a text file with the list of authors for the project.

  • src, a subdirectory containing the full source code, including a Makefile that can be used to compile Stockfish on Unix-like systems.

  • a file with the .nnue extension, storing the neural network for the NNUE evaluation. Binary distributions will have this file embedded.

Contributing

See Contributing Guide.

Donating hardware

Improving Stockfish requires a massive amount of testing. You can donate your hardware resources by installing the Fishtest Worker and viewing the current tests on Fishtest.

Improving the code

In the chessprogramming wiki, many techniques used in Stockfish are explained with a lot of background information. The section on Stockfish describes many features and techniques used by Stockfish. However, it is generic rather than focused on Stockfish's precise implementation.

The engine testing is done on Fishtest. If you want to help improve Stockfish, please read this guideline first, where the basics of Stockfish development are explained.

Discussions about Stockfish take place these days mainly in the Stockfish Discord server. This is also the best place to ask questions about the codebase and how to improve it.

Compiling Stockfish

Stockfish has support for 32 or 64-bit CPUs, certain hardware instructions, big-endian machines such as Power PC, and other platforms.

On Unix-like systems, it should be easy to compile Stockfish directly from the source code with the included Makefile in the folder src. In general, it is recommended to run make help to see a list of make targets with corresponding descriptions. An example suitable for most Intel and AMD chips:

cd src
make -j profile-build

Detailed compilation instructions for all platforms can be found in our documentation. Our wiki also has information about the UCI commands supported by Stockfish.

Terms of use

Stockfish is free and distributed under the GNU General Public License version 3 (GPL v3). Essentially, this means you are free to do almost exactly what you want with the program, including distributing it among your friends, making it available for download from your website, selling it (either by itself or as part of some bigger software package), or using it as the starting point for a software project of your own.

The only real limitation is that whenever you distribute Stockfish in some way, you MUST always include the license and the full source code (or a pointer to where the source code can be found) to generate the exact binary you are distributing. If you make any changes to the source code, these changes must also be made available under GPL v3.

Acknowledgements

Stockfish uses neural networks trained on data provided by the Leela Chess Zero project, which is made available under the Open Database License (ODbL).

S
Description
No description provided
Readme Cite this repository
251 MiB
Languages
C++ 86.7%
Makefile 4.7%
Python 3.9%
Shell 2.8%
C 1.6%
Other 0.3%