| 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 http://tests.stockfishchess.org/tests/view/5b015a1c0ebc5914abc126e5 Closes https://github.com/official-stockfish/Stockfish/pull/1603 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: 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. |
| 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 http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc LTC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 12998 W: 2045 L: 1876 D: 9077 http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c How could we continue after the patch: • The code in search() that checks for cycles has numerous possible variants. Perhaps the check need could be done in qsearch() too. • The biggest improvement would be to get "no progress" to be of actual benefit, and it would be helpful understand why it (probably) isn't. Perhaps there is an interaction with the transposition table or the (fantastically complex) tree search. Perhaps this would be hard to fix, but there may be a simple oversight. Closes https://github.com/official-stockfish/Stockfish/pull/1575 Bench: 4550412 |
| 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 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 http://tests.stockfishchess.org/tests/view/5af85dd40ebc591fdf408b87 Also use local variable excludedMove in NMP (marotear) Bench: 5294316 |
| 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 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 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 |
| 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 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 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 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. |
| 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 10 15:46:32 2018 +0200 Timestamp: 1525959992 Consolidate pawn storm types Simplification: the Unopposed and Unblocked pawn storm types are mathematically similar enough to combine with no Elo loss. This reduces the pawn storm types to BlockedByPawn and UnBlocked. STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 116869 W: 23549 L: 23605 D: 69715 http://tests.stockfishchess.org/tests/view/5af2def90ebc5968e6523f82 LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 39912 W: 6090 L: 5998 D: 27824 http://tests.stockfishchess.org/tests/view/5af3b2e20ebc5968e6524013 Closes https://github.com/official-stockfish/Stockfish/pull/1592 Bench: 5244314 |
| 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: Stefan Geschwentner
Date: Thu May 10 12:28:18 2018 +0200 Timestamp: 1525948098 Tune null move pruning Use a lower stat score threshold of 22500. Failed yellow at STC after many games (~0.92 Elo): LLR: -2.96 (-2.94,2.94) [0.00,4.00] Total: 73978 W: 14947 L: 14834 D: 44197 http://tests.stockfishchess.org/tests/view/5af2deec0ebc5968e6523f80 But scales good and passed LTC: LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 23147 W: 3453 L: 3237 D: 16457 http://tests.stockfishchess.org/tests/view/5af3cf820ebc5968e6524022 Closes https://github.com/official-stockfish/Stockfish/pull/1591 Bench: 4777674 |
| 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 May 9 09:22:11 2018 +0200 Timestamp: 1525850531 Tuned some pawns and evaluation constants Tuned values in pawns.cpp and evaluate.cpp after a SPSA session: 419k games 60sec 600nodetime. We have adjusted the PassedRank[] output of the SPSA session to keep increasing values with rank, and PassedFile[] output to keep the West <–> East symmetry of the evaluation. STC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 58948 W: 12431 L: 12046 D: 34471 http://tests.stockfishchess.org/tests/view/5af2302f0ebc5968e6523f0a LTC: LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 22211 W: 3468 L: 3251 D: 15492 http://tests.stockfishchess.org/tests/view/5af264c80ebc5968e6523f1a See https://github.com/official-stockfish/Stockfish/pull/1587 and https://github.com/official-stockfish/Stockfish/pull/1590 bench: 4437531 |
| 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 9 01:42:34 2018 +0200 Timestamp: 1525822954 Remove goto, limit skipping to NMP This patch simplifies the control flow in search(), removing an if and a goto. A side effect of the patch is that Stockfish is now a little bit more selective at low depths, because we allow razoring, futility pruning and probcut pruning after a null move. passed STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 32035 W: 6523 L: 6422 D: 19090 http://tests.stockfishchess.org/tests/view/5af142ca0ebc597fb3d39bb6 passed LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 41431 W: 6187 L: 6097 D: 29147 http://tests.stockfishchess.org/tests/view/5af148770ebc597fb3d39bc1 Ideas for further work: • Use the nodes credit opened by the patch (the increased selectivity) to try somewhat higher razoring, futility or probcut margins at [0..4]. Bench: 4855031 |
| 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: Stefan Geschwentner
Date: Tue May 8 23:31:55 2018 +0200 Timestamp: 1525815115 Tweak null move pruning conditions Allow null move pruning only if last stat score < 30000. Passed STC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 12653 W: 2641 L: 2454 D: 7558 http://tests.stockfishchess.org/tests/view/5af1d8830ebc5968e6523edb Passed LTC: LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 19782 W: 3072 L: 2878 D: 13832 http://tests.stockfishchess.org/tests/view/5af1ee8c0ebc5968e6523ee4 Ideas for further work: • Tune the stat score threshold. • Try depth based stat score threshold. • Try stat score condition for other prunings. Closes https://github.com/official-stockfish/Stockfish/pull/1589 Bench: 5088156 |
| 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: Tue May 8 11:14:43 2018 +0200 Timestamp: 1525770883 Drop the lever condition for backwards We can view the patch version as adding some "undermining bonus" for level pawns, when the defending side can not easily avoid the exchange by advancing her pawn. • Case 1) White b2,c3, Black a3,b3: Black is breaking through, b2 deserves a penalty • Case 2) White b2,c3, Black a3,c4: if b2xa3 then White ends up with a weak pawn on a3 and probably a weak pawn on c3 too. In either case, White can still not safely play b2-b3 and make a phalanx with c3, which is the essence of a backward pawn definition. Passed STC in SPRT[0, 4]: LLR: -2.96 (-2.94,2.94) [0.00,4.00] Total: 131169 W: 26523 L: 26199 D: 78447 http://tests.stockfishchess.org/tests/view/5aefa4d50ebc5902a409a151 ELO 1.19 [-0.38,2.88] (95%) Passed LTC in SPRT[-3, 1]: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 24824 W: 3732 L: 3617 D: 17475 http://tests.stockfishchess.org/tests/view/5af04d3f0ebc5902a88b2e55 ELO 1.27 [-1.21,3.70] (95%) Closes https://github.com/official-stockfish/Stockfish/pull/1584 How to continue from there? There were some promising tests a couple of months ago about adding a lever condition for king danger in evaluate.cpp, maybe it would be time to re-try this after all the recent changes in pawns.cpp Bench: 4773882 |
| 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 8 10:43:56 2018 +0200 Timestamp: 1525769036 Remove skipEarlyPruning argument to search() Remove nine boolean arguments and the corresponding skipEarlyPruning variable. Instead, skip early pruning only when there is an excluded move, and try null move pruning only if the previous move was not itself a null move. passed STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 33623 W: 6853 L: 6755 D: 20015 http://tests.stockfishchess.org/tests/view/5aef462a0ebc5902a409a10e passed LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 39474 W: 5882 L: 5789 D: 27803 http://tests.stockfishchess.org/tests/view/5aefd4b80ebc5902a409a164 Closes https://github.com/official-stockfish/Stockfish/pull/1585 Bench: 4953556 |
| 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 8 10:32:23 2018 +0200 Timestamp: 1525768343 Improve signature script Catch case of missing bench, indicative of a crash or assert. 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: Sun May 6 09:44:14 2018 +0200 Timestamp: 1525592654 Simplify the backward pawns code The two lines of code in the patch seem to be just as good as master. 1. We now only look at the current square to see if it is currently backward, whereas master looks there AND further ahead in the current file (master would declare a pawn "backward" even though it could still safely advance a little). This simplification allows us to avoid the use of the difficult logic with `backmost_sq(Us, neighbours | stoppers)`. 2. The condition `relative_rank(Us,s) < RANK_5` is simplified away. Passed STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 68132 W: 14025 L: 13992 D: 40115 http://tests.stockfishchess.org/tests/view/5aedc97a0ebc5902a4099fd6 Passed LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 23789 W: 3643 L: 3527 D: 16619 http://tests.stockfishchess.org/tests/view/5aee4f970ebc5902a409a03a Ideas for further work: • The new code flags some pawns on the 5th rank as backward, which was not the case in the old master. So maybe we should test a version with that included? • Further tweaks of the backward condition with [0..5] bounds? Closes https://github.com/official-stockfish/Stockfish/pull/1583 Bench: 5122789 |
| 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 May 3 22:00:07 2018 +0200 Timestamp: 1525377607 Tweak the connected[] array value for pawns on rank 5 A recent tuning session by Jerry Donald Watson suggested that the value for the pawns on the fifth rank in the connected[] array were a little bit too high in master. We lower here this value from 75 to 65. STC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 27399 W: 5646 L: 5384 D: 16369 http://tests.stockfishchess.org/tests/view/5aea17c50ebc5902a1bed396 LTC: LLR: 3.66 (-2.94,2.94) [0.00,4.00] Total: 95590 W: 14529 L: 14062 D: 66999 http://tests.stockfishchess.org/tests/view/5aea34a40ebc5902a104ebe5 Closes https://github.com/official-stockfish/Stockfish/pull/1580 Bench: 5186783 |
| 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 May 2 13:38:00 2018 +0200 Timestamp: 1525261080 Correct a bug introduced by Stéphane in the previous patch. When we are using the "Bitboard + Square" overloaded operators, the compiler uses the interpediate SquareBB[s] to transform the square into a Bitboard, and then calculate the result. For instance, the following code: ``` b = pos.pieces(Us, PAWN) & s ``` generates in fact the code: ``` b = pos.pieces(Us, PAWN) & SquareBB[s]` ``` The bug introduced by Stéphane in the previous patch was the use of `b = pos.pieces(Us, PAWN) & (s + Up)` which can result in out-of-bounds errors for the SquareBB[] array if s in the last rank of the board. We coorect the bug, and also add some asserts in bitboard.h to make the code more robust for this particular bug in the future. Bug report by Joost VandeVondele. Thanks! Bench: 5512000 |
| 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: Tue May 1 23:55:30 2018 +0200 Timestamp: 1525211730 Use special rule for BlockedByKing Simplification: remove BlockedByKing from storm array and use a special rule. The BlockedByKing section in the storm array is substantially similar to the Unopposed section except for two extreme values V(-290), V(-274). Turns out removing BlockedByKing and using a special rule for these two values shows no Elo loss. All the other values in the BlockedByKing section are apparently irrelevant. BlockedByKing now falls under unopposed which (to me) is a bit more logical since there is no defending pawn on this file. Also, retuning the Unopposed section may be another improvement. GOOD) This is a simplification because the entire BlockedByKing section of the storm array goes away reducing a few lines of code (and less values to tune). This also brings clarity because the special rule is self documenting. BAD) It takes execution time to apply the special rule. This should be negli- gible because it is based on a template parameter and is boiled down to two bitwise AND's. STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 33470 W: 6820 L: 6721 D: 19929 http://tests.stockfishchess.org/tests/view/5ae7b6e60ebc5926dba90e13 LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 47627 W: 7045 L: 6963 D: 33619 http://tests.stockfishchess.org/tests/view/5ae859ff0ebc5926dba90e85 Closes https://github.com/official-stockfish/Stockfish/pull/1574 Bench: 5512000 ----------- How to continue after this patch? This patch may open the possibility to move the special rule to evaluate.cpp in the evaluate::king() function, where we could refine the rule using king danger information. For instance, with a king in H2 blocking an opponent pawn in H3, it may be critical to know that the opponent has no safe check in G2 before giving the bonus :-) |
| 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: MJZ1977
Date: Tue May 1 07:12:27 2018 +0200 Timestamp: 1525151547 Penalty for bad bishop with blocked central files We increase the penalty for bad bishops by a factor proportional to the number of our blocked pawns in the center files C, D, E or F. STC: LLR: 2.97 (-2.94,2.94) [0.00,5.00] Total: 8868 W: 1870 L: 1700 D: 5298 http://tests.stockfishchess.org/html/live_elo.html?5ae7674f0ebc590e39268b34 LTC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 5813 W: 950 L: 808 D: 4055 http://tests.stockfishchess.org/html/live_elo.html?5ae77bae0ebc5926dba90dd9 Closes https://github.com/official-stockfish/Stockfish/pull/1573 Bench: 5364190 |
| 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: Stefano80
Date: Sun Apr 29 07:26:25 2018 +0200 Timestamp: 1524979585 Always scale using pawn contribution This is a further step in the long quest for a simple way of determining scale factors for the endgame. Here we remove the artificial restriction in evaluate_scale_factor() based on endgame score. Also SCALE_FACTOR_ONEPAWN can be simplified away. The latter is a small non functional simplification with respect to the version that was testedin the framework, verified on bench with depth 22 for good measure. Passed STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 49438 W: 9999 L: 9930 D: 29509 http://tests.stockfishchess.org/tests/view/5ae20c8b0ebc5963175205c8 Passed LTC LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 101445 W: 15113 L: 15110 D: 71222 http://tests.stockfishchess.org/tests/view/5ae2a0560ebc5902a1998986 How to continue from there? Maybe the general case could be scaled with pawns from both colors without losing Elo. If that is the case, then this could be merged somehow with the scaling in evaluate_initiative(), which also uses a additive malus down when the number of pawns in the position goes down. Closes https://github.com/official-stockfish/Stockfish/pull/1570 Bench: 5254862 |
| 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: Sun Apr 29 06:59:17 2018 +0200 Timestamp: 1524977957 Simplifiy IID condition do IID for all sufficiently deep searches without TT move. passed STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 25494 W: 5313 L: 5199 D: 14982 http://tests.stockfishchess.org/tests/view/5ae1e8dd0ebc596317520583 passed LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 80582 W: 12162 L: 12130 D: 56290 http://tests.stockfishchess.org/tests/view/5ae1f5ab0ebc5963175205a4 Bench: 4966970 |
| 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: Sun Apr 29 06:53:51 2018 +0200 Timestamp: 1524977631 Fix 'make strip' for mingw. Currently the make strip target is broken on mingw as the exe name is wrong (stockfish instead of stockfish.exe). Needs some testing by mingw users (both profile-build and strip, native and cross). 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: Sun Apr 29 06:48:18 2018 +0200 Timestamp: 1524977298 Update various comments Spotted by Alain Savard, Joost VandeVondele, Ronald de Man, Fabian Fichter, Chris Cain, xoto10 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: Alain SAVARD
Date: Tue Apr 24 14:41:50 2018 +0200 Timestamp: 1524573710 No Queen in the MobilityArea Queen was recently excluded from the mobility area of friendly minor pieces. Exclude queen also from the mobility area of friendly majors too. Run as a simplification: STC http://tests.stockfishchess.org/tests/view/5ade396f0ebc59602d053742 LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 46972 W: 9511 L: 9437 D: 28024 LTC http://tests.stockfishchess.org/tests/view/5ade64b50ebc5949f20a24d3 LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 66855 W: 10157 L: 10105 D: 46593 How to continue from there? The mobilityArea is used in various places of the evaluation as a soft proxy for "not attacked by the opponent pawns". Now that the mobility area is getting smaller and smaller, it may be worth to hunt for Elo gains by trying the more direct ~attackedBy[Them][PAWN] instead of mobilityArea[Us] in these places. Bench: 4650572 |
| 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 Apr 23 09:49:05 2018 +0200 Timestamp: 1524469745 Simplify the ShelterStrength[] array Remove the distinction between the king file and the two neighbours files in the ShelterStrength[] array. Instead we initialize the safety variable in the evaluate_shelter() function with a -10 penalty if our king is on a semi-open file (ie. if our king is on a file without a pawn protection). Also rename shelter_storm() to evaluate_shelter() while there. STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 23153 W: 4795 L: 4677 D: 13681 http://tests.stockfishchess.org/tests/view/5adcb83d0ebc595ec7ff8aa7 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 25728 W: 3934 L: 3821 D: 17973 http://tests.stockfishchess.org/tests/view/5adcdcb60ebc595ec7ff8adb See the commit history in PR#1559 for the proof that the committed version is equivalent to the version in the tests above: https://github.com/official-stockfish/Stockfish/pull/1559 Full credit to @protonspring for the renormalized values of the ShelterStrength[] array used for the simplification. Thanks! Bench: 4703935 |