| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Ondrej Mosnáček
Date: Tue Mar 27 17:08:08 2018 +0200 Timestamp: 1522163288 Refactor tbprobe.cpp This involves: * replacing the union hacks with simply reusing the EntryPiece arrays for the no-pawns case * merging the PairsData structure with the EntryPiece/-Pawn structs (with credit to Marco: @mcostalba) * simplifying some HashTable functions * thanks to previous changes, removing the ugly memsets * simplifying the template logic for WDL/DTZ distinction (now we distinguish based on an enum type, not the entry classes) * removing the unneeded Atomic wrapper ----------------------------- For reference, here is a manual way to check that patches concerning table bases code are non-functional changes: 0) Download the Syzygy table bases (up to 6 men). 1) Make sure you have branches master and the pull request pointing to the right commits. 2) Download the bench calculation scripts from the following URL: https://gist.github.com/WOnder93/b5fcf9c989b4a1715684d5c82367cdbe and copy into src inside your Stockfish repo. 3) Make the scripts executable (chmod +x *.sh). 4) Run the following command to use TBs located at <path>: export SYZYGY_PATH='<path>' 5) After that, run this (it will take a long time, this is a deep bench): BENCH_ARGS='128 1 22' ./check_benches.sh master tbprobe_cleanup 2>/dev/null` ==> You should see two equal numbers printed. (Of course, now we have to trust that the script itself is correct :) ----------------------------- Closes https://github.com/official-stockfish/Stockfish/pull/1477 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Marco Costalba
Date: Tue Mar 27 16:45:12 2018 +0200 Timestamp: 1522161912 Fix indentation in movepicker.cpp Fix indentation in movepicker.cpp and evaluate.cpp. Also move the PickType enum out of global space. No functional change |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Stéphane Nicolet
Date: Tue Mar 27 16:25:41 2018 +0200 Timestamp: 1522160741 Switch time management to 64 bits This is a patch to fix issue #1498, switching the time management variables to 64 bits to avoid overflow of time variables after 25 days. There was a bug in Stockfish 9 causing the output to be wrong after 2^31 milliseconds search. Here is a long run from the starting position: info depth 64 seldepth 87 multipv 1 score cp 23 nodes 13928920239402 nps 0 tbhits 0 time -504995523 pv g1f3 d7d5 d2d4 g8f6 c2c4 d5c4 e2e3 e7e6 f1c4 c7c5 e1g1 b8c6 d4c5 d8d1 f1d1 f8c5 c4e2 e8g8 a2a3 c5e7 b2b4 f8d8 b1d2 b7b6 c1b2 c8b7 a1c1 a8c8 c1c2 c6e5 d1c1 c8c2 c1c2 e5f3 d2f3 a7a5 b4b5 e7c5 f3d4 d8c8 d4b3 c5d6 c2c8 b7c8 b3d2 c8b7 d2c4 d6c5 e2f3 b7d5 f3d5 e6d5 c4e5 a5a4 e5d3 f6e4 d3c5 e4c5 b2d4 c5e4 d4b6 e4d6 g2g4 d6b5 b6c5 b5c7 g1g2 c7e6 c5d6 g7g6 We check at compile time that the TimePoint type is exactly 64 bits long for the compiler (TimePoint is our alias in Stockfish for std::chrono::milliseconds -- it is a signed integer type of at least 45 bits according to the C++ standard, but will most probably be implemented as a 64 bits signed integer on modern compilers), and we use this TimePoint type consistently across the code. Bug report by user "fischerandom" on the TCEC chat (thanks), and the patch includes code and suggestions by user "WOnder93" and Ronald de Man. Fixes issue: https://github.com/official-stockfish/Stockfish/issues/1498 Closes pull request: https://github.com/official-stockfish/Stockfish/pull/1510 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Jerry Donald Watson
Date: Mon Mar 26 09:28:37 2018 +0200 Timestamp: 1522049317 Make kingRing always 8 squares Make kingRing always eight squares, extending the bitboard to the F file if the king is on the H file, and to the C file if the king is on the A file. This may deal with cases where Stockfish (like many other engines) would shift the king around on the back rank like g1h1, not because there is some imminent threat, but because it makes king safety look a little better just because the king ring had a smaller area. STC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 34000 W: 7167 L: 6877 D: 19956 http://tests.stockfishchess.org/tests/view/5ab8216d0ebc5902932cbe64 LTC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 22574 W: 3576 L: 3370 D: 15628 http://tests.stockfishchess.org/tests/view/5ab84e6a0ebc5902932cbe72 How to continue from there? This patch probably makes it easier to tune the king safety evaluation, because the new regularity of the king ring size will make the king safety function more continuous. Closes https://github.com/official-stockfish/Stockfish/pull/1512 Bench: 5934103 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Chess13234
Date: Sat Mar 24 08:59:48 2018 +0100 Timestamp: 1521878388 IID margin reduced to 128 Change the internal iterative deepening margin from +256 to +128. Passed STC: LLR: 3.26 (-2.94,2.94) [0.00,5.00] Total: 22006 W: 4646 L: 4400 D: 12960 http://tests.stockfishchess.org/tests/view/5ab54a240ebc590295d8847d Passed LTC: LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 46665 W: 7187 L: 6898 D: 32580 http://tests.stockfishchess.org/tests/view/5ab5ba690ebc590295d884b4 Possible work in this area after this change: • Reduce even more the margin? • Try to do IID for smaller depths too? Bench: 5851102 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Joost VandeVondele
Date: Wed Mar 21 01:48:47 2018 +0100 Timestamp: 1521593327 Join refutation stages in the movepicker Unifies a bit further the three refuation stages in the MovePicker class. Also treat the skipping of TT move now always via select_move(), as discussed in pull request #1454. Passed STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 16608 W: 3461 L: 3331 D: 9816 http://tests.stockfishchess.org/tests/view/5ab0aaf00ebc59029fb6f6c3 Closes https://github.com/official-stockfish/Stockfish/pull/1502 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: DU-jdto
Date: Wed Mar 21 01:35:05 2018 +0100 Timestamp: 1521592505 Fix a few minor code style inconsistencies No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Joost VandeVondele
Date: Mon Mar 19 00:59:30 2018 +0100 Timestamp: 1521417570 Join common code in the stages of next_move() Rewrite the MovePicker class using lambda expressions for move filtering. Includes code style changes by @mcostalba. Verified for speed, passed STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 43191 W: 9391 L: 9312 D: 24488 http://tests.stockfishchess.org/tests/view/5a99b9df0ebc590297cc8f04 This rewrite of MovePicker.cpp seems to trigger less random crashes on Ryzen machines than the version in previous master (reported by Bojun Guo). Closes https://github.com/official-stockfish/Stockfish/pull/1454 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Joost VandeVondele
Date: Mon Mar 19 00:17:08 2018 +0100 Timestamp: 1521415028 Simplify razoring logic passed STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 36574 W: 7523 L: 7430 D: 21621 http://tests.stockfishchess.org/tests/view/5aae11450ebc590299abf52f No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Ronald de Man
Date: Sun Mar 18 23:48:16 2018 +0100 Timestamp: 1521413296 Mark all compile-time constants as constexpr. To more clearly distinguish them from "const" local variables, this patch defines compile-time local constants as constexpr. This is consistent with the definition of PvNode as constexpr in search() and qsearch(). It also makes the code more robust, since the compiler will now check that those constants are indeed compile-time constants. We can go even one step further and define all the evaluation and search compile-time constants as constexpr. In generate_castling() I replaced "K" with "step", since K was incorrectly capitalised (in the Chess960 case). In timeman.cpp I had to make the non-local constants MaxRatio and StealRatio constepxr, since otherwise gcc would complain when calculating TMaxRatio and TStealRatio. (Strangely, I did not have to make Is64Bit constexpr even though it is used in ucioption.cpp in the calculation of constexpr MaxHashMB.) I have renamed PieceCount to pieceCount in material.h, since the values of the array are not compile-time constants. Some compile-time constants in tbprobe.cpp were overlooked. Sides and MaxFile are not compile-time constants, so were renamed to sides and maxFile. Non-functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: mstembera
Date: Fri Mar 16 22:37:03 2018 +0100 Timestamp: 1521236223 Fix an MSVC 2017 error and warnings. Improved version by @mcostalba. No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Stéphane Nicolet
Date: Thu Mar 15 10:44:26 2018 +0100 Timestamp: 1521107066 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. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Joost VandeVondele
Date: Thu Mar 15 09:25:59 2018 +0100 Timestamp: 1521102359 Make using quiescence search implicit If search depth is less than ONE_PLY call qsearch(), no need to check the depth condition at various call sites of search(). Passed STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 14568 W: 3011 L: 2877 D: 8680 http://tests.stockfishchess.org/tests/view/5aa846190ebc59029781015b Also helps gcc to find some optimizations (smaller binary, some speedup). Thanks to Aram and Stefan for identifying an oversight in an early version. Closes https://github.com/official-stockfish/Stockfish/pull/1487 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Stéphane Nicolet
Date: Wed Mar 14 22:01:58 2018 +0100 Timestamp: 1521061318 Check the clock every 1024 nodes This patch checks the clock every 1024, instead of 4096 in current master. This is a step towards a solution to alleviate the problem reported by Gian-Carlo Pascutto in pull request #1471, about a situation where SF would sometimes lose on time in endgames at time control 1min+1sec when using Syzygy EGTB on a spinning drive. We made four tests called "Estimate the Elo cost of calling now() every N nodes", with N in {256,1024} and time control in {STC,LTC}. Each test was 40000 games with auto-purge off, against master branch. http://tests.stockfishchess.org/tests/view/5aa4f37c0ebc59029780ff2d http://tests.stockfishchess.org/tests/view/5aa4f3080ebc59029780ff2b http://tests.stockfishchess.org/tests/view/5aa5cbb50ebc59029780ffce http://tests.stockfishchess.org/tests/view/5aa5cb730ebc59029780ffcc Here is a summary of the results (speed-up and Elo gain against master): | Time | N=256 | N=1024 | |:--------:|:-----------------:|:----------------:| | Speed-up | 0.1% slower | 0.2% faster | | STC | -0.33 +-2.2 Elo | 1.33 +-2.2 Elo | | LTC | 1.08 +-2.3 Elo | 2.34 +-2.2 Elo | Based on these results, we tested N=1024 as a non-regression against master at LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 80746 W: 12430 L: 12399 D: 55917 http://tests.stockfishchess.org/tests/view/5aa7ba660ebc590297810116 Closes https://github.com/official-stockfish/Stockfish/pull/1482 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: lucasart
Date: Wed Mar 14 01:31:21 2018 +0100 Timestamp: 1520987481 Use intrinsics only for LSB/MSB The NO_BSF does not cover any real life use-case today. The only compilers that can compile SF today, with the current Makefile and no source code changes, are either GCC compatible (define __GNUC__) or MSVC compatible (define _MSC_VER). So they all support LSB/MSB intrinsics. This patch simplifies away the software fall-backs of LSB/MSB that were still in Stockfish code, but unused in any of the officially supported compilers. Note the (legacy) MSVC/WIN32 case, where we use a 32-bit BSF/BSR solution, as 64-bit intrinsics aren't available there. Discussed in: https://github.com/official-stockfish/Stockfish/pull/1447 and: https://github.com/official-stockfish/Stockfish/pull/1479 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Jerry Donald Watson
Date: Tue Mar 13 23:32:45 2018 +0100 Timestamp: 1520980365 Simplify condition for ProbCut move count pruning We retire depth-dependence in ProbCut move count pruning, the move count limit condition is now : "probCutCount < 3" STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 33895 W: 6995 L: 6897 D: 20003 http://tests.stockfishchess.org/tests/view/5aa6eaba0ebc59029781009d LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 28959 W: 4441 L: 4333 D: 20185 http://tests.stockfishchess.org/tests/view/5aa73dfa0ebc5902978100be Ideas for future work: • Is a flat move count limit in ProbCut ideal? Depth dependence, or dependence on some other variable, could possibly be reintroduced. • The move count limit 3 is untuned and a better value may exist. Closes https://github.com/official-stockfish/Stockfish/pull/1486 Bench: 5741807 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Jerry Donald Watson
Date: Tue Mar 13 23:21:46 2018 +0100 Timestamp: 1520979706 Tweak probcut margin with 'improving' flag Adjust ProbCut rBeta by whether the score is improving, and also set improving to false when in check. More precisely, this patch has two parts: 1) the increased beta threshold for ProbCut is now adjusted based on whether the score is improving 2) when in check, improving is always set to false. Co-authored by Joost VandeVondele (@vondele) and Bill Henry (@VoyagerOne). STC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 13480 W: 2840 L: 2648 D: 7992 http://tests.stockfishchess.org/tests/view/5aa693fe0ebc59029781004c LTC: LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 25895 W: 4099 L: 3880 D: 17916 http://tests.stockfishchess.org/tests/view/5aa6ac940ebc59029781006e In terms of opportunities for future work opened up by this patch, the ProbCut rBeta formula could probably be tuned to gain more Elo. Closes https://github.com/official-stockfish/Stockfish/pull/1485 Bench: 5328254 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: VoyagerOne
Date: Tue Mar 13 08:21:11 2018 +0100 Timestamp: 1520925671 Use quiescence search for Probcut Perform qsearch for the preliminary search in Probcut Passed STC with sprt[-3..1] bounds: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 31090 W: 6386 L: 6283 D: 18421 http://tests.stockfishchess.org/tests/view/5aa598ed0ebc59029780ff9f Passed LTC with sprt[0..4] bounds: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 104056 W: 15990 L: 15531 D: 72535 http://tests.stockfishchess.org/tests/view/5aa5b0f30ebc59029780ffa9 Closes https://github.com/official-stockfish/Stockfish/pull/1483 Bench: 5404567 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Joost VandeVondele
Date: Tue Mar 13 08:13:26 2018 +0100 Timestamp: 1520925206 qsearch(): remove inCheck as a template parameter Simplifies a bit, and avoids bugs as in #1478 Passed STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 104862 W: 21302 L: 21337 D: 62223 http://tests.stockfishchess.org/tests/view/5aa6de1b0ebc590297810097 Closes https://github.com/official-stockfish/Stockfish/pull/1484 No functional change |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Jerry Donald Watson
Date: Mon Mar 12 22:57:21 2018 +0100 Timestamp: 1520891841 Adjust initiative in pure pawn endgames King and pawn endgames are typically decisive, and a small advantage is often sufficient to win. Therefore we now take this into account when computing the initiative adjustment. This idea came from a series of patches by Gian-Carlo Pascutto. STC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 48770 W: 10203 L: 9845 D: 28722 http://tests.stockfishchess.org/tests/view/5aa58cce0ebc59029780ff8d LTC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 22252 W: 3572 L: 3366 D: 15314 http://tests.stockfishchess.org/tests/view/5aa5b27c0ebc59029780ffad Ideas for future developement: - There have been a number of changes to the initiative calculation lately. Perhaps the coefficients could be tuned again. - It may be possible to add special knowledge for other endgames in the initiative calculation. Closes https://github.com/official-stockfish/Stockfish/pull/1481 Bench: 5750110 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: protonspring
Date: Mon Mar 12 02:49:14 2018 +0100 Timestamp: 1520819354 MovePicker: combine countermove with killers. Handle the countermove in the same way we use stages to progress through the killer moves, using a common array called "refutations". Removes some lines of code and simplifies a bit the jump table. STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 71707 W: 14622 L: 14595 D: 42490 http://tests.stockfishchess.org/tests/view/5aa003cf0ebc590297cb6276 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 22320 W: 3470 L: 3352 D: 15498 http://tests.stockfishchess.org/tests/view/5aa051020ebc590297cb62ba Closes https://github.com/official-stockfish/Stockfish/pull/1468 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: protonspring
Date: Mon Mar 12 01:52:12 2018 +0100 Timestamp: 1520815932 Connectivity Score S(3,1) is stronger than S(2,2) I believe my tests were conclusive enough to demonstrate that a connectivity score of S(3,1) is stronger than S(2,2). STC LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 16175 W: 3386 L: 3165 D: 9624 http://tests.stockfishchess.org/tests/view/5aa48b150ebc59029780fef6 LTC LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 98685 W: 15209 L: 14765 D: 68711 http://tests.stockfishchess.org/tests/view/5aa496f50ebc59029780fefa Bench 5601228 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: protonspring
Date: Sat Mar 10 12:04:03 2018 +0100 Timestamp: 1520679843 Implement an old Russian proverb "Loose pieces drop, in blitz keep everything protected" Adding a small S(2,2) bonus for knights, bishops, rooks, and queens that are "connected" to each other (in the sense that they are under attack by our own pieces) apparently is a good thing. It probably helps the pieces work together a bit better. STC LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 12317 W: 2655 L: 2467 D: 7195 http://tests.stockfishchess.org/tests/view/5aa2d86b0ebc590297cb6474 LTC LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 35725 W: 5516 L: 5263 D: 24946 http://tests.stockfishchess.org/tests/view/5aa2fc6f0ebc590297cb64a8 How to continue from there (by Stefan Geschwentner)? • First we should identify all other eval terms which have an overlap with new connectivity bonus (like the outpost bonus). A simple way would be subtract the connectivity bonus from them and look if this better, or use a SPSA session for these terms. • Tuning Connectivity himself with SPSA seems not so promising because of the small range which is useful. Here manual testing changes of Connectivity like +-1 seems better. • The eg value is more important because in endgame the position gets more open and so attacks on pieces are easier. Another important point is that when defending/fortress-like positions each defending piece needs a protection, otherwise attacks on them can break defense. Closes https://github.com/official-stockfish/Stockfish/pull/1474 Bench: 5318575 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Joost VandeVondele
Date: Sat Mar 10 11:06:53 2018 +0100 Timestamp: 1520676413 Assign improving only once Avoid duplicated code after recent commit "Use evaluation trend to adjust futility margin". We initialize the improving variable to true in the check case, which allows to avoid redundant code in the general case. Tested for speed by snicolet, patch seems about 0.4% faster. No functional change. Note: initializing the improving variable to false in the check case was tested as a functional change, ending yellow in both STC and LTC. This change is not included in the commit, but it is an interesting result that could become part of a future patch about improving or LMR. Reference of the LTC yellow test: http://tests.stockfishchess.org/tests/view/5aa131560ebc590297cb636e |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Alain SAVARD
Date: Fri Mar 9 21:47:44 2018 +0100 Timestamp: 1520628464 Two steps slider threats on queen Allow a potential slider threat from a square currently occupied by a harmless attacker, just as the recent "knight on queen" patch. Also from not completely safe squares, use the mobilityArea instead of excluding all pawns for both SlidersOnQueen and KnightOnQueen We now compute the potential sliders threat on queen only if opponent has one queen. Run as SPRT [0,4] since it is some kind of simplification but maybe not clearly one. STC: http://tests.stockfishchess.org/tests/view/5aa1ddf10ebc590297cb63d8 LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 22997 W: 4817 L: 4570 D: 13610 LTC: http://tests.stockfishchess.org/tests/view/5aa1fe6b0ebc590297cb63e5 LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 11926 W: 1891 L: 1705 D: 8330 After this patch is committed, we may try to: • re-introduce some "threat by queen" bonus to make Stockfish's queen more aggressive (attacking aspect) • introduce a concept of "queen overload" to force the opponent queen into passivity and protecting duties (defensive aspect) • more generally, re-tune the queen mobility array since patches in the last three months have affected a lot the location/activity of queens. Closes https://github.com/official-stockfish/Stockfish/pull/1473 bench: 5788691 |