GithubHelp home page GithubHelp logo

fairy-stockfish / fairy-stockfish Goto Github PK

View Code? Open in Web Editor NEW
562.0 31.0 180.0 11.47 MB

chess variant engine supporting Xiangqi, Shogi, Janggi, Makruk, S-Chess, Crazyhouse, Bughouse, and many more

Home Page: https://fairy-stockfish.github.io/

License: GNU General Public License v3.0

Makefile 2.06% C++ 87.24% Shell 1.63% Python 4.54% JavaScript 3.64% C 0.89%
stockfish uci usi shogi makruk crazyhouse fairy-stockfish chess-variants xboard xiangqi

fairy-stockfish's Introduction

Fairy-Stockfish

Overview

Build Status Build Status Build Status PyPI version NPM version

Fairy-Stockfish is a chess variant engine derived from Stockfish designed for the support of fairy chess variants and easy extensibility with more games. It can play various regional, historical, and modern chess variants as well as games with user-defined rules. For compatibility with graphical user interfaces it supports the UCI, UCCI, USI, UCI-cyclone, and CECP/XBoard protocols.

The goal of the project is to create an engine supporting a large variety of chess-like games, equipped with the powerful search of Stockfish. Despite its generality the playing strength is on a very high level in almost all supported variants. Due to its multi-protocol support Fairy-Stockfish works with almost any chess variant GUI.

Installation

You can download the Windows executable or Linux binary from the latest release or compile the program from source. The program comes without a graphical user interface, so you perhaps want to use it together with a compatible GUI, or play against it online at pychess, lishogi, or lichess. Read more about how to use Fairy-Stockfish in the wiki.

If you want to preview the functionality of Fairy-Stockfish before downloading, you can try it out on the Fairy-Stockfish playground in the browser.

Optional NNUE evaluation parameter files to improve playing strength for many variants are in the list of NNUE networks. For the regional variants Xiangqi, Janggi, and Makruk dedicated releases with built-in NNUE networks are available. See the wiki for more details on NNUE.

Contributing

If you like this project, please support its development via patreon or paypal, by contributing CPU time to the framework for testing of code improvements, or by contributing to the code or documentation. An introduction to the code base can be found in the wiki.

Supported games

The games currently supported besides chess are listed below. Fairy-Stockfish can also play user-defined variants loaded via a variant configuration file, see the file src/variants.ini and the wiki.

Regional and historical games

Chess variants

Shogi variants

Related games

Help

See the Fairy-Stockfish Wiki for more info, or if the required information is not available, open an issue or join our discord server.

Bindings

Besides the C++ engine, this project also includes bindings for other programming languages in order to be able to use it as a library for chess variants. They support move, SAN, and FEN generation, as well as checking of game end conditions for all variants supported by Fairy-Stockfish. Since the bindings are using the C++ code, they are very performant compared to libraries directly written in the respective target language.

Python

The python binding pyffish contributed by @gbtami is implemented in pyffish.cpp. It is e.g. used in the backend for the pychess server.

Javascript

The javascript binding ffish.js contributed by @QueensGambit is implemented in ffishjs.cpp. The compilation/binding to javascript is done using emscripten, see the readme.

Ports

WebAssembly

For in-browser use a port of Fairy-Stockfish to WebAssembly is available at npm. It is e.g. used for local analysis on pychess.org. Also see the Fairy-Stockfish WASM demo available at https://fairy-stockfish-nnue-wasm.vercel.app/.

Stockfish

Overview

Build Status Build Status

Stockfish is a free, powerful UCI chess engine derived from Glaurung 2.1. Stockfish is not a complete chess program and requires a UCI-compatible graphical user interface (GUI) (e.g. XBoard with PolyGlot, Scid, Cute Chess, eboard, Arena, Sigma Chess, Shredder, Chess Partner or Fritz) in order to be used comfortably. Read the documentation for your GUI of choice for information about how to use Stockfish with it.

The Stockfish engine features two evaluation functions for chess, the classical evaluation based on handcrafted terms, and the NNUE evaluation based on efficiently updatable neural networks. The classical evaluation runs efficiently on almost all CPU architectures, while the NNUE evaluation benefits from the vector intrinsics available on most CPUs (sse2, avx2, neon, or similar).

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.

The UCI protocol and available options

The Universal Chess Interface (UCI) is a standard protocol used to communicate with a chess engine, and is the recommended way to do so for typical graphical user interfaces (GUI) or chess tools. Stockfish implements the majority of it options as described in the UCI protocol.

Developers can see the default values for UCI options available in Stockfish by typing ./stockfish uci in a terminal, but the majority of users will typically see them and change them via a chess GUI. This is a list of available UCI options in Stockfish:

  • Threads

    The number of CPU threads used for searching a position. For best performance, set this equal to the number of CPU cores available.

  • Hash

    The size of the hash table in MB. It is recommended to set Hash after setting Threads.

  • Clear Hash

    Clear the hash table.

  • Ponder

    Let Stockfish ponder its next move while the opponent is thinking.

  • MultiPV

    Output the N best lines (principal variations, PVs) when searching. Leave at 1 for best performance.

  • Use NNUE

    Toggle between the NNUE and classical evaluation functions. If set to "true", the network parameters must be available to load from file (see also EvalFile), if they are not embedded in the binary.

  • EvalFile

    The name of the file of the NNUE evaluation parameters. Depending on the GUI the filename might have to include the full path to the folder/directory that contains the file. Other locations, such as the directory that contains the binary and the working directory, are also searched.

  • UCI_AnalyseMode

    An option handled by your GUI.

  • UCI_Chess960

    An option handled by your GUI. If true, Stockfish will play Chess960.

  • UCI_ShowWDL

    If enabled, show approximate WDL statistics as part of the engine output. These WDL numbers model expected game outcomes for a given evaluation and game ply for engine self-play at fishtest LTC conditions (60+0.6s per game).

  • UCI_LimitStrength

    Enable weaker play aiming for an Elo rating as set by UCI_Elo. This option overrides Skill Level.

  • UCI_Elo

    If enabled by UCI_LimitStrength, aim for an engine strength of the given Elo. This Elo rating has been calibrated at a time control of 60s+0.6s and anchored to CCRL 40/4.

  • Skill Level

    Lower the Skill Level in order to make Stockfish play weaker (see also UCI_LimitStrength). Internally, MultiPV is enabled, and with a certain probability depending on the Skill Level a weaker move will be played.

  • SyzygyPath

    Path to the folders/directories storing the Syzygy tablebase files. Multiple directories are to be separated by ";" on Windows and by ":" on Unix-based operating systems. Do not use spaces around the ";" or ":".

    Example: C:\tablebases\wdl345;C:\tablebases\wdl6;D:\tablebases\dtz345;D:\tablebases\dtz6

    It is recommended to store .rtbw files on an SSD. There is no loss in storing the .rtbz files on a regular HD. It is recommended to verify all md5 checksums of the downloaded tablebase files (md5sum -c checksum.md5) as corruption will lead to engine crashes.

  • SyzygyProbeDepth

    Minimum remaining search depth for which a position is probed. Set this option to a higher value to probe less aggressively if you experience too much slowdown (in terms of nps) due to tablebase probing.

  • Syzygy50MoveRule

    Disable to let fifty-move rule draws detected by Syzygy tablebase probes count as wins or losses. This is useful for ICCF correspondence games.

  • SyzygyProbeLimit

    Limit Syzygy tablebase probing to positions with at most this many pieces left (including kings and pawns).

  • Move Overhead

    Assume a time delay of x ms due to network and GUI overheads. This is useful to avoid losses on time in those cases.

  • Slow Mover

    Lower values will make Stockfish take less time in games, higher values will make it think longer.

  • nodestime

    Tells the engine to use nodes searched instead of wall time to account for elapsed time. Useful for engine testing.

  • Debug Log File

    Write all communication to and from the engine into a text file.

For developers the following non-standard commands might be of interest, mainly useful for debugging:

  • bench ttSize threads limit fenFile limitType evalType

    Performs a standard benchmark using various options. The signature of a version (standard node count) is obtained using all defaults. bench is currently bench 16 1 13 default depth mixed.

  • compiler

    Give information about the compiler and environment used for building a binary.

  • d

    Display the current position, with ascii art and fen.

  • eval

    Return the evaluation of the current position.

  • export_net [filename]

    Exports the currently loaded network to a file. If the currently loaded network is the embedded network and the filename is not specified then the network is saved to the file matching the name of the embedded network, as defined in evaluate.h. If the currently loaded network is not the embedded network (some net set through the UCI setoption) then the filename parameter is required and the network is saved into that file.

  • flip

    Flips the side to move.

A note on classical evaluation versus NNUE evaluation

Both approaches assign a value to a position that is used in alpha-beta (PVS) search to find the best move. The classical evaluation computes this value as a function of various chess concepts, handcrafted by experts, tested and tuned using fishtest. The NNUE evaluation computes this value with a neural network based on basic inputs (e.g. piece positions only). The network is optimized and trained on the evaluations of millions of positions at moderate search depth.

The NNUE evaluation was first introduced in shogi, and ported to Stockfish afterward. It can be evaluated efficiently on CPUs, and exploits the fact that only parts of the neural network need to be updated after a typical chess move. The nodchip repository provides additional tools to train and develop the NNUE networks. On CPUs supporting modern vector instructions (avx2 and similar), the NNUE evaluation results in much stronger playing strength, even if the nodes per second computed by the engine is somewhat lower (roughly 80% of nps is typical).

Notes:

  1. the NNUE evaluation depends on the Stockfish binary and the network parameter file (see the EvalFile UCI option). Not every parameter file is compatible with a given Stockfish binary, but the default value of the EvalFile UCI option is the name of a network that is guaranteed to be compatible with that binary.

  2. to use the NNUE evaluation, the additional data file with neural network parameters needs to be available. Normally, this file is already embedded in the binary or it can be downloaded. The filename for the default (recommended) net can be found as the default value of the EvalFile UCI option, with the format nn-[SHA256 first 12 digits].nnue (for instance, nn-c157e0a5755b.nnue). This file can be downloaded from

https://tests.stockfishchess.org/api/nn/[filename]

replacing [filename] as needed.

What to expect from the Syzygy tablebases?

If the engine is searching a position that is not in the tablebases (e.g. a position with 8 pieces), it will access the tablebases during the search. If the engine reports a very large score (typically 153.xx), this means it has found a winning line into a tablebase position.

If the engine is given a position to search that is in the tablebases, it will use the tablebases at the beginning of the search to preselect all good moves, i.e. all moves that preserve the win or preserve the draw while taking into account the 50-move rule. It will then perform a search only on those moves. The engine will not move immediately, unless there is only a single good move. The engine likely will not report a mate score, even if the position is known to be won.

It is therefore clear that this behaviour is not identical to what one might be used to with Nalimov tablebases. There are technical reasons for this difference, the main technical reason being that Nalimov tablebases use the DTM metric (distance-to-mate), while the Syzygy tablebases use a variation of the DTZ metric (distance-to-zero, zero meaning any move that resets the 50-move counter). This special metric is one of the reasons that the Syzygy tablebases are more compact than Nalimov tablebases, while still storing all information needed for optimal play and in addition being able to take into account the 50-move rule.

Large Pages

Stockfish supports large pages on Linux and Windows. Large pages make the hash access more efficient, improving the engine speed, especially on large hash sizes. Typical increases are 5..10% in terms of nodes per second, but speed increases up to 30% have been measured. The support is automatic. Stockfish attempts to use large pages when available and will fall back to regular memory allocation when this is not the case.

Support on Linux

Large page support on Linux is obtained by the Linux kernel transparent huge pages functionality. Typically, transparent huge pages are already enabled, and no configuration is needed.

Support on Windows

The use of large pages requires "Lock Pages in Memory" privilege. See Enable the Lock Pages in Memory Option (Windows) on how to enable this privilege, then run RAMMap to double-check that large pages are used. We suggest that you reboot your computer after you have enabled large pages, because long Windows sessions suffer from memory fragmentation, which may prevent Stockfish from getting large pages: a fresh session is better in this regard.

Compiling Stockfish yourself from the sources

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.

    cd src
    make help
    make net
    make build ARCH=x86-64-modern

When not using the Makefile to compile (for instance, with Microsoft MSVC) you need to manually set/unset some switches in the compiler command line; see file types.h for a quick reference.

When reporting an issue or a bug, please tell us which Stockfish version and which compiler you used to create your executable. This information can be found by typing the following command in a console:

    ./stockfish compiler

Understanding the code base and participating in the project

Stockfish's improvement over the last decade has been a great community effort. There are a few ways to help contribute to its growth.

Donating hardware

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

Improving the code

If you want to help improve the code, there are several valuable resources:

  • In this 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 being focused on Stockfish's precise implementation. Nevertheless, a helpful resource.

  • The latest source can always be found on GitHub. Discussions about Stockfish take place these days mainly in the FishCooking group and on the Stockfish Discord channel. 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.

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 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 the GPL.

For full details, read the copy of the GPL v3 found in the file named Copying.txt.

fairy-stockfish's People

Contributors

31m059 avatar bm123499 avatar ceebo avatar elbertoone avatar fauziakram avatar fulmene avatar gbtami avatar glinscott avatar ianfab avatar joergoster avatar locutus2 avatar lucasart avatar mcostalba avatar miguel-l avatar mjz1977 avatar pb00068 avatar queensgambit avatar r-peleg avatar rainrat avatar rocky640 avatar sfisgod avatar snicolet avatar sopel97 avatar stefano80 avatar syzygy1 avatar unaiic avatar vizvezdenec avatar vondele avatar voyagerone avatar zamar avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fairy-stockfish's Issues

Perpetual check blindness in xiangqi

When the losing side has a perpetual check (and can pause the checking any time), SF recognizes only very late that the game is not drawn. Note: In actual games SF correctly detects perpetual checks and does not play them, the search just does not foresee that it has to stop checking, so it delays the loss by putting in some checks.

Examples:

  • Trivial endgame
setoption name UCI_Variant value xiangqi
position fen 4k4/8R/9/9/9/9/9/9/9/rrEA1K3 w 0 1
go depth 20
info depth 1 seldepth 2 multipv 1 score cp -229 nodes 46 nps 23000 tbhits 0 time 2 pv i9i10 e10e9
info depth 2 seldepth 3 multipv 1 score cp -225 nodes 105 nps 52500 tbhits 0 time 2 pv d1e2 b1c1 f1f2
info depth 3 seldepth 5 multipv 1 score cp -238 nodes 178 nps 89000 tbhits 0 time 2 pv i9i10 e10e9 d1e2 b1c1 f1f2
info depth 4 seldepth 6 multipv 1 score cp -261 nodes 300 nps 100000 tbhits 0 time 3 pv i9i10 e10e9 d1e2 b1c1 f1f2 a1a2
info depth 5 seldepth 7 multipv 1 score cp -259 nodes 603 nps 150750 tbhits 0 time 4 pv d1e2 b1b2 f1f2 a1c1 i9i2
info depth 6 seldepth 9 multipv 1 score cp -297 nodes 1522 nps 217428 tbhits 0 time 7 pv i9i10 e10e9 d1e2 b1c1 f1f2 a1a2 i10g10
info depth 7 seldepth 12 multipv 1 score cp 0 nodes 1795 nps 224375 tbhits 0 time 8 pv i9i10 e10e9 i10i9 e9e10
info depth 8 seldepth 6 multipv 1 score cp 0 nodes 1895 nps 210555 tbhits 0 time 9 pv i9i10 e10e9 i10i9 e9e10
info depth 9 seldepth 15 multipv 1 score cp 0 nodes 3844 nps 240250 tbhits 0 time 16 pv i9i10 e10e9 i10i4 a1a7 i4e4 e9d9 e4d4 d9e9
info depth 10 seldepth 18 multipv 1 score cp 0 nodes 5100 nps 137837 tbhits 0 time 37 pv i9i10 e10e9 i10i4 b1c1 i4e4 e9d9 e4d4 d9e9
info depth 11 seldepth 18 multipv 1 score cp 0 nodes 7290 nps 162000 tbhits 0 time 45 pv i9i10 e10e9 i10i4 b1b5 i4i9 e9e10 i9i10 e10e9
info depth 12 seldepth 22 multipv 1 score cp 0 nodes 13029 nps 148056 tbhits 0 time 88 pv i9i10 e10e9 i10i4 a1a8 i4i9 e9e10 i9i10 e10e9
info depth 13 seldepth 10 multipv 1 score cp 0 nodes 13257 nps 131257 tbhits 0 time 101 pv i9i10 e10e9 i10i4 a1a8 i4i9 e9e10 i9i10 e10e9
info depth 14 seldepth 9 multipv 1 score cp 0 nodes 13504 nps 132392 tbhits 0 time 102 pv i9i10 e10e9 i10i4 a1a8 i4i9 e9e10 i9i10 e10e9
info depth 15 seldepth 17 multipv 1 score cp 0 nodes 13964 nps 134269 tbhits 0 time 104 pv i9i10 e10e9 i10i4 b1c1 i4e4 e9d9 e4d4 d9e9
info depth 16 seldepth 31 multipv 1 score cp 0 nodes 31365 nps 129074 tbhits 0 time 243 pv i9i10 e10e9 i10i4 a1a2 i4e4 e9d9 e4d4 d9e9
info depth 17 seldepth 10 multipv 1 score cp 0 nodes 40235 nps 124566 tbhits 0 time 323 pv i9i10 e10e9 i10i4 e9e10
info depth 18 seldepth 11 multipv 1 score cp 0 nodes 46350 nps 123271 tbhits 0 time 376 pv i9i10 e10e9 i10i4 b1c1 i4i9 e9e10 i9i10 e10e9
info depth 19 seldepth 9 multipv 1 score cp 0 nodes 56567 nps 117115 tbhits 0 time 483 pv i9i10 e10e9 i10i4 a1a2 i4e4 e9d9 e4d4 d9e9
info depth 20 seldepth 23 multipv 1 score cp 0 nodes 98429 nps 132475 tbhits 0 time 743 pv i9i10 e10e9 i10i9 e9e10
  • Middlegame 1
setoption name UCI_Variant value xiangqi
position fen 4kae2/4a4/2H6/p3PP3/3H5/5R3/9/9/4K4/2r4c1 b 14 73
go depth 15
info depth 1 seldepth 1 multipv 1 score cp 44 nodes 39 nps 19500 tbhits 0 time 2 pv a7a6
info depth 2 seldepth 2 multipv 1 score cp 83 nodes 243 nps 81000 tbhits 0 time 3 pv c1c6 c8e9
info depth 3 seldepth 4 multipv 1 score cp 71 nodes 354 nps 118000 tbhits 0 time 3 pv c1a1 e2e3 a1e1 e3d3
info depth 4 seldepth 9 multipv 1 score cp 92 nodes 452 nps 150666 tbhits 0 time 3 pv c1a1 c8e9 f10e9
info depth 5 seldepth 7 multipv 1 score cp 69 nodes 1069 nps 178166 tbhits 0 time 6 pv a7a6 c8e9 f10e9 e2e3 c1a1
info depth 6 seldepth 12 multipv 1 score cp 66 nodes 3547 nps 154217 tbhits 0 time 23 pv a7a6 f7g7 h1i1 f5f7 c1a1 e7e8 a1a2 e2e1 g10e8 d6e8
info depth 7 seldepth 51 multipv 1 score cp 23 nodes 28725 nps 94490 tbhits 0 time 304 pv e9d10 f5a5 f10e9 a5a7 c1c2 e2e1 c2c3 c8d10 e10d10
info depth 8 seldepth 14 multipv 1 score cp 0 nodes 36893 nps 93400 tbhits 0 time 395 pv e9d10 f5a5 f10e9 a5a7 c1c2 e2e1 c2c1
info depth 9 seldepth 8 multipv 1 score cp 0 nodes 46929 nps 105221 tbhits 0 time 446 pv e9d10 f5a5 f10e9 a5a7 c1c2 e2e1 c2c1
info depth 10 seldepth 15 multipv 1 score cp 0 nodes 71969 nps 121364 tbhits 0 time 593 pv e9d10 f5a5 f10e9 a5a3 c1c2 e2e3 c2c1
info depth 11 seldepth 15 multipv 1 score cp 0 nodes 91204 nps 123248 tbhits 0 time 740 pv e9d10 f5a5 f10e9 a5a3 c1c2 e2e3 c2c1 e3e2
info depth 12 seldepth 15 multipv 1 score cp 0 nodes 126823 nps 128104 tbhits 0 time 990 pv e9d10 f5a5 f10e9 a5a3 c1c2 e2e1 c2c1
info depth 13 seldepth 19 multipv 1 score cp 0 nodes 169382 nps 134430 hashfull 106 tbhits 0 time 1260 pv e9d10 f5a5 f10e9 a5a7 c1c2 e2e1 c2c1
info depth 14 seldepth 21 multipv 1 score cp 0 nodes 252780 nps 137305 hashfull 156 tbhits 0 time 1841 pv c1c2 e2e1 c2c3 c8a7 c3c1 e1e2 c1c2 e2e3 c2c1 e3e2
info depth 15 seldepth 27 multipv 1 score cp 0 nodes 374285 nps 140655 hashfull 232 tbhits 0 time 2661 pv e9d10 f5a5 c1c6 a5a7 f10e9 a7a10 h1c1 a10c10 c1c5 e2e1 c5c3 e1e2 c3c5
  • Middlegame 2
setoption name UCI_Variant value xiangqi
position fen 2eak4/4a4/5c1Rh/p1H1PHp2/2e5p/P8/9/4E4/4K4/2EA1r3 b 1 48
go depth 15
info depth 1 seldepth 2 multipv 1 score cp 589 nodes 45 nps 22500 tbhits 0 time 2 pv f1f2 e2e1 f2f1 e1e2
info depth 2 seldepth 4 multipv 1 score cp 589 nodes 115 nps 57500 tbhits 0 time 2 pv f1f2 e2e1 f2f1 e1e2
info depth 3 seldepth 6 multipv 1 score cp 504 nodes 272 nps 90666 tbhits 0 time 3 pv i8h6 h8h7 h6f7 h7h10 e9f10 e7f7 f1f7
info depth 4 seldepth 5 multipv 1 score cp 493 nodes 377 nps 94250 tbhits 0 time 4 pv i8h6 h8h9 h6f7 e7f7 f1f7
info depth 5 seldepth 7 multipv 1 score cp 246 nodes 1167 nps 145875 tbhits 0 time 8 pv f1i1 h8i8 i1d1 c7e6 d1f1
info depth 6 seldepth 8 multipv 1 score cp 96 nodes 2606 nps 186142 tbhits 0 time 14 pv c6e8 h8i8 e8g10 i8i10 e9f10 i10g10
info depth 7 seldepth 10 multipv 1 score cp 46 nodes 6159 nps 186636 tbhits 0 time 33 pv c10e8 h8i8 e8g10 i8f8 e9f8 f7e5 d10e9 e5c6
info depth 8 seldepth 11 multipv 1 score cp 61 nodes 10227 nps 182625 tbhits 0 time 56 pv f1d1 h8i8 d1d5 i8i6 d5a5 f7g5 f8f4
info depth 9 seldepth 13 multipv 1 score cp 66 nodes 17063 nps 179610 tbhits 0 time 95 pv f1f2 e2e1 f2f1 e1e2 i6i5 h8i8 f1d1 f7g5 f8f5
info depth 10 seldepth 21 multipv 1 score cp 87 nodes 31469 nps 214074 tbhits 0 time 147 pv f1d1 h8i8 d1d5 c7b9 i6i5 i8i10 e9f10 f7e5 f8f9 e5d7
info depth 11 seldepth 19 multipv 1 score cp 50 nodes 75579 nps 274832 tbhits 0 time 275 pv f1d1 h8i8 d1d5 i8i6 d5f5 c7b9 c6e8 i6i10 f8f10 e2e1 g7g6 e7e8 c10e8
info depth 12 seldepth 23 multipv 1 score cp 0 nodes 194406 nps 283804 tbhits 0 time 685 pv f1d1 h8i8 d1d5 i8i6 d5a5 i6c6 a5a2 e2e1 a2h2 f7e5 h2h1 e1e2 h1h2 e2e1
info depth 13 seldepth 21 multipv 1 score cp 0 nodes 234487 nps 258245 tbhits 0 time 908 pv f1d1 h8i8 d1d5 i8i6 d5a5 i6c6 a5a2 e2e1 a2h2 f7e5 h2h1 e1e2 h1h2 e2e1
info depth 14 seldepth 25 multipv 1 score cp 0 nodes 347916 nps 239281 hashfull 181 tbhits 0 time 1454 pv f1d1 h8i8 d1h1 f7e5 h1h2 e2e1 h2h1 e1e2
info depth 15 seldepth 9 multipv 1 score cp 0 nodes 401490 nps 247680 hashfull 214 tbhits 0 time 1621 pv f1d1 h8i8 d1h1 f7e5 h1h2 e2e1 h2h1 e1e2

Combined variants

What do you think about adding combinations of some base variant + chess960 + zh?
Something like Seirawan-zh, Seirawan960-zh, Caparandom-zh. It would be fun IMO.

Wrong evaluation of final positions in racing kings

Final positions with both kings on the back rank are considered to be lost instead of drawn.

setoption name multipv value 10
setoption name UCI_Variant value racingkings
position fen 7K/k7/8/8/8/8/8/8 b - - 0 1
go depth 1
info depth 1 seldepth 1 multipv 1 score mate -1 nodes 15 nps 7500 tbhits 0 time 2 pv a7a6
info depth 1 seldepth 1 multipv 2 score mate -1 nodes 15 nps 7500 tbhits 0 time 2 pv a7b6
info depth 1 seldepth 1 multipv 3 score mate -1 nodes 15 nps 7500 tbhits 0 time 2 pv a7b7
info depth 1 seldepth 1 multipv 4 score mate -1 nodes 15 nps 7500 tbhits 0 time 2 pv a7a8
info depth 1 seldepth 1 multipv 5 score mate -1 nodes 15 nps 7500 tbhits 0 time 2 pv a7b8
bestmove a7a6

Positions for validating white-black asymmetry in evaluation when both kings can reach back rank:

setoption name multipv value 10
setoption name UCI_Variant value racingkings
position fen 8/K6k/8/8/8/8/8/8 w - - 0 1
go depth 5
setoption name multipv value 10
setoption name UCI_Variant value racingkings
position fen 8/K6k/8/8/8/8/8/8 b - - 0 1
go depth 5

Note: Might interfere with implementation of Jeson Mor.

Pruning issues in Breakthrough - SF does not see mate in 2

As example this game:

[Event "Breakthrough Chess Game"]
[Site "ATELCO-PC"]
[Date "2018.11.07"]
[Round "-"]
[White "Michael Taktikos"]
[Black "Fairy-Stockfish 071118 64 (UCI2WB)"]
[Result "1:0"]
[TimeControl "40/240"]
[Variant "breakthrough"]
[FEN "pppppppp/pppppppp/8/8/8/8/PPPPPPPP/PPPPPPPP w - - 0 1"]
[SetUp "1"]

{--------------
p p p p p p p p
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
P P P P P P P P
white to play
--------------}

  1. a2b3 c7d6 {-0.51/17 34} 2. h2g3 f7e6 {-0.42/15 5} 3. b4 g7f6
    {-0.62/18 24} 4. f2e3 a7b6 {-0.40/16 2.9} 5. e2d3 d5 {-0.36/19 17} 6. d2c3
    h7g6 {-0.77/18 11} 7. c4 d6 {+0.50/18 10} 8. b5 c8d7 {+1.32/16 2.5} 9. g2f3
    b7c6 {+2.57/16 8} 10. b5a6 b7 {+4.82/17 22}

The bug is reconstruable: In winboard, menu edit/"copy game from clipboard", then go to move #10 and play manually 10.b5a6 SF will answer with 10... b7?
Has nothing to do with your new evaluation tweaking, the bug was there before, I assume somewhere to heavy pruning, or an unwanted try to promote the breakthrough-piece so that it never reaches the last rank

Originally posted by @mtaktikos in fd6e178#commitcomment-31212386

Sittuyin perft difference

I have a sittuyin middle game position perft test case in PyChess at https://github.com/pychess/pychess/blob/master/testing/movegen.py#L153

8/6k1/6p1/3s2P1/3npR2/2r5/p2N2F1/3K4 b - - 0 49

PyChess and Fairy-Stockfish produces same values until depth 4, but different ones at depth 5.

The tail of pychess-engine output:

 4     394725 11.08     35628.91nps
  Nd4-e6     390479     390479
  Nd4-c6     367287     757766
  Nd4-f5     338546    1096312
  Nd4-b5     376896    1473208
  Nd4-f3     270240    1743448
  Nd4-b3     337983    2081431
  Nd4-e2     359577    2441008
  Nd4-c2     347399    2788407
  Kg7-h8     333087    3121494
  Kg7-g8     371850    3493344
  Kg7-h7     332325    3825669
  Rc3-c8     394031    4219700
  Rc3-c7     359383    4579083
  Rc3-c6     322419    4901502
  Rc3-c5     303072    5204574
  Rc3-c4     279819    5484393
  Rc3-h3     387577    5871970
  Rc3-g3     337498    6209468
  Rc3-f3     265719    6475187
  Rc3-e3     278932    6754119
  Rc3-d3     173145    6927264
  Rc3-b3     388259    7315523
  Rc3-a3     383052    7698575
  Rc3-c2     293446    7992021
  Rc3-c1       7608    7999629
  Sd5-e6     409773    8409402
  Sd5-c6     359078    8768480
  Sd5-c4     316027    9084507
   e4-e3     272711    9357218
   a2-a1     389795    9747013
 e4xe4=Q     335238   10082251
 e4-f5=Q     330633   10412884
 e4-f3=Q     282319   10695203
 e4-d3=Q     302094   10997297
 5   10997297 324.10     33931.87nps

Fairy-Stockfish:

go perft 5
a2a1: 389795
e4e3: 272711
e4d3f: 302094
e4f3f: 282319
e4e4f: 335238
e4f5f: 330633
d4c2: 347399
d4e2: 359577
d4b3: 337983
d4f3: 270240
d4b5: 376896
d4f5: 338546
d4c6: 367287
d4e6: 390479
c3c1: 7608
c3c2: 293446
c3a3: 383052
c3b3: 388259
c3d3: 173145
c3e3: 278932
c3f3: 265719
c3g3: 337498
c3h3: 387577
c3c4: 279819
c3c5: 303072
c3c6: 322385
c3c7: 359349
c3c8: 393997
d5c4: 316027
d5c6: 359078
d5e6: 409773
g7h8: 333087
g7g8: 371850
g7h7: 332325

Nodes searched: 10997195

I started to track down the differences with following move sequence:
Rc3c8
2r5/6k1/6p1/3s2P1/3npR2/8/p2N2F1/3K4 w - - 0 50
Nd2b3
2r5/6k1/6p1/3s2P1/3npR2/1N6/p5F1/3K4 b - - 0 51
Rc8e8
4r3/6k1/6p1/3s2P1/3npR2/1N6/p5F1/3K4 w - - 0 52
Kd1e1
4r3/6k1/6p1/3s2P1/3npR2/1N6/p5F1/4K3 b - - 0 53

In this position Fairy-Stockfish produces this:

position fen 4r3/6k1/6p1/3s2P1/3npR2/1N6/p5F1/4K3 b - - 0 53
go perft 1
a2a1: 1
e4e3: 1
g7h8: 1
g7g8: 1
g7h7: 1
d5e6: 1
d4c2: 1
d4e2: 1
d4b3: 1
d4f3: 1
d4b5: 1
d4f5: 1
d4c6: 1
d4e6: 1
e8e5: 1
e8e6: 1
e8e7: 1
e8a8: 1
e8b8: 1
e8c8: 1
e8d8: 1
e8f8: 1
e8g8: 1
e8h8: 1
d5c4: 1
d5c6: 1

Nodes searched: 26

Seems e4e4f in place promotion is missing here.
Maybe there are other differences with our movegen, but I will wait for this being fixed before going on 😉

[Sittuyin] promotion rule

Thank you for adding Sittuyin support!

I finally had a chance to do some testing, mainly by using some highly artificial positions to test rule conformity during promotion. The testing methodology was simple, involving obvious and enticing material incentives, to encourage promotion as long as the engine thinks it is legal to do so.

I am happy to report that the current master branch seems to know most of the rules, although it still appears to be ignoring one: "The promotion shall not be made in the direct-attacking position to the opponent piece by newly-promoted general." (rule 3.9 c.4, page 8)

Specifically, it would try to promote with a fork on non-King pieces. But if the same move also attacks the opponent King, the engine knows about the "no checks, direct or discovered" rule, and avoids it.

8/8/4r1r1/6fk/1R2P3/4N3/2N5/2KS4 w - - 0 1
PV: e4f5f (illegal attack forking two rooks with the new Fers)

But if the opponent King is also involved, a similar fork isn't attempted.
8/8/4r1k1/6fr/1R2P3/4N3/2N5/2KS4 w - - 0 1
PV: e4e4f (legal promotion)

P.S.
I just realized that this might not be a bug, and probably a different interpretation that you made from the wording of the rules. But because this could potentially affect game-play, especially in positions where the engine might be relying on (or trying to avoid) variations which include winning/regaining material with forks upon promotion, I thought I'd report about this behavior. Thank you!

Support variants with large boards (up to 12x10)

The board size is currently limited to be smaller than or equal to 8x8 squares. Investigate feasibility of switchover to larger bitboards, e.g., based on compiler-specific 128 bit integers, in order to be able to support board sizes up to 12x10.

Required steps:

  • use unsigned __int128 for bitboards
  • rewrite bitboard operations to work for 128bit (including popcount, pext, etc.)
  • extend squares, files, ranks, move representation, etc. to match a 12x10 board
  • adjust code for magics for 12x10 / 128 bit bitboards
  • fix potential issues with two digit numbers in FEN and move strings
  • extend TT entry to use 32 bit int for move representation to avoid wrong TT moves
  • generalize castling for large boards
  • improve performance of non-pext magics generation (precompute magics)
  • make parsing of en passant flag in FEN work irrespective of board size

Further improvements:

  • Support MSVC
  • Support 32-bit hardware
  • reduce size of rook magics for large-board version (~200 MB) by splitting into horizontal and vertical slider
  • reduce memory consumption of continuation history table (100 MB) (e.g., by only using slots for piece types actually used in a variant)
  • fix endgame code (pawn bitbases, square normalization, etc.) and re-enable it
  • fix or disable TB code
  • fix issues in evaluation related to different board size (e.g., PSQT asymmetry)
  • rewrite move encoding, simplify from_sq

Hostage Chess

This is a variant that I'm most interested in. https://www.hostagechess.com/ This website has a beautiful book about this variant also available. I wonder if Fairy-Stockfish could also support this variant.

Crashes on fishtest

Recent tests on fishtest show occasional crashes on all workers for various variants. I was not able to reproduce it locally so far, so if anyone managed to find a reproducible bug or get a stacktrace, please let me know.

Bug in S-chess FEN generation

In my up to date Fairy-Stockfish clone python3 test.py fails one get_fen() test.
The position is your example in 22fc967 commit message.

tamas@tami:~/Fairy-Stockfish$ python3 test.py
test_get_fen (__main__.TestPyffish) ... FAIL
test_get_san (__main__.TestPyffish) ... ok
test_gives_check (__main__.TestPyffish) ... ok
test_has_insufficient_material (__main__.TestPyffish) ... ok
test_info (__main__.TestPyffish) ... ok
test_is_immediate_game_end (__main__.TestPyffish) ... ok
test_is_optional_game_end (__main__.TestPyffish) ... ok
test_legal_moves (__main__.TestPyffish) ... ok
test_set_option (__main__.TestPyffish) ... info string variant capablanca files 10 ranks 8 pocket 0 template fairy startpos rnabqkbcnr/pppppppppp/10/10/10/10/PPPPPPPPPP/RNABQKBCNR w KQkq - 0 1
ok
test_short_castling (__main__.TestPyffish) ... ok
test_start_fen (__main__.TestPyffish) ... ok

======================================================================
FAIL: test_get_fen (__main__.TestPyffish)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 73, in test_get_fen
    self.assertEqual(result, fen1)
AssertionError: 'reb2rk1/ppppqppp/2nb1n2/4p3/4P3/N1P2N2/PB1PQPPP/RE2KBHR[h] w KQacgh - 3 7' != 'reb2rk1/ppppqppp/2nb1n2/4p3/4P3/N1P2N2/PB1PQPPP/RE2KBHR[h] w KQac - 3 7'
- reb2rk1/ppppqppp/2nb1n2/4p3/4P3/N1P2N2/PB1PQPPP/RE2KBHR[h] w KQacgh - 3 7
?                                                                  --
+ reb2rk1/ppppqppp/2nb1n2/4p3/4P3/N1P2N2/PB1PQPPP/RE2KBHR[h] w KQac - 3 7


----------------------------------------------------------------------
Ran 11 tests in 0.005s

FAILED (failures=1)

Btw. the bug was reproduced in https://pychess-variants.herokuapp.com/xyF6jgaY

Playing strength against human opponents

Playing strength against engine opponents is quite well known already, but the comparison against human opponents is more difficult. I started to collect estimates in https://github.com/ianfab/Fairy-Stockfish/wiki/Playing-strength#compared-to-human-opponents.

If you have an estimate for playing strength in a variant, feel free to add it in the wiki or leave a comment here. In order to have a standardized classification, I would suggest to use the following categories:
expert: 2000+
master: 2200+
elite: 2500+
superhuman: 2800+

960 variants

Can FairyStockfish play 960 (sub)variants of variants starting with standard chess initial FEN?
(Crazyhouse, Losers, Seirawan, etc.)

Ideas

additional rule configuration options

  • game termination criteria
    • bare king (shatranj, losers, heian shogi)
    • capture the flag (king of the hill, racing kings, breakthrough)
    • check count (3check, 5check, kar ouk)
    • piece count (horde, extinction, giveaway, kinglet)
    • checkmate/stalemate score (losers, shatranj)
    • connectN
  • game dynamics
    • piece drops (crazyhouse, loop, chessgi, pocketknight, shogi variants [minishogi, euroshogi, tori shogi], sittuyin)
    • piece drops, but captured pieces are not transferred to opponent's hand (pocketknight, bughouse, sittuyin)
    • gating (seirawan)
    • mandatory/prohibited captures/checks (giveaway, losers, clobber, racing kings)
    • board sizes below 8x8 (los alamos, minishogi, minixiangqi)
    • piece promotions, unpromotion when capturing (shogi variants)
    • optional promotions (shogi variants, sittuyin)
    • hoppers (xiangqi, grasshopper)
    • setup-phase (or forced piece drops) (sittuyin, placement)
    • restriction of piece drops to certain area, e.g., behind pawns (sittuyin, placement)
    • sittuyin pawn promotion rules
    • complex checkmate legality evaluation (shogi, shatar)
    • do not require presence of kings (giveaway, horde, extinction)
    • castling with non-king (e.g., commoner) pieces (giveaway, extinction, knightmate)
    • pawns on first rank (horde, chessgi, shogi variants)
    • compile-time option to enable board sizes between 8x8 and 12x10 (shogi, xiangqi, capablanca)
    • generalize pawn double step option (grand)
    • one-time moves (ouk chatrang)

major missing games

  • Lines of action
  • Game of the Amazons
  • Surakarta
  • Go
  • Checkers

enhancements, refactoring

  • move variant configuration to a text/ini file
  • store piece movement options in piece-centric way for readablity and robustness (not performance critical as only used for bitboard initialization at startup)
  • reduce memory consumption of history tables (can be up to ~150MB per thread for 64 piece types)
  • support USI dialect for shogi variants
  • extend TT entry to use 32 bit int for move representation -> removes restriction on number of piece types, allows addition of new move types, e.g., for gating, and makes encoding of promotions more flexible and more performant

playing strength improvements

  • generic psqt formula
  • generic mobility bonus formula
  • passed pawn bonus scaled by value of promotion piece
  • king safety calculation considering all piece types
  • variant goal specific bonuses (distance from king target squares, check count bonus, etc.)
  • endgame eval functions for fairy pieces
  • speed-ups for attack bitboard generation
  • search adaptions for variants (e.g., pruning margins)

limitations, not doable

  • boards with different topology (Hex, etc.)
  • complex game dynamics (cylinder, alice, atomic(?), patrol(?))
  • incomplete information (kriegspiel, dark chess)
  • multimove/multiplayer variants (progressive chess, avalanche chess, four-player chess)

Memory consumption of continuation history

Due to the recent upstream changes of the continuation history, its size in the large-board version increased to almost 100 MB. This does not cause any immediate problems, but it would be preferable to keep the memory consumption small.

Knightmate

Currently only kings can be used as royal pieces. Add support for royal non-king pieces to support more variants:

  • Knightmate
  • Maharaja and the sepoys

Xiangqi

Open problems for a Xiangqi implementation:

  • Hopper/Cannon move generation
  • Lame leapers (elephant, horse)
    • consider time-asymmetrical movement of horse in attackers calculation
    • precalculated magics
  • Configurable area for piece movements (general, elephant, advisor)
    • consider in move generation, and attack/attackers_to calculation
  • Alternative royal pieces (wazir-style movement of general)
  • Position-dependent move of soldier
  • Flying general rule (face-off)
  • basic chasing rules
    • perpetual check illegal
    • 3fold illegal
  • make piece abbreviations consistent with UCCI convention (only use XBoard convention for XBoard protocol)

Possible further improvement:

  • complex chasing rules

Current state of incomplete xiangqi implementation is on branch xiangqi.

Support for very large boards (>12x10)

Place to discuss potential support for board sizes >12x10.

  • Most likely needs to be based on 256 bitboards, i.e., up to 16x16 boards.
  • Use non-magic method for move generation? Or split magics (as for rook and cannon) to reduce size?

Failed to compile large boards

I wanted to try shogi on my Ubuntu 18.04 laptop.
The compiled stockfish doesn't start (segmentation error).

tamas@tami:~/Fairy-Stockfish/src$ make build ARCH=x86-64 COMP=gcc largeboards=yes

Config:
debug: 'no'
sanitize: 'no'
optimize: 'yes'
arch: 'x86_64'
bits: '64'
kernel: 'Linux'
os: 'GNU/Linux'
prefetch: 'yes'
popcnt: 'no'
sse: 'yes'
pext: 'no'

Flags:
CXX: g++
CXXFLAGS: -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto
LDFLAGS:  -m64 -Wl,--no-as-needed -lpthread -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto

Testing config sanity. If this fails, try 'make help' ...

make ARCH=x86-64 COMP=gcc all
make[1]: Entering directory '/home/tamas/Fairy-Stockfish/src'
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o benchmark.o benchmark.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o endgame.o endgame.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o evaluate.o evaluate.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o main.o main.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o material.o material.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o misc.o misc.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o movegen.o movegen.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o movepick.o movepick.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o pawns.o pawns.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o position.o position.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o psqt.o psqt.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o search.o search.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o thread.o thread.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o timeman.o timeman.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o uci.o uci.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o ucioption.o ucioption.cpp
g++ -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto   -c -o variant.o variant.cpp
g++ -o stockfish benchmark.o bitbase.o bitboard.o endgame.o evaluate.o main.o material.o misc.o movegen.o movepick.o pawns.o position.o psqt.o search.o thread.o timeman.o tt.o uci.o ucioption.o variant.o syzygy/tbprobe.o  -m64 -Wl,--no-as-needed -lpthread -Wall -Wcast-qual -fno-exceptions -std=c++11  -DLARGEBOARDS -DPRECOMPUTED_MAGICS -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto
types.h:274:6: warning: type ‘Square’ violates the C++ One Definition Rule [-Wodr]
 enum Square : int {
      ^
types.h:274:6: note: an enum with different value name is defined in another translation unit
 enum Square : int {
      ^
types.h:334:6: warning: type ‘Rank’ violates the C++ One Definition Rule [-Wodr]
 enum Rank : int {
      ^
types.h:334:6: note: an enum with different value name is defined in another translation unit
 enum Rank : int {
      ^
types.h:324:6: warning: type ‘File’ violates the C++ One Definition Rule [-Wodr]
 enum File : int {
      ^
types.h:324:6: note: an enum with different value name is defined in another translation unit
 enum File : int {
      ^
bitboard.h:114:8: warning: type ‘struct Magic’ violates the C++ One Definition Rule [-Wodr]
 struct Magic {
        ^
bitboard.h:114:8: note: a different type is defined in another translation unit
 struct Magic {
        ^
bitboard.h:115:13: note: the first difference of corresponding definitions is field ‘mask’
   Bitboard  mask;
             ^
bitboard.h:115:13: note: a field of same name but different type is defined in another translation unit
   Bitboard  mask;
             ^
types.h:109:18: note: type ‘Bitboard’ should match type ‘Bitboard’
 typedef uint64_t Bitboard;
                  ^
types.h:106:27: note: the incompatible type is defined here
 typedef unsigned __int128 Bitboard;
                           ^
types.h:308:6: warning: type ‘Direction’ violates the C++ One Definition Rule [-Wodr]
 enum Direction : int {
      ^
types.h:308:6: note: an enum with different values is defined in another translation unit
 enum Direction : int {
      ^
variant.h:34:8: warning: type ‘struct Variant’ violates the C++ One Definition Rule [-Wodr]
 struct Variant {
        ^
syzygy/../variant.h:34:8: note: a different type is defined in another translation unit
 struct Variant {
        ^
variant.h:36:20: note: the first difference of corresponding definitions is field ‘pocketSize’
   int pocketSize = 0;
                    ^
syzygy/../variant.h:36:18: note: a field with different name is defined in another translation unit
   int pocketSize = 0;
                  ^
position.h:39:8: warning: type ‘struct StateInfo’ violates the C++ One Definition Rule [-Wodr]
 struct StateInfo {
        ^
syzygy/../position.h:39:8: note: a different type is defined in another translation unit
 struct StateInfo {
        ^
position.h:50:10: note: the first difference of corresponding definitions is field ‘epSquare’
   Square epSquare;
          ^
syzygy/../position.h:50:10: note: a field of same name but different type is defined in another translation unit
   Square epSquare;
          ^
types.h:274:6: note: type ‘Square’ itself violates the C++ One Definition Rule
 enum Square : int {
      ^
position.h:78:7: warning: type ‘struct Position’ violates the C++ One Definition Rule [-Wodr]
 class Position {
       ^
syzygy/../position.h:78:7: note: a different type is defined in another translation unit
 class Position {
       ^
position.h:249:24: note: the first difference of corresponding definitions is field ‘board’
   Piece board[SQUARE_NB];
                        ^
syzygy/../position.h:245:24: note: a field of same name but different type is defined in another translation unit
   template<bool Do>
                        ^
position.h:78:7: note: array types have different bounds
 class Position {
       ^
types.h:128:6: warning: type ‘Move’ violates the C++ One Definition Rule [-Wodr]
 enum Move : int {
      ^
syzygy/../types.h:128:6: note: an enum with different values is defined in another translation unit
 enum Move : int {
      ^
movegen.h:39:8: warning: type ‘struct ExtMove’ violates the C++ One Definition Rule [-Wodr]
 struct ExtMove {
        ^
syzygy/../movegen.h:39:8: note: a different type is defined in another translation unit
 struct ExtMove {
        ^
movegen.h:40:8: note: the first difference of corresponding definitions is field ‘move’
   Move move;
        ^
syzygy/../movegen.h:40:8: note: a field of same name but different type is defined in another translation unit
   Move move;
        ^
types.h:128:6: note: type ‘Move’ itself violates the C++ One Definition Rule
 enum Move : int {
      ^
syzygy/../types.h:128:6: note: the incompatible type is defined here
 enum Move : int {
      ^
types.h:133:6: warning: type ‘MoveType’ violates the C++ One Definition Rule [-Wodr]
 enum MoveType : int {
      ^
syzygy/../types.h:133:6: note: an enum with different values is defined in another translation unit
 enum MoveType : int {
      ^
syzygy/tbprobe.h:52:6: warning: ‘root_probe’ violates the C++ One Definition Rule  [-Wodr]
 bool root_probe(Position& pos, Search::RootMoves& rootMoves);
      ^
syzygy/tbprobe.cpp:1446:6: note: type mismatch in parameter 1
 bool Tablebases::root_probe(Position& pos, Search::RootMoves& rootMoves) {
      ^
syzygy/../position.h:78:7: note: type ‘struct Position’ itself violates the C++ One Definition Rule
 class Position {
       ^
position.h:78:7: note: the incompatible type is defined here
 class Position {
       ^
syzygy/tbprobe.cpp:1446:6: note: ‘root_probe’ was previously declared here
 bool Tablebases::root_probe(Position& pos, Search::RootMoves& rootMoves) {
      ^
syzygy/tbprobe.cpp:1446:6: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/tbprobe.h:53:6: warning: ‘root_probe_wdl’ violates the C++ One Definition Rule  [-Wodr]
 bool root_probe_wdl(Position& pos, Search::RootMoves& rootMoves);
      ^
syzygy/tbprobe.cpp:1515:6: note: type mismatch in parameter 1
 bool Tablebases::root_probe_wdl(Position& pos, Search::RootMoves& rootMoves) {
      ^
syzygy/../position.h:78:7: note: type ‘struct Position’ itself violates the C++ One Definition Rule
 class Position {
       ^
position.h:78:7: note: the incompatible type is defined here
 class Position {
       ^
syzygy/tbprobe.cpp:1515:6: note: ‘root_probe_wdl’ was previously declared here
 bool Tablebases::root_probe_wdl(Position& pos, Search::RootMoves& rootMoves) {
      ^
syzygy/tbprobe.cpp:1515:6: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/../position.h:841:13: warning: ‘do_move’ violates the C++ One Definition Rule  [-Wodr]
 inline void Position::undrop_piece(Piece pc_hand, Piece pc_drop, Square s) {
             ^
position.h:817:13: note: implicit this pointer type mismatch
 inline void Position::do_move(Move m, StateInfo& newSt) {
             ^
position.h:78:7: note: type ‘struct Position’ itself violates the C++ One Definition Rule
 class Position {
       ^
syzygy/../position.h:78:7: note: the incompatible type is defined here
 class Position {
       ^
position.h:817:13: note: ‘do_move’ was previously declared here
 inline void Position::do_move(Move m, StateInfo& newSt) {
             ^
position.h:817:13: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/tbprobe.h:50:10: warning: ‘probe_wdl’ violates the C++ One Definition Rule  [-Wodr]
 WDLScore probe_wdl(Position& pos, ProbeState* result);
          ^
syzygy/tbprobe.cpp:1348:10: note: type mismatch in parameter 1
 WDLScore Tablebases::probe_wdl(Position& pos, ProbeState* result) {
          ^
syzygy/../position.h:78:7: note: type ‘struct Position’ itself violates the C++ One Definition Rule
 class Position {
       ^
position.h:78:7: note: the incompatible type is defined here
 class Position {
       ^
syzygy/tbprobe.h:50:10: warning: ‘probe_wdl’ violates the C++ One Definition Rule  [-Wodr]
 WDLScore probe_wdl(Position& pos, ProbeState* result);
          ^
syzygy/tbprobe.cpp:1348:10: note: type mismatch in parameter 1
 WDLScore Tablebases::probe_wdl(Position& pos, ProbeState* result) {
          ^
syzygy/../position.h:78:7: note: type ‘struct Position’ itself violates the C++ One Definition Rule
 class Position {
       ^
position.h:78:7: note: the incompatible type is defined here
 class Position {
       ^
syzygy/tbprobe.cpp:1348:10: note: ‘probe_wdl’ was previously declared here
 WDLScore Tablebases::probe_wdl(Position& pos, ProbeState* result) {
          ^
syzygy/tbprobe.cpp:1348:10: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/tbprobe.h:51:5: warning: ‘probe_dtz’ violates the C++ One Definition Rule  [-Wodr]
 int probe_dtz(Position& pos, ProbeState* result);
     ^
syzygy/tbprobe.cpp:1380:5: note: type mismatch in parameter 1
 int Tablebases::probe_dtz(Position& pos, ProbeState* result) {
     ^
syzygy/../position.h:78:7: note: type ‘struct Position’ itself violates the C++ One Definition Rule
 class Position {
       ^
position.h:78:7: note: the incompatible type is defined here
 class Position {
       ^
syzygy/tbprobe.cpp:1380:5: note: ‘probe_dtz’ was previously declared here
 int Tablebases::probe_dtz(Position& pos, ProbeState* result) {
     ^
syzygy/tbprobe.cpp:1380:5: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/../position.h:201:8: warning: ‘undo_move’ violates the C++ One Definition Rule  [-Wodr]
   void do_move(Move m, StateInfo& newSt, bool givesCheck);
        ^
position.cpp:1245:6: note: implicit this pointer type mismatch
 void Position::undo_move(Move m) {
      ^
position.h:78:7: note: type ‘struct Position’ itself violates the C++ One Definition Rule
 class Position {
       ^
syzygy/../position.h:78:7: note: the incompatible type is defined here
 class Position {
       ^
position.cpp:1245:6: note: ‘undo_move’ was previously declared here
 void Position::undo_move(Move m) {
      ^
position.cpp:1245:6: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/../position.h:200:8: warning: ‘do_move’ violates the C++ One Definition Rule  [-Wodr]
   void do_move(Move m, StateInfo& newSt);
        ^
position.cpp:953:6: note: implicit this pointer type mismatch
 void Position::do_move(Move m, StateInfo& newSt, bool givesCheck) {
      ^
position.h:78:7: note: type ‘struct Position’ itself violates the C++ One Definition Rule
 class Position {
       ^
syzygy/../position.h:78:7: note: the incompatible type is defined here
 class Position {
       ^
position.cpp:953:6: note: ‘do_move’ was previously declared here
 void Position::do_move(Move m, StateInfo& newSt, bool givesCheck) {
      ^
position.cpp:953:6: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/../position.h:221:8: warning: ‘has_repeated’ violates the C++ One Definition Rule  [-Wodr]
   bool is_game_end(Value& result, int ply = 0) const;
        ^
position.cpp:1664:6: note: ‘has_repeated’ was previously declared here
 bool Position::has_repeated() const {
      ^
position.cpp:1664:6: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/../position.h:188:8: warning: ‘gives_check’ violates the C++ One Definition Rule  [-Wodr]
   bool capture_or_promotion(Move m) const;
        ^
position.cpp:884:6: note: type mismatch in parameter 1
 bool Position::gives_check(Move m) const {
      ^
types.h:128:6: note: type ‘Move’ itself violates the C++ One Definition Rule
 enum Move : int {
      ^
syzygy/../types.h:128:6: note: the incompatible type is defined here
 enum Move : int {
      ^
position.cpp:884:6: note: ‘gives_check’ was previously declared here
 bool Position::gives_check(Move m) const {
      ^
position.cpp:884:6: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/../position.h:88:13: warning: ‘set’ violates the C++ One Definition Rule  [-Wodr]
   Position& set(const std::string& code, Color c, StateInfo* si);
             ^
position.cpp:549:11: note: return value type mismatch
 Position& Position::set(const string& code, Color c, StateInfo* si) {
           ^
position.h:78:7: note: type ‘struct Position’ itself violates the C++ One Definition Rule
 class Position {
       ^
syzygy/../position.h:78:7: note: the incompatible type is defined here
 class Position {
       ^
position.cpp:549:11: note: ‘set’ was previously declared here
 Position& Position::set(const string& code, Color c, StateInfo* si) {
           ^
position.cpp:549:11: note: code may be misoptimized unless -fno-strict-aliasing is used
syzygy/../movegen.h:56:10: warning: ‘generate’ violates the C++ One Definition Rule  [-Wodr]
 ExtMove* generate(const Position& pos, ExtMove* moveList);
          ^
movegen.cpp:477:10: note: return value type mismatch
 ExtMove* generate<LEGAL>(const Position& pos, ExtMove* moveList) {
          ^
movegen.h:39:8: note: type ‘struct ExtMove’ itself violates the C++ One Definition Rule
 struct ExtMove {
        ^
syzygy/../movegen.h:39:8: note: the incompatible type is defined here
 struct ExtMove {
        ^
movegen.cpp:477:10: note: ‘generate’ was previously declared here
 ExtMove* generate<LEGAL>(const Position& pos, ExtMove* moveList) {
          ^
movegen.cpp:477:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:98:17: warning: type of ‘BetweenBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard BetweenBB[SQUARE_NB][SQUARE_NB];
                 ^
bitboard.cpp:35:10: note: array types have different bounds
 Bitboard BetweenBB[SQUARE_NB][SQUARE_NB];
          ^
bitboard.cpp:35:10: note: ‘BetweenBB’ was previously declared here
bitboard.cpp:35:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:99:17: warning: type of ‘LineBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard LineBB[SQUARE_NB][SQUARE_NB];
                 ^
bitboard.cpp:36:10: note: array types have different bounds
 Bitboard LineBB[SQUARE_NB][SQUARE_NB];
          ^
bitboard.cpp:36:10: note: ‘LineBB’ was previously declared here
bitboard.cpp:36:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:107:17: warning: type of ‘LeaperMoves’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard LeaperMoves[COLOR_NB][PIECE_TYPE_NB][SQUARE_NB];
                 ^
bitboard.cpp:44:10: note: array types have different bounds
 Bitboard LeaperMoves[COLOR_NB][PIECE_TYPE_NB][SQUARE_NB];
          ^
bitboard.cpp:44:10: note: ‘LeaperMoves’ was previously declared here
bitboard.cpp:44:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:105:17: warning: type of ‘PseudoMoves’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard PseudoMoves[COLOR_NB][PIECE_TYPE_NB][SQUARE_NB];
                 ^
bitboard.cpp:42:10: note: array types have different bounds
 Bitboard PseudoMoves[COLOR_NB][PIECE_TYPE_NB][SQUARE_NB];
          ^
bitboard.cpp:42:10: note: ‘PseudoMoves’ was previously declared here
bitboard.cpp:42:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:100:17: warning: type of ‘DistanceRingBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard DistanceRingBB[SQUARE_NB][FILE_NB];
                 ^
bitboard.cpp:37:10: note: array types have different bounds
 Bitboard DistanceRingBB[SQUARE_NB][FILE_NB];
          ^
bitboard.cpp:37:10: note: ‘DistanceRingBB’ was previously declared here
bitboard.cpp:37:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:92:17: warning: type of ‘BoardSizeBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard BoardSizeBB[FILE_NB][RANK_NB];
                 ^
bitboard.cpp:29:10: note: array types have different bounds
 Bitboard BoardSizeBB[FILE_NB][RANK_NB];
          ^
bitboard.cpp:29:10: note: ‘BoardSizeBB’ was previously declared here
bitboard.cpp:29:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:102:17: warning: type of ‘PassedPawnMask’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard PassedPawnMask[COLOR_NB][SQUARE_NB];
                 ^
bitboard.cpp:39:10: note: array types have different bounds
 Bitboard PassedPawnMask[COLOR_NB][SQUARE_NB];
          ^
bitboard.cpp:39:10: note: ‘PassedPawnMask’ was previously declared here
bitboard.cpp:39:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:103:17: warning: type of ‘PawnAttackSpan’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard PawnAttackSpan[COLOR_NB][SQUARE_NB];
                 ^
bitboard.cpp:40:10: note: array types have different bounds
 Bitboard PawnAttackSpan[COLOR_NB][SQUARE_NB];
          ^
bitboard.cpp:40:10: note: ‘PawnAttackSpan’ was previously declared here
bitboard.cpp:40:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:101:17: warning: type of ‘ForwardFileBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard ForwardFileBB[COLOR_NB][SQUARE_NB];
                 ^
bitboard.cpp:38:10: note: array types have different bounds
 Bitboard ForwardFileBB[COLOR_NB][SQUARE_NB];
          ^
bitboard.cpp:38:10: note: ‘ForwardFileBB’ was previously declared here
bitboard.cpp:38:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:97:17: warning: type of ‘ForwardRanksBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard ForwardRanksBB[COLOR_NB][RANK_NB];
                 ^
bitboard.cpp:34:10: note: array types have different bounds
 Bitboard ForwardRanksBB[COLOR_NB][RANK_NB];
          ^
bitboard.cpp:34:10: note: ‘ForwardRanksBB’ was previously declared here
bitboard.cpp:34:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:96:17: warning: type of ‘AdjacentFilesBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard AdjacentFilesBB[FILE_NB];
                 ^
bitboard.cpp:33:10: note: array types have different bounds
 Bitboard AdjacentFilesBB[FILE_NB];
          ^
bitboard.cpp:33:10: note: ‘AdjacentFilesBB’ was previously declared here
bitboard.cpp:33:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:94:17: warning: type of ‘FileBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard FileBB[FILE_NB];
                 ^
bitboard.cpp:31:10: note: array types have different bounds
 Bitboard FileBB[FILE_NB];
          ^
bitboard.cpp:31:10: note: ‘FileBB’ was previously declared here
bitboard.cpp:31:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:95:17: warning: type of ‘RankBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard RankBB[RANK_NB];
                 ^
bitboard.cpp:32:10: note: array types have different bounds
 Bitboard RankBB[RANK_NB];
          ^
bitboard.cpp:32:10: note: ‘RankBB’ was previously declared here
bitboard.cpp:32:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:135:14: warning: ‘RookMagics’ violates the C++ One Definition Rule  [-Wodr]
 extern Magic RookMagics[SQUARE_NB];
              ^
bitboard.cpp:46:7: note: array types have different bounds
 Magic RookMagics[SQUARE_NB];
       ^
bitboard.cpp:46:7: note: ‘RookMagics’ was previously declared here
bitboard.cpp:46:7: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:136:14: warning: ‘BishopMagics’ violates the C++ One Definition Rule  [-Wodr]
 extern Magic BishopMagics[SQUARE_NB];
              ^
bitboard.cpp:47:7: note: array types have different bounds
 Magic BishopMagics[SQUARE_NB];
       ^
bitboard.cpp:47:7: note: ‘BishopMagics’ was previously declared here
bitboard.cpp:47:7: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:106:17: warning: type of ‘LeaperAttacks’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard LeaperAttacks[COLOR_NB][PIECE_TYPE_NB][SQUARE_NB];
                 ^
bitboard.cpp:43:10: note: array types have different bounds
 Bitboard LeaperAttacks[COLOR_NB][PIECE_TYPE_NB][SQUARE_NB];
          ^
bitboard.cpp:43:10: note: ‘LeaperAttacks’ was previously declared here
bitboard.cpp:43:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:31:6: warning: ‘probe’ violates the C++ One Definition Rule  [-Wodr]
 bool probe(Square wksq, Square wpsq, Square bksq, Color us);
      ^
bitbase.cpp:76:6: note: type mismatch in parameter 1
 bool Bitbases::probe(Square wksq, Square wpsq, Square bksq, Color us) {
      ^
types.h:274:6: note: type ‘Square’ itself violates the C++ One Definition Rule
 enum Square : int {
      ^
bitbase.cpp:76:6: note: ‘probe’ was previously declared here
 bool Bitbases::probe(Square wksq, Square wpsq, Square bksq, Color us) {
      ^
bitboard.h:93:17: warning: type of ‘SquareBB’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard SquareBB[SQUARE_NB];
                 ^
bitboard.cpp:30:10: note: array types have different bounds
 Bitboard SquareBB[SQUARE_NB];
          ^
bitboard.cpp:30:10: note: ‘SquareBB’ was previously declared here
bitboard.cpp:30:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:104:17: warning: type of ‘PseudoAttacks’ does not match original declaration [-Wlto-type-mismatch]
 extern Bitboard PseudoAttacks[COLOR_NB][PIECE_TYPE_NB][SQUARE_NB];
                 ^
bitboard.cpp:41:10: note: array types have different bounds
 Bitboard PseudoAttacks[COLOR_NB][PIECE_TYPE_NB][SQUARE_NB];
          ^
bitboard.cpp:41:10: note: ‘PseudoAttacks’ was previously declared here
bitboard.cpp:41:10: note: code may be misoptimized unless -fno-strict-aliasing is used
bitboard.h:90:12: warning: type of ‘SquareDistance’ does not match original declaration [-Wlto-type-mismatch]
 extern int SquareDistance[SQUARE_NB][SQUARE_NB];
            ^
bitboard.cpp:27:5: note: array types have different bounds
 int SquareDistance[SQUARE_NB][SQUARE_NB];
     ^
bitboard.cpp:27:5: note: ‘SquareDistance’ was previously declared here
make[1]: Leaving directory '/home/tamas/Fairy-Stockfish/src'

Racing kings draw not forced by the engine

In position 1r3RK1/1kq1R3/8/8/8/8/2NnN3/1rb2B1n b - - 8 11 where white already reached rank 8 black can save/draw the game if hes next move is Ka8. Fairy-Stockfish wants to play Nd2xf1 instead. In positions like this engine eval shouldn't consider material or any other eval aspect except King rank bonus to force the shortest (1 move only) draw line.

S-chess

It would be nice to have S-chess support in Fairy-Stockfish.
Similar to Makruk, you "just" have to merge it from Seirawan-Stockfish 😉

Inconsistent handling of illegal moves

Some illegal moves in shogi, xiangqi, and janggi currently are handled as legal, but then adjudicated as losing. This is not fully consistent as some illegal moves are detected early and correctly identified as illegal, whereas others are just declared as losing, but the move itself is considered legal. The situations where this issue applies are:

  • Checkmate by shogi pawn drops
  • Perpetual check, illegal repetitions

Idea: Filter out such moves in pyffish.

  • It needs to be considered that there can be cases where the losing move is the only legal move.

More convenient CLI usage

Now that the xboard protocol is supported, it already is relatively simple to play variants that are not supported by any GUI on the command line. What is mainly missing is to print the current board position in order to not have to use a physical board. Communication could e.g. work similar to Sjaak, see below. Any opinions?

>xboard

>board on
 8r n b q k b n r 
 7p p p p p p p p 
 6                
 5                
 4                
 3                
 2P P P P P P P P 
 1R N B Q K B N R *
  a b c d e f g h 
>e2e4
{verbose search output}
move d7d5
 8r n b q k b n r 
 7p p p   p p p p 
 6                
 5      p         
 4        P       
 3                
 2P P P P   P P P 
 1R N B Q K B N R *
  a b c d e f g h 

Musketeer Chess

Dr Zied Haddad asked me about adding his variant to pychess site (or maybe a new server for him), but I think maintaining two *-Stockfish Python binding is the latest thing I want in my life. Not to mention the problems of WASM port needed for client side analysis planned in the future.
What do you think about merging musketeer support to Fairy from your Musketeer-Stockfish?

ianfab-Fairy-Stockfish-c9bbf18 bug

@ianfab the windows worker stopped with this error:

Step 1/4. Building instrumented executable ...
make ARCH=x86-64-modern COMP=mingw gcc-profile-make
make[1]: Entering directory '/c/users/42/appdata/local/temp/tmp53jjtr/ianfab-Fairy-Stockfish-c9bbf18/src'
make ARCH=x86-64-modern COMP=mingw \
EXTRACXXFLAGS='-fprofile-generate' \
EXTRALDFLAGS='-lgcov' \
all
make[2]: Entering directory '/c/users/42/appdata/local/temp/tmp53jjtr/ianfab-Fairy-Stockfish-c9bbf18/src'
...
g++ -march=native -Wall -Wcast-qual -fno-exceptions -std=c++11  -Wextra -Wshadow -DANTI -DATOMIC -DBUGHOUSE -DCRAZYHOUSE -DDISPLACEDGRID -DEXTINCTION -DGIVEAWAY -DGRID -DHORDE -DKOTH -DLOOP -DLOSERS -DPLACEMENT -DRACE -DSLIPPEDGRID -DSUICIDE -DTHREECHECK -DTWOKINGS -DTWOKINGSSYMMETRIC -DNDEBUG -O3 -DIS_64BIT -msse -msse3 -mpopcnt -DUSE_POPCNT -Wall -Wcast-qual -fno-exceptions -std=c++11  -Wextra -Wshadow -DANTI -DATOMIC -DBUGHOUSE -DCRAZYHOUSE -DDISPLACEDGRID -DEXTINCTION -DGIVEAWAY -DGRID -DHORDE -DKOTH -DLOOP -DLOSERS -DPLACEMENT -DRACE -DSLIPPEDGRID -DSUICIDE -DTHREECHECK -DTWOKINGS -DTWOKINGSSYMMETRIC -DNDEBUG -O3 -DIS_64BIT -msse -msse3 -mpopcnt -DUSE_POPCNT -Wall -Wcast-qual -fno-exceptions -std=c++11 -fprofile-generate -Wextra -Wshadow -DANTI -DATOMIC -DBUGHOUSE -DCRAZYHOUSE -DDISPLACEDGRID -DEXTINCTION -DGIVEAWAY -DGRID -DHORDE -DKOTH -DLOOP -DLOSERS -DPLACEMENT -DRACE -DSLIPPEDGRID -DSUICIDE -DTHREECHECK -DTWOKINGS -DTWOKINGSSYMMETRIC -DNDEBUG -O3 -DIS_64BIT -msse -msse3 -mpopcnt -DUSE_POPCNT   -c -o syzygy/tbprobe.o syzygy/tbprobe.cpp
thread.cpp: In constructor 'Thread::Thread(size_t)':
thread.cpp:44:33: error: no matching function for call to 'NativeThread::NativeThread()'
   44 | Thread::Thread(size_t n) : idx(n) {
      |                                 ^
In file included from thread.h:39,
                 from thread.cpp:26:
thread_win32_osx.h:53:12: note: candidate: 'template<class T, class P> NativeThread::NativeThread(void (T::*)(), T*)'
   53 |   explicit NativeThread(void(T::*fun)(), T* obj) {
      |            ^~~~~~~~~~~~
thread_win32_osx.h:53:12: note:   template argument deduction/substitution failed:
thread.cpp:44:33: note:   candidate expects 2 arguments, 0 provided
   44 | Thread::Thread(size_t n) : idx(n) {
      |                                 ^
In file included from thread.h:39,
                 from thread.cpp:26:
thread_win32_osx.h:47:7: note: candidate: 'constexpr NativeThread::NativeThread(const NativeThread&)'
   47 | class NativeThread {
      |       ^~~~~~~~~~~~
thread_win32_osx.h:47:7: note:   candidate expects 1 argument, 0 provided
thread_win32_osx.h:47:7: note: candidate: 'constexpr NativeThread::NativeThread(NativeThread&&)'
thread_win32_osx.h:47:7: note:   candidate expects 1 argument, 0 provided
thread.cpp:47:51: error: no match for 'operator=' (operand types are 'NativeThread' and 'std::thread')
   47 |   stdThread = std::thread(&Thread::idle_loop, this);
      |                                                   ^
In file included from thread.h:39,
                 from thread.cpp:26:
thread_win32_osx.h:47:7: note: candidate: 'NativeThread& NativeThread::operator=(const NativeThread&)'
   47 | class NativeThread {
      |       ^~~~~~~~~~~~
thread_win32_osx.h:47:7: note:   no known conversion for argument 1 from 'std::thread' to 'const NativeThread&'
thread_win32_osx.h:47:7: note: candidate: 'NativeThread& NativeThread::operator=(NativeThread&&)'
thread_win32_osx.h:47:7: note:   no known conversion for argument 1 from 'std::thread' to 'NativeThread&&'
make[2]: *** [<builtin>: thread.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory

gcc version:

$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-9.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++ --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --enable-plugin --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 9.2.0 (Rev2, Built by MSYS2 project)

Large boards version issues illegal moves in PV

Since 6aab09c cutechess reports dozens of illegal moves in PVs at least for standard chess. Version 9e617f4 does not issue any (AFAICS) illegal moves.

The problematic moves have target squares outside the board.

<stockfish-large-6aab09c(37): info depth 10 seldepth 16 multipv 1 score cp -20 nodes 1888 nps 269714 tbhits 0 time 7 pv g8f6 e1g1 f8c5 b5c6 d7c6 d2d3 d8e7 c1d2 c8g4 h2h3 g4f3 d1f3 f6d7
<stockfish-large-6aab09c(37): info depth 11 seldepth 21 multipv 1 score cp -25 nodes 10921 nps 280025 tbhits 0 time 39 pv g8f6 e1g1 f8c5 c2c3 e8g8 d2d4 c5b6 c1g5 e5d4 e4e5 h7h6 g5f6 g7f6 f3d4 c6d4 d1g4 g8h8 c3d4 d7d5 g4l4 h8g7

LARGEBOARDS compiled with msvc running error

When compiled with msvc using LARGEBOARDS, it seems running unlimitted time. When run into the Bitbases::init() or Threads.set(Options["Threads"]) in main(), the error occurs, throws "access conflict at 0x000000000085C070", stop at the line:
repeat |= (db[idx] == UNKNOWN && db[idx].classify(db) != UNKNOWN);
when comment line Bitbases::init() , the error throws within set_state( ) module,throws "access conflict at 0x000000009F71798C" stop at the line
si->key ^= Zobrist::psq[pc][s];

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.