| 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: Vizvezdenec
Date: Tue Nov 26 01:28:05 2019 +0100 Timestamp: 1574728085 Simplify king danger This patch is a cleanup/simplification of king flank defenders patch, removing king flanks attacks linear dependance in kingdanger. Result of experiments with quadratic kingflank defenders scaling. Rebased on the latest master. passed STC http://tests.stockfishchess.org/tests/view/5ddc2b99e0b4af579302bacf LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 19660 W: 4309 L: 4184 D: 11167 Elo +2.21 passed LTC http://tests.stockfishchess.org/tests/view/5ddc3168e0b4af579302bade LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 24362 W: 3974 L: 3859 D: 16529 Elo +1.64 Closes https://github.com/official-stockfish/Stockfish/pull/2428 bench 5742013 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: Moez Jellouli
Date: Tue Nov 26 00:01:49 2019 +0100 Timestamp: 1574722909 Extend last non-pawn captures Extend last non-pawn captures at principal variation nodes because they are in general decisive moves with clear endgame result. STC http://tests.stockfishchess.org/tests/view/5ddafc86e75c0005326d2140 LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 9892 W: 2238 L: 2099 D: 5555 Elo +4.88 LTC http://tests.stockfishchess.org/tests/view/5ddb0401e75c0005326d2150 LLR: 2.95 (-2.94,2.94) [0.00,3.50] Total: 30369 W: 5013 L: 4756 D: 20600 Elo +2.94 Closes https://github.com/official-stockfish/Stockfish/pull/2425 Bench: 5059526 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: 31m059
Date: Sun Nov 24 00:34:43 2019 +0100 Timestamp: 1574552083 King danger: retire attacked-by-bishop defense In a recent commit, "Introduce king flank defenders," a term was introduced by Michael Chaly (@Vizvezdenec) to reduce king danger based on king defenders, i.e., friendly attacks on our King Flank and Camp. This is a powerful idea and broadly applicable to all of our pieces. An earlier, but narrower, version of a similar idea was already coded into king danger, with a term reducing king danger simply if we had a bishop and king attacking the same square -- there is also a similar term for knights, but roughly three times larger. I had attempted to tweak this term's coefficient fairly recently, in a series of tests in early September which increased this coefficient. All failed STC with significantly negative scores. Now that the king flank defenders term has been introduced, it appears that the bishop-defense term can be simplified away without compensation or significant Elo loss. Where do we go from here? This PR is a natural follow-up to "Introduce king flank defenders," which proposed simplification with existing and overlapping terms, such as this one. That PR also mentioned that the coefficient it introduced appeared arbitrary, so perhaps this PR can facilitate a tweak to increase king flank defenders' coefficient. Additionally, this pull request is extremely similar to https://github.com/official-stockfish/Stockfish/pull/1821, which was (coincidentally) merged a year ago, to the day (November 23, 2018). That patch also simplified away a linear king danger tropism term, which was soon after replaced with a quadratic term by @Vizvezdenec (which would not have passed without the simplification). @Vizvezdenec, again by coincidence, has recently been trying to implement a quadratic term, this time for defenders rather than attackers. This history of this evaluation code suggests that this simplification might be enough to help a patch for quadratic king-flank defenders pass. Bench: 4959670 STC: LLR: 2.94 (-2.94,2.94) [-3.00,1.00] Total: 22209 W: 4920 L: 4800 D: 12489 Elo +1.88 https://tests.stockfishchess.org/tests/view/5dd444d914339111b9b6bed7 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 152107 W: 24658 L: 24743 D: 102706 Elo -0.19 https://tests.stockfishchess.org/tests/view/5dd4be31f531e81cf278ea9d Interesting discussion on Github about this pull request: https://github.com/official-stockfish/Stockfish/pull/2424 --- This pull request was opened less than one week before the holiday of Thanksgiving here in the United States. In keeping with the holiday tradition of expressing gratitude, I would like to thank our generous CPU donors, talented forum contributors, innovative developers, speedy fishtest approvers, and especially our hardworking server maintainers (@ppigazzini and @tomtor). Thank you all for a year of great Stockfish progress! 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: SFisGOD
Date: Sun Nov 24 00:23:06 2019 +0100 Timestamp: 1574551386 Simplify endgame factor for opposite colored bishops Stockfish is continually improving. Patches that gain elo in the past may no longer be needed as stockfish improved elsewhere. This patch removes passed pawns count dependence in opposite colored bishops scale factor. We used the mean of passed count pawns (~1.4) to compensate, and changed the base value from 16 to 22. Passed STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 57879 W: 12657 L: 12607 D: 32615 Elo +0.30 http://tests.stockfishchess.org/tests/view/5dd1644f42928ff08153dc1e Passed LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 121648 W: 19622 L: 19659 D: 82367 Elo -0.11 http://tests.stockfishchess.org/tests/view/5dd24572ccb823d41d4b47bb Closes https://github.com/official-stockfish/Stockfish/pull/2419 Bench: 5067864 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: Vizvezdenec
Date: Thu Nov 21 09:52:13 2019 +0100 Timestamp: 1574326333 Do lmr for more captures Based on machinery introduced by vondele. Logic behind patch if relatively simple - if we reduce less with high hit rate of transposition table somewhat logical is to reduce more with low hit rate. For example enable all captures for LMR. Threshold 0.375 is arbitrary and can be tweaked :) STC http://tests.stockfishchess.org/tests/view/5dd4d51df531e81cf278eaac LLR: 2.97 (-2.94,2.94) [-1.50,4.50] Total: 16495 W: 3591 L: 3434 D: 9470 Elo +3.31 LTC http://tests.stockfishchess.org/tests/view/5dd52265f531e81cf278eace LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 23598 W: 3956 L: 3716 D: 15926 Elo +3.53 Closes https://github.com/official-stockfish/Stockfish/pull/2420 Bench: 5067870 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: Alain SAVARD
Date: Thu Nov 21 09:32:19 2019 +0100 Timestamp: 1574325139 Outpost Endgame values Remove the recent rank based Outpost array by using a weighted average value computed using a frequency analysis by rank from a large set of middle game positions. The higher eg values introduced by the new Outpost array (which were about twice the previous masters) are thus preserved. STC http://tests.stockfishchess.org/tests/view/5dd05c870ebc5902579e1f7f LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 42466 W: 9232 L: 9151 D: 24083 Elo +0.66 LTC http://tests.stockfishchess.org/tests/view/5dd146e342928ff08153dab1 LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 66968 W: 10921 L: 10873 D: 45174 Elo +0.25 Closes https://github.com/official-stockfish/Stockfish/pull/2418 Bench: 5103360 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: Vizvezdenec
Date: Tue Nov 19 23:18:14 2019 +0100 Timestamp: 1574201894 Simplify advanced pawn push pruning This patch simplifies away all conditions related to advanced pawn pushes in shallow depth pruning. Idea is based on fact that in master we have advanced pawn pushes not being pruned what we are only in PV node and when non-pawn material of opponent is > Bishop, so pretty rarely. With this patch we will have all pruning heuristics working for this moves as for every other move. STC LLR: 2.94 (-2.94,2.94) [-3.00,1.00] Total: 159143 W: 34271 L: 34418 D: 90454 Elo -0.32 http://tests.stockfishchess.org/tests/view/5dcdb3110ebc5902563249d7 LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 63900 W: 10375 L: 10322 D: 43203 Elo +0.29 http://tests.stockfishchess.org/tests/view/5dd05e820ebc5902579e1fb8 Closes https://github.com/official-stockfish/Stockfish/pull/2416 bench 4897149 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: Mon Nov 18 09:57:53 2019 +0100 Timestamp: 1574067473 Use exploration rate for reductions This patch measures how frequently search is exploring new configurations. This is done be computing a running average of ttHit. The ttHitAverage rate is somewhat low (e.g. 30% for startpos) in the normal case, while it can be very high if no progress is made (e.g. 90% for the fortress I used for testing). This information can be used to influence search. In this patch, by adjusting reductions if the rate > 50%. A first version (using a low ttHitAverageResolution and this 50% threshold) passed testing: STC LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 26425 W: 5837 L: 5650 D: 14938 Elo +2.46 http://tests.stockfishchess.org/tests/view/5dcede8b0ebc5902563258fa LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 32313 W: 5392 L: 5128 D: 21793 Elo +2.84 http://tests.stockfishchess.org/tests/view/5dcefb1f0ebc590256325c0e However, as discussed in pull request 2414, using a larger ttHitAverageResolution gives a better approximation of the underlying distributions. This needs a slight adjustment for the threshold as the new distributions are shifted a bit compared to the older ones, and this threshold seemingly is sensitive (we used 0.53125 here). https://github.com/official-stockfish/Stockfish/pull/2414 This final version also passed testing, and is used for the patch: STC LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 16025 W: 3555 L: 3399 D: 9071 Elo +3.38 http://tests.stockfishchess.org/tests/view/5dd070b90ebc5902579e20c2 LTC LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 37576 W: 6277 L: 5998 D: 25301 Elo +2.58 http://tests.stockfishchess.org/tests/view/5dd0f58e6f544e798086f224 Closes https://github.com/official-stockfish/Stockfish/pull/2414 Bench: 4989584 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: Vizvezdenec
Date: Sat Nov 16 17:29:53 2019 +0100 Timestamp: 1573921793 Introduce king flank defenders This patch implements what we have been trying for quite some time - dependance of kingdanger on balance of attackers and defenders of king flank, to avoid overestimate attacking power if the opponent has enough defenders of king position. We already have some form of it in bishop and knight defenders - this is further work in this direction. What to do based on this? 1) constant 4 is arbitrary, maybe it is not optimal 2) maybe we can use quadratic formula as in kingflankattack 3) simplification into alrealy existing terms is always a possibility :) 4) overall kingdanger tuning always can be done. passed STC: http://tests.stockfishchess.org/tests/view/5dcf40560ebc590256325f30 LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 26298 W: 5819 L: 5632 D: 14847 Elo +2.47 passed LTC: http://tests.stockfishchess.org/tests/view/5dcfa5760ebc590256326464 LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 30600 W: 5042 L: 4784 D: 20774 Elo +2.93 Closes https://github.com/official-stockfish/Stockfish/pull/2415 Bench: 4496847 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: Stefan Geschwentner
Date: Thu Nov 14 20:26:15 2019 +0100 Timestamp: 1573759575 Prune before extension Switch execution order in search: do move pruning before extension detection. STC: LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 5762 W: 1307 L: 1181 D: 3274 Elo +7.60 http://tests.stockfishchess.org/tests/view/5dcc56e90ebc59025bcbb833 LTC: LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 72956 W: 11959 L: 11585 D: 49412 Elo +1.78 http://tests.stockfishchess.org/tests/view/5dcc62840ebc59025bcbb96f Closes https://github.com/official-stockfish/Stockfish/pull/2413 Bench: 4532366 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: SFisGOD
Date: Wed Nov 13 11:01:00 2019 +0100 Timestamp: 1573639260 Rank-based outposts Introduce OutpostRank[RANK_NB] which contains a bonus according to the rank of the outpost. We use it for the primary Outpost bonus. The values are based on the trends of the SPSA tuning run with some manual tweaks. Passed STC: LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 27454 W: 6059 L: 5869 D: 15526 Elo +2.40 http://tests.stockfishchess.org/tests/view/5dcadba20ebc590256922f09 Passed LTC: LLR: 2.94 (-2.94,2.94) [0.00,3.50] Total: 57950 W: 9443 L: 9112 D: 39395 Elo +1.98 http://tests.stockfishchess.org/tests/view/5dcaea880ebc5902569230bc Bench: 4778405 ---------------------------- The inspiration for this patch came from Stefan Geschwentner's attempt of modifying BishopPawns into a rank-based penalty. Michael Stembera suggested that maybe the S(0, 0) ranks (3rd, 7th and also maybe 8th) can still be tuned. This would expand our definition of Outpost and OutpostRanks would be removed altogether. Special thanks to Mark Tenzer for all the help and excellent suggestions. 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: Miguel Lahoz
Date: Tue Nov 12 01:36:06 2019 +0100 Timestamp: 1573518966 Shallow depth pruning on NonPV advanced pawn push Usually advanced pawn pushes are not considered in shallow depth pruning because it is risky to do so with possible promotions near the horizon. However, this heuristic is not also beneficial on NonPV nodes since we can afford to take slightly more risk on less important nodes. STC: LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 54530 W: 11955 L: 11686 D: 30889 Elo +1.71 http://tests.stockfishchess.org/tests/view/5dc7dda30ebc5902ea57efd0 LTC: LLR: 2.95 (-2.94,2.94) [0.00,3.50] Total: 77336 W: 12786 L: 12399 D: 52151 Elo +1.74 http://tests.stockfishchess.org/tests/view/5dc8050d0ebc5902ea57f491 Closes https://github.com/official-stockfish/Stockfish/pull/2408 Bench: 4422068 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 Nov 12 01:27:06 2019 +0100 Timestamp: 1573518426 Remove explicit moveCount pruning The removed lines approximately duplicate equivalent logic in the movePicker. Adjust the futility_move_count to componsate for some difference (the movePicker prunes one iteration of the move loop later). Passed STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 8114 W: 1810 L: 1663 D: 4641 Elo +6.30 http://tests.stockfishchess.org/tests/view/5dc6afe60ebc5902562bd318 Passed LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 89956 W: 14473 L: 14460 D: 61023 Elo +0.05 http://tests.stockfishchess.org/tests/view/5dc6bdcf0ebc5902562bd3c0 Closes https://github.com/official-stockfish/Stockfish/pull/2407 Bench: 4256440 --------------------- How to continue from there? It would be interesting to see if we can extract some Elo gain from the new futility_move_count formula, for instance by somehow incorporating the final -1 in the 5 constant, or adding a linear term to the quadratics... ``` futility_move_count = (5 + depth * depth) * (1 + improving) / 2 - 1 ``` 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: Alain SAVARD
Date: Tue Nov 12 01:18:54 2019 +0100 Timestamp: 1573517934 Sequencing tweak in tbprobe() Followup of "issue" #2372, which was in fact a small speed-up proposal by user @d3vv for the probing code of tablebases. See comments on this issue where it was proven by Alin Savard that the proposed change is more efficient on average than master on all type of sequences it will usually be called. Note that on gcc 4.3, this will produce a bogus warning which was solved with ulterior gcc versions: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43949 Closes https://github.com/official-stockfish/Stockfish/issues/2372 Closes https://github.com/official-stockfish/Stockfish/pull/2379 Non 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: Tue Nov 12 01:09:57 2019 +0100 Timestamp: 1573517397 Fix incorrect mate score. Current master 648c7ec25db2040c0af34dd846dfa3f57af5ad0a will generate an incorrect mate score for: ``` setoption name Hash value 8 setoption name Threads value 1 position fen 8/1p2KP2/1p4q1/1Pp5/2P5/N1Pp1k2/3P4/1N6 b - - 76 40 go depth 49 ``` even though the position is a draw. Generally, SF tries to display only proven mate scores, so this is a bug. This was posted http://www.talkchess.com/forum3/viewtopic.php?f=2&t=72166 by Uri Blass, with the correct analysis that this must be related to the 50 moves draw rule being ignored somewhere. Indeed, this is possible as positions and there eval are stored in the TT, without reference to the 50mr counter. Depending on the search path followed a position can thus be mate or draw in the TT (GHI or Graph history interaction). Therefore, to prove mate lines, the TT content has to be used with care. Rather than ignoring TT content in general or for mate scores (which impact search or mate finding), it is possible to be more selective. In particular, @WOnder93 suggested to only ignore the TT if the 50mr draw ply is closer than the mate ply. This patch implements this idea, by clamping the eval in the TT to +-VALUE_MATED_IN_MAX_PLY. This retains the TTmove, but causes a research of these lines (with the current 50mr counter) as needed. This patch hardly ever affects search (as indicated by the unchanged bench), but fixes the testcase. As the conditions are very specific, also mate finding will almost never be less efficient (testing welcome). It was also shown to pass STC and LTC non-regression testing, in a form using if/then/else instead of ternary operators: STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 93605 W: 15346 L: 15340 D: 62919 Elo +0.02 http://tests.stockfishchess.org/tests/view/5db45bb00ebc5908127538d4 LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 33873 W: 7359 L: 7261 D: 19253 Elo +1.01 http://tests.stockfishchess.org/tests/view/5db4c8940ebc5902d6b146fc closes https://github.com/official-stockfish/Stockfish/issues/2370 Bench: 4362323 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: Wed Nov 6 11:07:38 2019 +0100 Timestamp: 1573034858 Revert "Rook PSQT Tuned" This reverts the previous commit. The PSQT changes in this previous commit originated from tests against quite an old version of master which did not include the other PSQT changes of 474d133 for the other pieces, and there might be some unknown interactions between the PSQT tables. So we made a non-regression test of the last commit against the last-but-one commit. This test failed, leading to the revert decision. Failed non-regression test: LLR: -2.96 (-2.94,2.94) [-3.00,1.00] Total: 95536 W: 15047 L: 15347 D: 65142 Elo -1.09 http://tests.stockfishchess.org/tests/view/5dc0ba1d0ebc5904493b0112 Closes https://github.com/official-stockfish/Stockfish/pull/2395 Bench: 4362323 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: SFisGOD
Date: Tue Nov 5 00:15:23 2019 +0100 Timestamp: 1572909323 Rook PSQT Tuned This patch uses about half the changes of the SPSA tuning run: http://tests.stockfishchess.org/tests/view/5dba93d30ebc5925b64ed3bf About a month ago, xoto10's patch raised the mg value of the third rank center files from -1 to 7 to encourage rook lifts to the third rank. About three days later, Rocky's patch lowered this value from 7 to 3. This patch raises that again from 3 to 12 and ends up greater than the original rook lift patch. Passed STC: LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 104094 W: 22573 L: 22161 D: 59360 Elo +1.38 http://tests.stockfishchess.org/tests/view/5dbc77f20ebc5925b64ef1d0 Passed LTC: LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 168291 W: 27410 L: 26777 D: 114104 Elo +1.31 http://tests.stockfishchess.org/tests/view/5dbd9f1e0ebc5925b64f0647 Bench: 4707799 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: MichaelB7
Date: Tue Nov 5 00:01:49 2019 +0100 Timestamp: 1572908509 Remove shuffle extension It was noted in an earlier patch that all of the positions below needed the Shuffle Detection idea to be solved: 3r4/p3r1pk/PpBb1pRp/1KpPpP1P/2P1P1R1/8/8/8 b - - 32 86 8/8/8/1k6/2p5/p1K5/N2B2r1/8 b - - 59 109 1r4k1/1r1bq3/4p1p1/3pPpPp/pNpN1P1P/P1PnQ3/1PK5/1R3R2 b - - 13 82 5k2/3b4/5p2/p1p1pPp1/PpPpP1Pp/1P1P3P/8/3R1K2 w - - 20 1 But Stockfish has envolved a bit since the Shuffle Detection patch introduction, and this patch proves Stockfish is able to solves these drawn positions without it, even on single core without EGTB. Passed STC LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 14231 W: 3114 L: 2978 D: 8139 Elo +3.32 http://tests.stockfishchess.org/tests/view/5dbe1a610ebc5925b64f09d9 Passed LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 42781 W: 6917 L: 6831 D: 29033 Elo +0.70 http://tests.stockfishchess.org/tests/view/5dbe24c20ebc5925b64f0a7a Passed VLTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 32556 W: 4573 L: 4469 D: 23514 Elo +1.11 http://tests.stockfishchess.org/tests/view/5dbec3830ebc5925b64f11aa Closes https://github.com/official-stockfish/Stockfish/pull/2394 Bench: 4362323 ---------------------------- Example of search by Michael Byrne for the FEN position: q1B5/1P1q4/8/8/8/6R1/8/1K1k4 w - - 0 1 This position is win for white and the only moves that wins is Rg1 - all other moves either draw or lose. With single core and 1024M hash, it is solved without shuffle detection in 38 seconds on my machine (with no EGTB). This was the position that was locked in a loop in the initial shuffle detection patch! ``` dep score nodes time (not shown: tbhits knps seldep) 50 +1.71 298.9M 2:43.63 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Qe5+ Kb1 Qe4+ Ka2 Qd5+ Rb3 Qd2+ Ka3 Qc1+ Kb4 Qc7 Ka4 Qb8 Rb6 Ke5 Kb3 Qg8+ Kb4 Qf8+ Ka5 Qb8 Bb3 Kd4 Kb4 Qf8+ Ka4 Qb8 Ka5 K <snip> 49 +1.68 288.5M 2:38.35 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Qe5+ Kb1 Qe4+ Ka2 Qd5+ Rb3 Qd2+ Ka3 Qc1+ Kb4 Qc7 Ka4 Qb8 Rb6 Ke5 Kb3 Qg8+ Kb4 Qf8+ Ka5 Qb8 Bb3 Kd4 Kb4 Ke3 Be6 Ke4 Bc4 Ke <snip> 48 +1.78 228.5M 2:01.93 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Qe5+ Kb1 Qe4+ Ka2 Qd5+ Rb3 Qd2+ Ka3 Qa5+ Kb2 Qe5+ Ka2 Qb8 Rb5 Ke3 Kb1 Ke4 Bb3 Kf4 Be6 Ke3 Rb4 Kd3 Kb2 Ke3 Bd5 Qe5+ Kc2 Qh <snip> 46 +1.49 198.4M 1:44.89 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Qe5+ Kb1 Qe4+ Ka2 Qd5+ Rb3 Qd2+ Ka3 Qc1+ Kb4 Qc7 Ka4 Qb8 Rb6 Qe8+ Rb5 Qb8 Bc2 Qa7+ Kb3 Qe3+ Kc4 Qe6+ Kb4 Qd6+ Kb3 Qb8 Rb4 <snip> 45 +1.45 154.5M 1:20.75 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke3 Bg2 Kd4 Rb5 Kc4 Bf1+ Kd4 Kb2 Qh2+ Kb3 Qg3+ Ka4 Qb8 Be2 Ke3 Bc4 Kf4 Kb4 Qd6+ Kc3 Qb8 Kc2 Ke4 Be6 Qh2+ Kb3 Qg3+ Ka4 Qb8 Bb3 Kd4 Bd5 Ke3 <snip> 44 +1.36 141.9M 1:14.40 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Qd6 Rc2+ Kd3 Be2+ Ke3 Rb2 Qb8 Bd1 Ke4 Rb5 Kd4 Bf3 Kc4 Be2+ Kc3 Rb6 Kd2 Bc4 Kc3 Bd5 Kd4 Bg2 Ke5 Kb2 Kd4 Rb5 Kc4 Bf1+ Kd4 Be2 Ke4 Bc4 Qh2+ Kb3 Qg3+ Ka4 Qb8 Bd5+ Kd4 Be6 Ke4 <snip> 43 +1.36 134.1M 1:10.46 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Qd6 Rc2+ Kd3 Be2+ Ke3 Rb2 Qb8 Bd1 Ke4 Rb5 Kd4 Bf3 Kc4 Be2+ Kc3 Rb6 Kd2 Bc4 Kc3 Be6 Kd4 Rb5 Kc3 Bf7 Kd4 Kb2 Ke4 Kb3 Kf4 Kc3 Ke4 Kb2 Qh2+ Kb3 Qg3+ Ka4 Qb8 Rb4+ Ke5 Rb6 Kf4 <snip> 42 +1.36 118.7M 1:01.60 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Qd6 Rc2+ Kd3 Be2+ Ke3 Rb2 Qb8 Bd1 Ke4 Rb5 Kd4 Bf3 Kc4 Be2+ Kc3 Rb6 Kd2 Bc4 Kc3 Be6 Kd4 Rb5 Kc3 Bf7 Kd4 Kb2 Ke4 Bc4 Qh2+ Kb3 Qg3+ Ka4 Qb8 Bd5+ Kd4 Bb3 Qa7+ Kb4 Qb8 Bc4 Ke4 <snip> 41 +1.38 110.3M 0:56.80 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Qd6 Rc2+ Kd3 Be2+ Ke3 Rb2 Qb8 Bd1 Ke4 Rb5 Kd4 Bf3 Kc4 Be2+ Kc3 Rb6 Kd2 Bc4 Kc3 Be6 Kd4 Rb5 Kc3 Bd5 Kd4 Ba2 Ke4 Be6 Kd4 Kb2 Qh2+ Kb3 Qb8 Bc4 Ke3 Kc3 Qh8+ Kb4 Qb2+ Ka4 Qa1+ <snip> 39 +1.25 87.3M 0:44.48 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Kg5 Kb1 Kf5 Bb3 Ke5 Kb2 Kd4 Rb5 Qh2+ Bc2 Qb8 Bd1 Kc4 Be2+ Kd4 Kc2 Ke3 Bd1 Kd4 Kb3 Qg3+ Ka4 Qb8 Bb3 Kc3 Rb6 Kd4 Kb5 Ke5 K 38 +1.25 82.0M 0:41.90 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kd4 Rb5 Kc4 Be2+ Kc3 Rb6 Kd4 Bf3 Ke5 Kb2 Kf4 Bd1 Kg5 Kb1 Kf5 Bb3 Ke5 Kb2 Kd4 Rb5 Qh2+ Bc2 Qb8 Kb3 Qg3+ Ka4 Qb8 Bb3 Kc3 Rb6 Kd4 Kb5 Ke5 Kb4 Kd4 Be6 Kd3 Bd5 Kd4 Bf3 Ke5 Be <snip> 37 +0.13 79.3M 0:40.44 Rg1+ Kd2 Rg2+ Kc3 Rc2+ Kb3 Rb2+ Kc3 Bxd7 Qf8 Ba4 Qb8 Bd1 Kc4 Bf3 Kd4 Rb5 Kc4 Rb6 Kd4 Rb2 Ke5 Rb3 Kd6 Rb5 Ke6 Rb4 Kd6 Kc2 Kc5 Kb3 Kd6 Be4 Ke7 Kc3 Qc7+ Kd3 Qg3+ Kc2 Qf2+ Kb3 Qe3+ Ka2 Qa7+ Kb2 Qb8 Kb3 Kd6 Bf3 Qg8+ Ka3 Kc7 b8=R Qx 37 +0.67! 78.3M 0:39.90 Rg1+! 37 +0.47! 77.0M 0:39.18 Rg1+! 37 +0.32! 76.8M 0:39.11 Rg1+! 37 +0.23! 76.8M 0:39.07 Rg1+! 36 +0.57! 76.1M 0:38.72 Rg1+! 36 +0.37! 75.8M 0:38.59 Rg1+! 36 +0.23! 75.7M 0:38.51 Rg1+! 36 +0.13! 75.6M 0:38.49 Rg1+! 35 +0.03? 58.0M 0:29.84 bxa8=Q Qb5+? ``` 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: 31m059
Date: Mon Nov 4 23:50:14 2019 +0100 Timestamp: 1572907814 Make Square and Bitboard operators commutative As Stockfish developers, we aim to make our code as legible and as close to simple English as possible. However, one of the more notable exceptions to this rule concerns operations between Squares and Bitboards. Prior to this pull request, AND, OR, and XOR were only defined when the Bitboard was the first operand, and the Square the second. For example, for a Bitboard b and Square s, "b & s" would be valid but "s & b" would not. This conflicts with natural reasoning about logical operators, both mathematically and intuitively, which says that logical operators should commute. More dangerously, however, both Square and Bitboard are defined as integers "under the hood." As a result, code like "s & b" would still compile and give reasonable bench values. This trap occasionally ensnares even experienced Stockfish developers, but it is especially dangerous for new developers not aware of this peculiarity. Because there is no compilation or runtime error, and a reasonable bench, only a close review by approvers can spot this error when a test has been submitted--and many times, these bugs have slipped past review. This is by far the most common logical error on Fishtest, and has wasted uncountable STC games over the years. However, it can be fixed by adding three non-functional lines of code. In this patch, we define the operators when the operands are provided in the opposite order, i.e., we make AND, OR, and XOR commutative for Bitboards and Squares. Because these are inline methods and implemented identically, the executable does not change at all. This patch has the small side-effect of requiring Squares to be explicitly cast to integers before AND, OR, or XOR with integers. This is only performed twice in Stockfish's source code, and again does not change the executable at all (since Square is an enum defined as an integer anyway). For demonstration purposes, this pull request also inverts the order of one AND and one OR, to show that neither the bench nor the executable change. (This change can be removed before merging, if preferred.) I hope that this pull request significantly lowers the barrier-of-entry for new developer to join the Stockfish project. I also hope that this change will improve our efficiency in using our generous CPU donors' machines, since it will remove one of the most common causes of buggy tests. Following helpful review and comments by Michael Stembera (@mstembera), we add a further clean-up by implementing OR for two Squares, to anticipate additional traps developers may encounter and handle them cleanly. Closes https://github.com/official-stockfish/Stockfish/pull/2387 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: SFisGOD
Date: Sat Nov 2 21:19:35 2019 +0100 Timestamp: 1572725975 Combo of Parameter Tweaks This patch is a combo of the following tweaks: Complexity parameters Knight PSQT Bishop PSQT King PSQT Piece Values Passed STC: LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 56527 W: 12326 L: 12052 D: 32149 Elo +1.68 http://tests.stockfishchess.org/tests/view/5dbbca3f0ebc5925b64ee6d6 Passed LTC: LLR: 2.95 (-2.94,2.94) [0.00,3.50] Total: 64010 W: 10549 L: 10199 D: 43262 Elo +1.90 http://tests.stockfishchess.org/tests/view/5dbc30dc0ebc5925b64eee0c Closes https://github.com/official-stockfish/Stockfish/pull/2390 Bench: 4312945 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 Oct 31 17:47:23 2019 +0100 Timestamp: 1572540443 Simplify kingRing Simplify the king ring initialization and make it more regular, by just moving the king square off the edges and using PseudoAttacks by king from this new square. There is a small functional difference from the previous master, as the old master excludes the original ksq square while this patch always includes the nine squares block (after moving the king from the edges). Additionally, master does not adjust the kingRing down if we are on relative rank 8, while this patch treats all of the edges the same. STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 13263 W: 2968 L: 2830 D: 7465 Elo +3.62 http://tests.stockfishchess.org/tests/view/5db872830ebc5902d1f388aa LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 72996 W: 11819 L: 11780 D: 49397 Elo +0.19 http://tests.stockfishchess.org/tests/view/5db899c20ebc5902d1f38b5e Closes https://github.com/official-stockfish/Stockfish/pull/2384 Bench: 4959244 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 Oct 31 17:22:09 2019 +0100 Timestamp: 1572538929 Consolidate pawn_push and up This is a non-functional simplification. Pawn_push and Up are redundant. If we make up pawn_push, we can use it for all of the Up's and Down's. In this version, I've also left the Up and Down constants so that there is no worse readability. STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 23878 W: 5202 L: 5085 D: 13591 Elo +1.70 http://tests.stockfishchess.org/tests/view/5db5569a0ebc5902d6b14de4 Closes https://github.com/official-stockfish/Stockfish/pull/2378 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: Stefan Geschwentner
Date: Thu Oct 31 17:05:29 2019 +0100 Timestamp: 1572537929 Tweak dynamic contempt (the birthday patch) Make dynamic contempt weight factor dependent on static contempt so that higher static contempt implies less dynamic contempt and vice versa. For default contempt 24 this is a non-functional change. But tests with contempt 0 shows an elo gain. Also today is my birthday so i have already give to myself a gift with this patch :-)! Further proceedings: in the past we checked for default contempt that it doesn't regress against contempt 0. Now that the later is stronger and the former is the same strength this should be rechecked. Perhaps the default contempt have to be lowered. It would be interesting to get some idea of the impact of this patch outside of the 0-24 contempt range. STC: (both with contempt=0) LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 21912 W: 3898 L: 3740 D: 14274 Elo +2.51 http://tests.stockfishchess.org/tests/view/5db74b6f0ebc5902d1f37405 LTC: (both with contempt=0) LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 27172 W: 3350 L: 3126 D: 20696 Elo +2.86 http://tests.stockfishchess.org/tests/view/5db760020ebc5902d1f375d0 Closes https://github.com/official-stockfish/Stockfish/pull/2382 No functional change (for current default contempt 24). 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 Oct 26 01:10:55 2019 +0200 Timestamp: 1572045055 Refactor final stats updates. This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done. Effectively, all stat updates that need to be done after search is finished and a bestmove is found, are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```. The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```. ```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture). passed non-regression STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 75196 W: 16364 L: 16347 D: 42485 Elo +0.08 http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1 The diff is most easily readable as ```git diff master --patience``` 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: Sat Oct 26 00:29:12 2019 +0200 Timestamp: 1572042552 Assorted trivial cleanups - Cleanups by Alain - Group king attacks and king defenses - Signature of futility_move_count() - Use is_discovery_check_on_king() - Simplify backward definition - Use static asserts in move generator - Factor a statement in move generator No functional change see source |