When D Green ? Madam
Posts : 358 Reputation : 1185 Join date : 2012-11-08 Location : Ten men waiting for me at the door? Send Rabbi Mordecai home, I'm tired of kosher pork Moslem meats Richer
| Subject: Latest aboke builds Mar 10th Sun Mar 11, 2018 4:28 pm | |
| !! latest version !!
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 |
| |
|