| 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: candirufish
Date: Wed Jun 6 10:16:48 2018 +0200 Timestamp: 1528273008 Quiet move soft fail high bonus Extra bonus for quiet move creating a huge soft fail high (triggered in 21% of quiet bestmoves on a normal bench run). Pb00067 original idea using PawnValueMg. Passed STC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 138207 W: 28060 L: 27295 D: 82852 Elo +1.92 http://tests.stockfishchess.org/tests/view/5b14471b0ebc5902a81689c1 Passe LTC: LLR: 2.94 (-2.94,2.94) [0.00,5.00] Total: 157289 W: 23200 L: 22518 D: 111571 Elo +1.51 http://tests.stockfishchess.org/tests/view/5b149dde0ebc5902a8b41c5a bench: 4441320 see source |
| 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: Wed Jun 6 09:58:34 2018 +0200 Timestamp: 1528271914 Simplify capture bonus Simplify capture bonus by simply adding ONE_DEPTH instead of being dependent on BestValue. STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 24419 W: 4939 L: 4824 D: 14656 Elo +1.64 http://tests.stockfishchess.org/tests/view/5b16b2040ebc5963ba37e2a5 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 44560 W: 6524 L: 6438 D: 31598 Elo +0.67 http://tests.stockfishchess.org/tests/view/5b16ccc00ebc59214346d403 Closes https://github.com/official-stockfish/Stockfish/pull/1640 Bench: 4782637 see source |
| 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 Jun 5 18:15:54 2018 +0200 Timestamp: 1528215354 Call cycle detection before qsearch() This has the property of raising alpha before calling qsearch(), thus maybe giving some more cuts during qsearch(). The patch is equivalent to the use of cycle detection inside qsearch() at depth 0, but is in fact implemented by re-ordering code inside search(), which explains the [0..4] bounds in the following tests. STC (interrupted after 124250 games, with LLR=0.87): http://tests.stockfishchess.org/tests/view/5b1500bd0ebc5902a8b420bf LLR: 0.87 (-2.94,2.94) [0.00,4.00] Total: 124250 W: 24973 L: 24470 D: 74807 Elo +1.41 LTC: http://tests.stockfishchess.org/tests/view/5b1590eb0ebc5902a84dcd09 LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 74234 W: 11098 L: 10733 D: 52403 Elo +1.71 Closes https://github.com/official-stockfish/Stockfish/pull/1635 Bench: 4326784 see source |
| 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 Jun 5 18:06:13 2018 +0200 Timestamp: 1528214773 Stabilize AppVeyor CI After a helpful suggestion from AppVeyor support staff, moving the Stockfish execution from ps to cmd seems to work. Alternative to PR #1624 tested in PR #1637. No functional change. see source |
| 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: Guenther Demetz
Date: Tue Jun 5 10:10:32 2018 +0200 Timestamp: 1528186232 Remove a superfluous subtrahend The '- 1' subtrahend was introduced for guarding against null move search at root, which would be nonsense. But this is actually already guaranteed by the !PvNode condition. This followed from the discussion in pull request 1609: https://github.com/official-stockfish/Stockfish/pull/1609 No functional change see source |
| 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 Jun 5 09:58:10 2018 +0200 Timestamp: 1528185490 Simplify LMR for captures Simplify LMR for captures by removing capture's stat score logic for reduction. STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 37068 W: 7462 L: 7370 D: 22236 Elo +0.86 http://tests.stockfishchess.org/tests/view/5b115bc30ebc591af58a6fd2 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 80061 W: 11706 L: 11671 D: 56684 Elo +0.15 http://tests.stockfishchess.org/tests/view/5b117f590ebc59033d2d5315 Closes https://github.com/official-stockfish/Stockfish/pull/1631 Bench: 4470519 see source |
| 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: joergoster
Date: Mon Jun 4 07:45:12 2018 +0200 Timestamp: 1528091112 Bugfix of Position::has_repeated() The function Position::has_repeated() is used by Tablebases::root_probe() to determine whether we can rank all winning moves with the same value, or if we need to strictly rank by dtz in case the position has already been repeated once, and we are risking to run into the 50-move rule and thus losing the win (especially critical in some very complicated endgames). To check whether the current position or one of the previous positions after the last zeroing move has already been occured once, we start looking for a repetition of the current position, and if that is not the case, we step one position back and repeat the check for that position, and so on. If you now look at how this was done before the new root ranking patch was merged two months ago, it seems quite obvious that it is a simple oversight: https://github.com/official-stockfish/Stockfish/commit/108f0da4d7f993732aa2e854b8f3fa8ca6d3b46c More specifically, after we stepped one position back with ``` stc = stc->previous; ``` we now have to start checking for a repetition with ``` StateInfo* stp = stc->previous->previous; ``` and not with ``` StateInfo* stp = st->previous->previous; ``` Closes https://github.com/official-stockfish/Stockfish/pull/1625 No functional change see source |
| 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: Sun Jun 3 09:19:13 2018 +0200 Timestamp: 1528010353 Fix overload ambiguity Fix an error when compiling current master with MSVC due to the ambiguity of which operator* overload was intended (reported by Jarrod Torriero). No functional change. see source |
| 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: pb00068
Date: Sat Jun 2 18:02:35 2018 +0200 Timestamp: 1527955355 Extra bonus for capture creating a huge fail high STC: http://tests.stockfishchess.org/tests/view/5b114f3d0ebc596e9e0881f6 LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 13007 W: 2730 L: 2541 D: 7736 Elo +5.05 LTC: http://tests.stockfishchess.org/tests/view/5b1176740ebc59033d2d52c6 LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 15594 W: 2417 L: 2239 D: 10938 Elo +3.97 See https://github.com/official-stockfish/Stockfish/pull/1627 Bench: 4790240 see source |
| 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: Sat Jun 2 17:41:37 2018 +0200 Timestamp: 1527954097 Fix comments, rename variables Thanks everybody for the various hints in the perpetual renaming thread: https://github.com/official-stockfish/Stockfish/issues/1426 No functional change see source |
| 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 Jun 2 17:03:01 2018 +0200 Timestamp: 1527951781 Reallocate TT on threadpool resize. Makes sure the potential benefit of first touch does not depend on the order of the UCI commands Threads and Hash, by reallocating the hash if a Threads is issued. The cost is zeroing the TT once more than needed. In case the prefered order (first Threads than Hash) is employed, this amounts to zeroing the default sized TT (16Mb), which is essentially instantaneous. Follow up for https://github.com/official-stockfish/Stockfish/pull/1601 where additional data and discussion is available. Closes https://github.com/official-stockfish/Stockfish/pull/1620 No functional change. see source |
| 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 May 30 13:38:11 2018 +0200 Timestamp: 1527680291 Simplify depth reduction in IID. Use a constant reduction instead of a depth dependent reduction. passed STC: http://tests.stockfishchess.org/tests/view/5b06eb600ebc5914abc12ba8 LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 58086 W: 11710 L: 11657 D: 34719 Elo +0.32 passed LTC: http://tests.stockfishchess.org/tests/view/5b07b25e0ebc5914abc12c6d LLR: 3.09 (-2.94,2.94) [-3.00,1.00] Total: 110414 W: 16217 L: 16219 D: 77978 Elo -0.01 Bench: 4521056 see source |
| 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: Rodrigo Exterckötter Tjäder
Date: Wed May 30 13:07:18 2018 +0200 Timestamp: 1527678438 Use threads to clear the TT faster. Stockfish currently takes a while to clear the TT when using larger hash sizes. On one machine with 128 GB hash it takes about 50 seconds with a single thread, allowing it to use all allocated cores brought that time down to 4 seconds on some Linux systems. The patch was further tested on Windows and refined with NUMA binding of the hash initializing threads (we refer to pull request #1601 for the complete discussion and the speed measurements). Closes https://github.com/official-stockfish/Stockfish/pull/1601 No functional change see source |
| 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: Thu May 24 19:06:24 2018 +0200 Timestamp: 1527181584 LMR Capture Tweak Increase capture reduction by comparing opponent's stat score STC: (Yellow) LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 92291 W: 18647 L: 18350 D: 55294 Elo +1.12 http://tests.stockfishchess.org/tests/view/5b04225e0ebc5914abc1291b LTC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 20176 W: 3061 L: 2868 D: 14247 Elo +3.32 http://tests.stockfishchess.org/tests/view/5b04bb3f0ebc5914abc129a3 How to continue? • we could try a different value for the capture history threeshold Closes https://github.com/official-stockfish/Stockfish/pull/1612 Bench: 5167159 see source |
| 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: Thu May 24 18:46:55 2018 +0200 Timestamp: 1527180415 Simplify BlockedByPawn to one dimension I was able to get this to pass which reduces BlockedByPawn to one dimension with NO distance from edge offset. GOOD) It's more simple and may provide additional clarity for further simplifications. Facilitates migrating unblocked to one dimension as well. BAD) If there is indeed a distance component to BlockedStorm (may or may not be the case), this obfuscates this component into ShelterStrength and UnblockedStorm. This may be more convoluted. Also, it may be more convenient to have each of the three arrays (ShelterStrength, BlockedStorm, and UnBlocked) be the same size. STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 96173 W: 19326 L: 19343 D: 57504 Elo -0.06 http://tests.stockfishchess.org/tests/view/5b04544d0ebc5914abc12965 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 49818 W: 7441 L: 7363 D: 35014 Elo +0.54 http://tests.stockfishchess.org/tests/view/5b0487d50ebc5914abc12990 Closes https://github.com/official-stockfish/Stockfish/pull/1611 Bench: 5133208 see source |
| 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 May 24 18:26:34 2018 +0200 Timestamp: 1527179194 Correctly prevent recursive verification in nmp. As discussed with @pb00068, the condition to prevent recursive verification was not completely correct. This patch corrects that condition, and adds an assert. In the current implementation, recursive verification needs to be avoided in order not to break the verification of the move closer to the root (i.e. to not set thisThread->nmp_min_ply to zero prematurely). This patch is tested as a bug fix, based on and tested against PR #1609 . passed STC: http://tests.stockfishchess.org/tests/view/5b050f170ebc5914abc129c5 LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 7875 W: 1669 L: 1523 D: 4683 Elo +6.44 passed LTC: http://tests.stockfishchess.org/tests/view/5b0513970ebc5914abc129cd LLR: 3.00 (-2.94,2.94) [-3.00,1.00] Total: 24048 W: 3525 L: 3407 D: 17116 Elo +1.70 Bench changes at high depth. Closes https://github.com/official-stockfish/Stockfish/pull/1610 and https://github.com/official-stockfish/Stockfish/pull/1609 Bench: 4484288 see source |
| 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 May 22 22:43:17 2018 +0200 Timestamp: 1527021797 Simplify color usage in search. define Color us and use this instead of pos.side_to_move() and nmp_odd. The latter allows to clarify the nmp verification criterion. Tested for no regression: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 76713 W: 15303 L: 15284 D: 46126 Elo +0.09 http://tests.stockfishchess.org/tests/view/5b046a0d0ebc5914abc12971 No functional change. see source |
| 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 May 22 07:23:04 2018 +0200 Timestamp: 1526966584 Simply reset StatScore to zero at beta cutoff STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 43154 W: 8706 L: 8625 D: 25823 Elo +0.65 http://tests.stockfishchess.org/tests/view/5b01a7660ebc5914abc1271d LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 48155 W: 7036 L: 6955 D: 34164 Elo +0.58 http://tests.stockfishchess.org/tests/view/5b01b2e50ebc5914abc1272c Closes https://github.com/official-stockfish/Stockfish/pull/1608 Bench: 4484288 see source |
| 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 May 21 09:51:05 2018 +0200 Timestamp: 1526889065 Simplify shelter: always do strength and danger This check of pawns before subtracting danger can be removed. STC LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 21174 W: 4361 L: 4239 D: 12574 Elo +2.00 http://tests.stockfishchess.org/tests/view/5b00b9f90ebc5914abc12680 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 56980 W: 8377 L: 8309 D: 40294 Elo +0.41 http://tests.stockfishchess.org/tests/view/5b00ca750ebc5914abc12683 Closes https://github.com/official-stockfish/Stockfish/pull/1607 Bench: 4746692 see source |
| 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: Mon May 21 09:37:44 2018 +0200 Timestamp: 1526888264 Simplifying away the progressKey Simplifying away all the progressKey stuff gives exactly the same bench, without any speed impact. Tested for speed against master with two benches at depth 22 ran in parallel: **testedpatch** Total time (ms) : 92350 Nodes searched : 178962949 Nodes/second : 1937877 **master** Total time (ms) : 92358 Nodes searched : 178962949 Nodes/second : 1937709 We also tested the patch at STC for no-regression with [-3, 1] bounds: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 57299 W: 11529 L: 11474 D: 34296 Elo +0.33 http://tests.stockfishchess.org/tests/view/5b015a1c0ebc5914abc126e5 Closes https://github.com/official-stockfish/Stockfish/pull/1603 No functional change. see source |
| 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: Wed May 16 23:40:23 2018 +0200 Timestamp: 1526506823 Fix MSVC errors in tbprobe.cpp Default template parameters values and recursive functions do not play well together. Fix for below errors that showed up after updating to latest MSVC. ```` tbprobe.cpp(1156): error C2672: 'search': no matching overloaded function found tbprobe.cpp(1198): error C2783: 'Tablebases::WDLScore `anonymous-namespace'::search(Position &,Tablebases::ProbeState *)': could not deduce template argument for 'CheckZeroingMoves' ```` Closes https://github.com/official-stockfish/Stockfish/pull/1594 No functional change. see source |
| 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: Tom Truscott
Date: Wed May 16 22:51:43 2018 +0200 Timestamp: 1526503903 Use cycle detection to bound search value A position which has a move which draws by repetition, or which could have been reached from an earlier position in the game tree, is considered to be at least a draw for the side to move. Cycle detection algorithm by Marcel van Kervink: https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf ---------------------------- How does the algorithm work in practice? The algorithm is an efficient method to detect if the side to move has a drawing move, without doing any move generation, thus possibly giving a cheap cutoffThe most interesting conditions are both on line 1195: ``` if ( originalKey == (progressKey ^ stp->key) || progressKey == Zobrist::side) ``` This uses the position keys as a sort-of Bloom filter, to avoid the expensive checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1. The XOR of this position's key with the starting position gives their difference, which can be used to look up black's repeating move (Ng8). But that look-up is expensive, so line 1195 checks that the white pieces are on their original squares. This is the subtlest part of the algorithm, but the basic idea in the above game is there are 4 positions (starting position and the one after each move). An XOR of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But since the difference in each pair is the location of the white knight those keys are "identical" (not quite because while there are 4 keys the the side to move changed 3 times, so the keys differ by Zobrist::side). The loop containing line 1195 does this pair-wise XOR-ing. Continuing the example, after line 1195 determines that the white pieces are back where they started we still need to make sure the changes in the black pieces represents a legal move. This is done by looking up the "moveKey" to see if it corresponds to possible move, and that there are no pieces blocking its way. There is the additional complication that, to match the behavior of is_draw(), if the repetition is not inside the search tree then there must be an additional repetition in the game history. Since a position can have more than one upcoming repetition a simple count does not suffice. So there is a search loop ending on line 1215. On the other hand, the "no-progress' is the same thing but offset by 1 ply. I like the concept but think it currently has minimal or negative benefit, and I'd be happy to remove it if that would get the patch accepted. This will not, however, save many lines of code. ----------------------------- STC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 36430 W: 7446 L: 7150 D: 21834 Elo +2.82 http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc LTC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 12998 W: 2045 L: 1876 D: 9077 Elo +4.52 http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c How could we continue after the patch: • The code in search() that checks for cycles has numerous possible variants. Perhaps the check need could be done in qsearch() too. • The biggest improvement would be to get "no progress" to be of actual benefit, and it would be helpful understand why it (probably) isn't. Perhaps there is an interaction with the transposition table or the (fantastically complex) tree search. Perhaps this would be hard to fix, but there may be a simple oversight. Closes https://github.com/official-stockfish/Stockfish/pull/1575 Bench: 4550412 see source |
| 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: Mon May 14 06:52:48 2018 +0200 Timestamp: 1526273568 Update search.cpp At PvNodes allow bonus for prior counter move that caused a fail low for depth 1 and 2. Note : I did a speculative LTC on yellow STC patch since history stats tend to be highly TC sensitive STC (Yellow): LLR: -2.96 (-2.94,2.94) [0.00,5.00] Total: 64295 W: 13042 L: 12873 D: 38380 Elo +0.91 http://tests.stockfishchess.org/tests/view/5af507c80ebc5968e6524153 LTC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 22407 W: 3413 L: 3211 D: 15783 Elo +3.13 http://tests.stockfishchess.org/tests/view/5af85dd40ebc591fdf408b87 Also use local variable excludedMove in NMP (marotear) Bench: 5294316 see source |
| 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: Sun May 13 07:20:39 2018 +0200 Timestamp: 1526188839 Tweak kingAttackersCount and KingAttackWeights Use the whole kingRing for pawn attackers instead of only the squares directly around the king. This tends to give quite a lot more kingAttackersCount, so to compensate and to avoid raising the king danger too fast we lower the values in the KingAttackWeights array a little bit. STC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 51892 W: 10723 L: 10369 D: 30800 Elo +2.37 http://tests.stockfishchess.org/tests/view/5af6d4dd0ebc5968e652428e LTC: LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 24536 W: 3737 L: 3515 D: 17284 Elo +3.14 http://tests.stockfishchess.org/tests/view/5af709890ebc5968e65242ac Credits to user @xoroshiro for the idea of using the kingRing for pawn attackers. How to continue? It seems that the KingAttackWeights[] array stores values which are quite Elo-sensitive, yet they have not been tuned with SPSA recently. There might be easy Elo points to get there. Closes https://github.com/official-stockfish/Stockfish/pull/1597 Bench: 5282815 see source |
| 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: Thu May 10 23:36:16 2018 +0200 Timestamp: 1525988176 Include all blockers in king danger Simplification: in king danger, include all blockers and not only pinned pieces, since blockers enemy pieces can result in discovered checks which are also bad. STC http://tests.stockfishchess.org/tests/view/5af35f9f0ebc5968e6523fe9 LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 145781 W: 29368 L: 29478 D: 86935 Elo -0.26 LTC http://tests.stockfishchess.org/tests/view/5af3cb430ebc5968e652401f LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 76398 W: 11272 L: 11232 D: 53894 Elo +0.18 I also incorrectly scheduled STC with [0,5] which it failed. http://tests.stockfishchess.org/tests/view/5af283c00ebc5968e6523f33 LLR: -2.94 (-2.94,2.94) [0.00,5.00] Total: 12338 W: 2451 L: 2522 D: 7365 Elo -2.00 Closes https://github.com/official-stockfish/Stockfish/pull/1593 bench: 4698290 ---------------------------------------- Thanks to @vondele and @Rocky640 for a cleaner version of the patch, and the following comments! > Most of the pinned, (or for this pull request, blocking) squares were > already computed in the unsafeChecks, the only missing squares being: > > a) squares attacked by a Queen which are occupied by friendly piece > or "unsafe". Note that adding such squares never passed SPRT[0,5]. > > b) squares not in mobilityArea[Us]. > > There is a strong relationship between the blockers and the unsafeChecks, > but the bitboard unsafeChecks is still useful when the checker is not > aligned with the king, and the checking square is occupied by friendly > piece or is "unsafe". This is always the case for the Knight. see source |