Stockfish Testing Queue

Finished - 1117 tests

18-07-27 31m ThreatByRank_blocked diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 29749 W: 6713 L: 6696 D: 16340
sprt @ 10+0.1 th 1 Include @locutus2's bugfix and retry this STC. Only include the blocked enemy pawns that we block. Enemy pieces blocking enemy pawns may move out of the way.
18-07-27 31m ThreatByRank_blocked^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 15834 W: 3524 L: 3577 D: 8733
sprt @ 10+0.1 th 1 Thanks to @locutus2 who spotted my error and corrected me. Retry this version with his bugfix included. Include blocked pawns in ThreatByRank with half effect, alongside the recently added king-pinned pawns.
18-07-26 31m simplify_RookOnPawn2a diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 54991 W: 9381 L: 9316 D: 36294
sprt @ 60+0.6 th 1 LTC after merging new master. Retire RookOnPawn score, replacing it with ThreatByRook[PAWN], and add middlegame components to ThreatByRook[PAWN] and ThreatByMinor[PAWN] to compensate.
18-07-26 31m ThreatByRank_blocked diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 32166 W: 7182 L: 7154 D: 17830
sprt @ 10+0.1 th 1 An idea taking inspiration from both @locutus2's recent passed patch and @Rocky640's tests with Overload for blocked pawns. Include blocked pawns in ThreatByRank with half effect, alongside the recently added king-pinned pawns.
18-07-26 31m simplify_RookOnPawn2 diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 26090 W: 5827 L: 5714 D: 14549
sprt @ 10+0.1 th 1 A sudden realization: RookOnPawn is S(8, 24), but ThreatByRook[PAWN] is already S(0, 24), and my previous tweak_threatOnPawn tests have consistently found a slight Elo gain (~0.5 Elo) by adding middlegame components of 6 cp to ThreatByRook[PAWN] and ThreatByMinor[PAWN]. Therefore, having a separate score for RookOnPawn seems unnecessary; replace it with ThreatByRook[PAWN] (which is conceptually very similar) and tweak to compensate. The ultimate effect is that rook threats on pawns are given a bonus of size ThreatByRook[PAWN], or double that if the rook is on the fifth relative rank or higher.
18-07-26 31m simplify_RookOnPawn2 diff
LLR: -2.95 (-2.94,2.94) [-3.00,1.00]
Total: 21132 W: 4563 L: 4769 D: 11800
sprt @ 10+0.1 th 1 Also try a version with full compensation in ThreatByRook (i.e., S(8, 24) rather than S(6, 24)) and no change to ThreatByMinor to compensate for this tweak (i.e., S(0, 31) rather than S(6, 31)).
18-07-26 31m ThreatByRank_blocked diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 18754 W: 4129 L: 4168 D: 10457
sprt @ 10+0.1 th 1 Only include the blocked enemy pawns that we block. Enemy pieces blocking enemy pawns may move out of the way.
18-07-26 31m ThreatByPiece_blocked diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 16213 W: 3567 L: 3618 D: 9028
sprt @ 10+0.1 th 1 I am encouraged by the results so far from ThreatByRank_blocked. Also try an approach closer to sg's pinned_threat.
18-07-26 31m simplify_RookOnPawn diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 9194 W: 1941 L: 2124 D: 5129
sprt @ 10+0.1 th 1 Inspired by a fairly recent, long yellow STC [0, 4] by @Rocky640: RookPawnV5, computing RookOnPawn only if on a semi-open file. If we are on a semi-open file, we may easily be able to move to the fifth relative rank, so try simplifying away this condition. Move RookOnPawn inside the existing semi-open file if statement to compensate.
18-07-26 31m ThreatByRank_Qpin^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 21120 W: 4675 L: 4702 D: 11743
sprt @ 10+0.1 th 1 Half effect (i.e., / 4 rather than / 2). Include @locutus2's simplification/improvement generalizing this to multiple queens.
18-07-26 31m ThreatByPiece_Qpin diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 9754 W: 2067 L: 2150 D: 5537
sprt @ 10+0.1 th 1 A similar idea, but built on the ideas in sg's pinned_threat rather than his ThreatByRank.
18-07-26 31m ThreatByRank_Qpin diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 10304 W: 2255 L: 2336 D: 5713
sprt @ 10+0.1 th 1 Double effect. Include @locutus2's simplification/improvement generalizing this to multiple queens.
18-07-25 31m ThreatByRank_Qpin diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 20966 W: 4662 L: 4690 D: 11614
sprt @ 10+0.1 th 1 Consider also pawns that are pinned to the queen. Test against sg's passed patch.
18-07-25 31m overload_pawns3 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 21707 W: 4813 L: 4837 D: 12057
sprt @ 10+0.1 th 1 Recently, simply adding pawns to Overload--S(16, 7) at the time--seemed roughly Elo-neutral. Perhaps we can do better by introducing a separate bonus with smaller values. S(4, 4).
18-07-25 31m overload_pawns3 diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 20830 W: 4589 L: 4618 D: 11623
sprt @ 10+0.1 th 1 S(8, 4).
18-07-25 31m overload_pawns3 diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 15563 W: 3440 L: 3495 D: 8628
sprt @ 10+0.1 th 1 S(4, 8).
18-07-25 31m overload_noQ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 24899 W: 5507 L: 5515 D: 13877
sprt @ 10+0.1 th 1 Exclude the queen as a target of overloading, i.e., as an attacked and defended piece. (Such a queen will most likely be traded shortly, possibly in a favorable exchange. This does not reflect the long-term positional tension often present in other types of Overload.)
18-07-24 31m overload_noK diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 15986 W: 3494 L: 3547 D: 8945
sprt @ 10+0.1 th 1 Previous attempts to add king-specific Overload (on top of the generic one) have failed, sometimes badly. However, the king defends the weak pieces in many Overload cases; I wonder if these should be included or not. Exclude from Overload pieces which are king-defended. Test with passed tweak included.
18-07-24 31m overload4a diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 25100 W: 5607 L: 5614 D: 13879
sprt @ 10+0.1 th 1 S(5, 10).
18-07-24 31m overload4a^ diff
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 20127 W: 4380 L: 4412 D: 11335
sprt @ 10+0.1 th 1 S(10, 5).
18-07-24 31m overload4a^^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 18416 W: 4034 L: 4075 D: 10307
sprt @ 10+0.1 th 1 Experiment with some different OverloadedPin values, with @goodkov's simplification included. S(15, 15). (Original was S(10, 10).)
18-07-23 31m overload4a diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 29678 W: 6554 L: 6539 D: 16585
sprt @ 10+0.1 th 1 The most recent LTC failed very quickly; apparently I need to return to STC testing, as merging in the interacting patches dramatically changes the results. Include @goodkov's simplification as part of my [0, 5], tested against the passed tweak.
18-07-23 31m overload4a diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 7827 W: 1286 L: 1378 D: 5163
sprt @ 60+0.6 th 1 It currently appears that the tweak will be committed shortly, but the simplification will not (since it failed LTC against the tweak). Test with the passed parameter tweak merged, but not the simplification. (There is already evidence of interaction between these three Overload patches, and the inclusion of the tweak has improved the performance of overload pin previously.) Test directly at LTC because overload4 already passed STC.
18-07-23 31m overload5 diff
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 8533 W: 1829 L: 1918 D: 4786
sprt @ 10+0.1 th 1 Try a smaller effect, S(10, 0), also applied to non-pawn enemies only. Test with the newly passed simplification and the newly passed tweak merged into both the base and test branches.
18-07-23 31m overload4^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 25971 W: 4444 L: 4462 D: 17065
sprt @ 60+0.6 th 1 LTC. Since the Overload conditions have changed so dramatically in recent days, let's retry some old ideas which showed some promise. Here, extra bonus for overload on pins. Test against the recent passed simplification.
18-07-22 31m overload4 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 38255 W: 8568 L: 8509 D: 21178
sprt @ 10+0.1 th 1 Pin overload; use only nonPawnEnemies. Test against recent passed simplification.
18-07-22 31m overload5 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 28608 W: 6413 L: 6402 D: 15793
sprt @ 10+0.1 th 1 Queen overload; use only nonPawnEnemies. Test against recent passed simplification.
18-07-22 31m overload4 diff
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 21812 W: 4970 L: 4729 D: 12113
sprt @ 10+0.1 th 1 Since the Overload conditions have changed so dramatically in recent days, let's retry some old ideas which showed some promise. Here, extra bonus for overload on pins. Test against the recent passed simplification.
18-07-22 31m overload5 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 10605 W: 2311 L: 2390 D: 5904
sprt @ 10+0.1 th 1 Extra bonus for queen overload. Test against the recent passed simplification.
18-07-22 31m tweak_threatOnPawn3 diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 41974 W: 9317 L: 9315 D: 23342
sprt @ 10+0.1 th 1 Since the large LTC king/pawn tuning runs appear to have ended for now, I would like to retry this pawn tweak that has given long yellow STC and LTC runs in the past, prior to the most recent tuning run(s). Nonzero middlegame components for ThreatByMinor[PAWN] and ThreatByRook[PAWN].
18-07-22 31m OverloadBlockPin diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 14220 W: 3189 L: 3250 D: 7781
sprt @ 10+0.1 th 1 My take on @Rocky640's 81K yellow. In addition to considering blocked pawns for overload, also consider pinned pawns, since they are similarly immobile.
18-07-21 31m BackRanksMobQ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 16285 W: 3573 L: 3624 D: 9088
sprt @ 10+0.1 th 1 Mobility along the back ranks may actually be useful if we have rooks (even though we did in LC0 1-0 SF), i.e., for setting up attacks along (semi-)open files. Exclude these cases. If we have no rooks, then cap the number of squares our back two ranks can contribute to queen mobility to a maximum of 5.
18-07-21 31m BackRanksMobQ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 9434 W: 2025 L: 2110 D: 5299
sprt @ 10+0.1 th 1 I was surprised to see the other tests on this branch fail so quickly. Try limiting the scope to just the back rank; cap the mobility on this rank to 5 (out of a maximum 7).
18-07-20 31m BackRanksMobQ^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 6722 W: 1409 L: 1507 D: 3806
sprt @ 10+0.1 th 1 Cap at 5 (i.e., three quarters of a full rank), half of the current maximum.
18-07-20 31m BackRanksMobQ^^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 6766 W: 1448 L: 1546 D: 3772
sprt @ 10+0.1 th 1 Another idea inspired by LC0 1-0 SF. In several positions in the later stages of the game (e.g., 7q/2p3k1/1p1pBR2/p7/2Pr4/5RP1/5PK1/8 w - - 6 41) SF's static eval favors Black, though White seems winning. A large component of this is the enormous mobility of Black's queen, but here it is stuck on h8 harmlessly threatening to move along Black's back rank. Cap how much mobility a queen can have in its back two ranks. Here, a mild reduction: 7 (i.e., one whole rank) compared to the old maximum of 10.
18-07-20 31m BackRanksMobQ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 3915 W: 839 L: 952 D: 2124
sprt @ 10+0.1 th 1 The most aggressive version (probably too much so): cap at 3 (i.e., half a rank).
18-07-20 31m stat_bonus_root_depth^^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 49440 W: 8456 L: 8379 D: 32605
sprt @ 60+0.6 th 1 Since the framework is empty, LTC for sg. "For my past cubic formula tests we had a fixed depth as break point (higher bonus below, smaller bonus above). But their doesn't scale well to LTC. Try now a moving break even point up by factoring in root depth (stat update measurements indicate a higher breakeven point at longer TC). Test against my passed evasion_cmh patch."
18-07-19 31m SoloQueenMob diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 15806 W: 3428 L: 3482 D: 8896
sprt @ 10+0.1 th 1 Even though imbalanced queen positions are uncommon, I'm surprised that such large changes are yielding Elo effects of very nearly 0. Keep increasing the size of the changes until we see an effect. Decrease mob by 3.
18-07-19 31m SoloQueenMob diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 20256 W: 4434 L: 4466 D: 11356
sprt @ 10+0.1 th 1 Previous test failed with a slightly positive Elo estimate; perhaps the effect was too small. Double it.
18-07-18 31m evasion_cmh^^ diff
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 12135 W: 2171 L: 1997 D: 7967
sprt @ 60+0.6 th 1 LTC for sg, since the framework is empty. Use contHistory[0] also in evasion move sorting.
18-07-18 31m SoloQueenMob diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 22428 W: 4926 L: 4947 D: 12555
sprt @ 10+0.1 th 1 Another try. If only we have a queen, decrement its mobility for the MobilityBonus. The idea is that queen mobility is absolutely essential in this imbalance, and somewhat low mobility should be viewed as worse than it normally would be.
18-07-18 31m ThreatOnSoloQueen diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 20348 W: 4468 L: 4499 D: 11381
sprt @ 10+0.1 th 1 Half effect, S(5, 5).
18-07-18 31m ThreatOnSoloQueen^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 10052 W: 2192 L: 2274 D: 5586
sprt @ 10+0.1 th 1 Framework is empty. Try a simple S(10, 10) bonus for any threat on the enemy queen, when we have no queen of our own.
18-07-18 31m ImbalancedQueenThreats diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 13332 W: 2925 L: 2991 D: 7416
sprt @ 10+0.1 th 1 The previous test fared quite poorly, despite being a relatively small change. Out of curiosity, what about the opposite--a 25% decrease?
18-07-18 31m ImbalancedQueenThreats diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 9645 W: 2093 L: 2177 D: 5375
sprt @ 10+0.1 th 1 Looking at queen-imbalanced positions from another angle; give 25% more KnightOnQueen and SliderOnQueen (threats on next moves against the enemy queen) when we have no queen of our own.
18-07-17 31m 99a3e3a2edd64f0da03ef43 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 21728 W: 4756 L: 4780 D: 12192
sprt @ 10+0.1 th 1 Since the framework is completely empty, I would like to address my concerns about whether this STC green was a fluke directly, by re-testing it. I do not intend to pursue LTC regardless of whether it passes; for information only.
18-07-17 31m KingDangerQueens2 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 8022 W: 1767 L: 1859 D: 4396
sprt @ 10+0.1 th 1 The complementary idea: endgame only.
18-07-17 31m KingDangerQueens2^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 4901 W: 1009 L: 1116 D: 2776
sprt @ 10+0.1 th 1 I'm starting to worry that the STC green was a fluke...restore that version, and try only applying the increased kingDanger to the middlegame penalty.
18-07-16 31m MobilityDangerQueens diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 21211 W: 4652 L: 4679 D: 11880
sprt @ 10+0.1 th 1 Increase mobility danger by 25%. This should generally be a smaller effect.
18-07-16 31m MobilityDangerQueens^ diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 21969 W: 4890 L: 4913 D: 12166
sprt @ 10+0.1 th 1 Try a mobility danger-based approach. If in the top quartile of mobility danger, increase king danger by 10%.