Stockfish Testing Queue

Finished - 977 tests

19-01-11 31m combo_190110 diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 18218 W: 3971 L: 4063 D: 10184
sprt @ 10+0.1 th 1 The KDC and F tweaks don't seem to perform well together. Try dropping one at a time from the large combo. Remove KDC from the combo.
19-01-11 31m fawn3 diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 8978 W: 1939 L: 2059 D: 4980
sprt @ 10+0.1 th 1 A different take. Enemy pawns in our king ring on the A or H files, which are neither attacked by our pawns nor weak. S(30, 30).
19-01-11 31m combo_190110 diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 17360 W: 3821 L: 3917 D: 9622
sprt @ 10+0.1 th 1 Merge new master and bugfix--I incorrectly implemented @snicolet's fawn2 (due to a mistake on my part when manually fixing a merge conflict with an earlier combo).
19-01-09 31m fawn diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 76128 W: 16610 L: 16402 D: 43116
sprt @ 10+0.1 th 1 Half effect for the a-file.
19-01-10 31m fawn2 diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 24131 W: 5276 L: 5321 D: 13534
sprt @ 10+0.1 th 1 Try again, ignoring castling rights. Half penalty regardless of king position along the back rank, full penalty if on the outer two files on the same side as the fawn pawn.
19-01-10 31m combo_KDC_F diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 18585 W: 4022 L: 4113 D: 10450
sprt @ 10+0.1 th 1 Just the two most recent and most promising [0, 4]s, both by @snicolet.
19-01-10 31m combo_190110 diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 18012 W: 3969 L: 4062 D: 9981
sprt @ 10+0.1 th 1 Combination of eight promising tweaks. I have erred on the side of inclusion for anything that looked promising in recent (since Dec. 14) combo or standalone attempts.
19-01-10 31m fawn2 diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 9452 W: 2001 L: 2119 D: 5332
sprt @ 10+0.1 th 1 I have been asked to try to maintain symmetry here--yet the asymmetric version (1/2 effect for queenside) is my best so far. Maybe the key is king position after all--we are more likely to be castled or able to castle kingside. Full effect if on the outer two files, half effect if able to castle there.
19-01-10 31m hinderBishop diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 10142 W: 2182 L: 2296 D: 5664
sprt @ 10+0.1 th 1 The opposite: knight only.
19-01-09 31m hinderBishop diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 17422 W: 3727 L: 3806 D: 9889
sprt @ 10+0.1 th 1 Much closer to @ElbertoOne's test. However, knights are harder to block than bishops--so I wonder if this penalty ought to only be applied to bishops.
19-01-09 31m fawn_passer diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 16712 W: 3612 L: 3694 D: 9406
sprt @ 10+0.1 th 1 First attempt at a proposal by @Vizvezdenec, although the code is a bit ugly for now. If an enemy fawn pawn and our king are on one side (files ABC or FGH), and an enemy passer is on the other, give a large penalty.
19-01-09 31m hinderMinor diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 9994 W: 2134 L: 2249 D: 5611
sprt @ 10+0.1 th 1 Derivative of @ElbertoOne's idea. Penalty if the king blocks the forward mobility of our minor--i.e., if the minor attacks our king and the king is in front of the minor.
19-01-09 31m fawn2 diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 15215 W: 3268 L: 3357 D: 8590
sprt @ 10+0.1 th 1 Trying to refine the conditions for fawn pawns. Return to kingside-only for now; require that we not have a pawn on g2/g7, rather than requiring that we have one on g3/g6. In other words, this allows cases where the g-pawn is further advanced or captured.
19-01-09 31m fawn diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 35008 W: 7618 L: 7610 D: 19780
sprt @ 10+0.1 th 1 f1, f2, g1, or h1, and the equivalent squares for Black.
19-01-09 31m fawn diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 25103 W: 5452 L: 5493 D: 14158
sprt @ 10+0.1 th 1 A bug in my previous test ignored the king's position altogether--an idea I was about to test in any case. It actually appears to be an improvement so far. Move this code to pawns.cpp's main evaluation (not king safety) and try increasing to S(20, 30) from S(15, 15) at @noobpwnftw's recommendation.
19-01-09 31m fawn diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 18391 W: 3922 L: 3996 D: 10473
sprt @ 10+0.1 th 1 Include a-file fawn pawns with equal effect size to h-file ones.
19-01-09 31m fawn diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 12041 W: 2595 L: 2700 D: 6746
sprt @ 10+0.1 th 1 Based on @noobpwnftw's work. Also apply FawnPawn if the king is on f1/f8 or if it is able to castle kingside. The latter especially should increase the effect size.
19-01-08 31m simplify_outpost3 diff
LLR: 0.22 (-2.94,2.94) [-3.00,1.00]
Total: 250 W: 51 L: 40 D: 159
sprt @ 60+0.6 th 1 LTC. Functionally equivalent to STC-passed version, but with cleanup by @snicolet.
19-01-09 31m RestrictedByKing diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 9525 W: 2043 L: 2160 D: 5322
sprt @ 10+0.1 th 1 I am trying to refine RestrictedPiece, and a vital part of that is stronglyProtected. Refine stronglyProtected using Alayan's ideas first, and then add the new logic to RestrictedPiece.
19-01-09 31m RestrictedByKing diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 15561 W: 3407 L: 3495 D: 8659
sprt @ 10+0.1 th 1 Exclude squares where our king or queen is attempting to restrict the enemy alone.
19-01-08 31m RestrictedByKing diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 51289 W: 11172 L: 11085 D: 29032
sprt @ 10+0.1 th 1 @Vizvezdenec's suggestion.
19-01-08 31m RestrictedByKing diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 24702 W: 5301 L: 5344 D: 14057
sprt @ 10+0.1 th 1 With more precise handling of the king case, can we accept a larger RestrictedPiece bonus? Restore this promising version and increase RestrictedPiece.
19-01-08 31m simplify_outpost3 diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 33903 W: 7515 L: 7418 D: 18970
sprt @ 10+0.1 th 1 Less dramatic change. Simplify away the PieceType dimension of the Outpost array; then, simply double the bishop values if Pt == KNIGHT, just as we already double them if the outpost is immediately occupied rather than available.
19-01-08 31m RestrictedByKing diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 36185 W: 7873 L: 7860 D: 20452
sprt @ 10+0.1 th 1 No middlegame component (when king safety is most important) for RestrictedPiece where our king is the piece restricting the enemy.
19-01-08 31m RestrictedByKing diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 12841 W: 2753 L: 2854 D: 7234
sprt @ 10+0.1 th 1 Based on more ideas helpfully provided by @Vizvezdenec. Use more careful king handling in the middlegame--excluding king-only attacks--but leave the endgame component untouched.
19-01-08 31m simplify_outpost2 diff
LLR: -2.95 (-2.94,2.94) [-3.00,1.00]
Total: 10262 W: 2156 L: 2340 D: 5766
sprt @ 10+0.1 th 1 Our master logic in handling the 8 possible cases of outpost seems inconsistent. Sometimes we handle linear dependencies with a simple equation (on an outpost vs. able to reach one; we multiply by 2 in the former), but sometimes we unroll the values into a multidimensional array (the other conditions). It seems we may be able to calculate all 8 cases with a single base Score and an equation of a few additions, a few multiplications, and one ternary operator. This seems more consistent.
19-01-07 31m RestrictedQueen diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 24819 W: 5391 L: 5433 D: 13995
sprt @ 10+0.1 th 1 Narrower version: don't include restriction of the enemy queen done by our own queen.
19-01-07 31m RestrictedByKing diff
LLR: -3.57 (-2.94,2.94) [0.50,4.50]
Total: 14481 W: 3064 L: 3191 D: 8226
sprt @ 10+0.1 th 1 Don't count enemy attacks restricted by our king in RestrictedPiece. If anything, we should penalize these squares in king danger, not allocate bonus for them.
19-01-07 31m RestrictedQueen^ diff
LLR: -2.94 (-2.94,2.94) [0.50,4.50]
Total: 13563 W: 2891 L: 2988 D: 7684
sprt @ 10+0.1 th 1 +50% RestrictedPiece for restricting the enemy's queen attacks specifically.
19-01-07 31m respin_PDS diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 27778 W: 6031 L: 6059 D: 15688
sprt @ 10+0.1 th 1 Respin this idea from last June, since I think it's still relevant to SF's (mis?)-evaluation of passers.
19-01-07 31m moreDoubled_Viz diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 16714 W: 3579 L: 3661 D: 9474
sprt @ 10+0.1 th 1 Constant tweak of @Vizvezdenec's 111K yellow (moreDoubled8) from Dec. 28. Use endgame-only S(0, 50) rather than S(10, 40).
18-12-29 31m combo_CE_PF diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 47592 W: 10388 L: 10365 D: 26839
sprt @ 10+0.1 th 1 Try without the combo_O_SS tweaks, in case they are producing the worse-than-expected results. (I have kept CE and PF because they are very recent positive results.)
18-12-29 31m combo_O_SS_CE_PF diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 24856 W: 5442 L: 5508 D: 13906
sprt @ 10+0.1 th 1 I overlooked the fact that @snicolet had a better CloseEnemies tweak than the one I used. Try again with this one.
18-12-28 31m combo_O_SS_CE_PF diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 69764 W: 15253 L: 15143 D: 39368
sprt @ 10+0.1 th 1 Merge @snicolet's tweak_closeenemies^^ (STC 59K yellow) and @Vizvezdenec's KDreodree3 (STC 98K green, LTC 64K yellow) into my existing combo_O_SS (82K STC yellow, 98K LTC yellow), which hopefully will be a helpful vehicle for these other two promising tweaks. (If this passes STC, are the correct LTC bounds [0, 4] or [0, 3.5]?)
18-12-28 31m tweak_CloseEnemies diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 25887 W: 5627 L: 5689 D: 14571
sprt @ 10+0.1 th 1 S(10, 0).
18-12-27 31m tweak_CloseEnemies diff
LLR: -2.94 (-2.94,2.94) [0.00,4.00]
Total: 53383 W: 11550 L: 11505 D: 30328
sprt @ 10+0.1 th 1 S(9, 0).
18-12-27 31m tweak_CloseEnemies^ diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 31764 W: 6910 L: 6949 D: 17905
sprt @ 10+0.1 th 1 S(7, 0).
18-12-27 31m tweak_CloseEnemies^^ diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 17441 W: 3758 L: 3854 D: 9829
sprt @ 10+0.1 th 1 S(6, 0).
18-12-27 31m tweak_CloseEnemies^^^ diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 8898 W: 1909 L: 2038 D: 4951
sprt @ 10+0.1 th 1 Now that the quartic tropism term (in king danger) is always applied, try tweaking CloseEnemies. Half: S(4, 0).
18-12-27 31m simplify_CloseEnemies diff
LLR: -2.95 (-2.94,2.94) [-3.00,1.00]
Total: 6496 W: 1365 L: 1543 D: 3588
sprt @ 10+0.1 th 1 Before today's king safety simplification, CloseEnemies served as a linear middlegame-only tropism penalty even when king safety was otherwise not evaluated, analogous to a "lazy eval" for king safety. Now, however, a 4th-degree tropism penalty is applied in every position (quadratic in kingDanger, which is itself quadratic). Do we still need CloseEnemies at all?
18-12-27 31m simplify_kingsafety diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35432 W: 7815 L: 7721 D: 19896
sprt @ 10+0.1 th 1 Inspired by recent tests by xoto, Vizvezdenec, and myself. Always initialize king safety and always evaluate it, regardless of non-pawn material, king attackers, tropism, or other factors. Note: most of this diff consists of whitespace changes, because I removed if statements with large blocks of code. Append "?w=1" (no quotes) to the diff's GitHub URL to ignore whitespace differences and make viewing the diff much easier.
18-12-26 31m kingsafety_PD diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 43525 W: 9554 L: 9504 D: 24467
sprt @ 10+0.1 th 1 Use both tropism (@Vizvezdenec) and piece difference conditions to activate king safety evaluation.
18-12-26 31m kingsafety_Viz3^ diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 22142 W: 4859 L: 4914 D: 12369
sprt @ 10+0.1 th 1 As far as I can tell, these tests have always required non-pawn material of at least a rook and knight. Perhaps what is needed is a narrower condition--a higher NPM threshold. Try RNN rather than RN.
18-12-26 31m kingsafety_Viz3 diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 16442 W: 3599 L: 3682 D: 9161
sprt @ 10+0.1 th 1 Try RR (opponent must have NPM equivalent to at least two rooks).
18-12-26 31m kingsafety_PD diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 34234 W: 7349 L: 7346 D: 19539
sprt @ 10+0.1 th 1 Larger effect: do king safety if the opponent has even one extra attacker.
18-12-26 31m kingsafety_PD^ diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 18085 W: 3885 L: 3960 D: 10240
sprt @ 10+0.1 th 1 Investigate whether the old PieceDifference idea could be useful for determining when to evaluate king safety. Evaluate king safety if the NPM condition from @Vizvezdenec's tests is met and the opponent has more than one extra (non-pawn, non-king) attacker in our kingFlank and Camp.
18-12-25 31m kingsafety_Viz2 diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 22401 W: 4860 L: 4914 D: 12627
sprt @ 10+0.1 th 1 My PR #1807 simplification was based on the fact that ~attackedBy[Us][PAWN] didn't seem to change Elo performance. However, it could help modulate and interact with the effect size of @Vizvezdenec's patch, without itself introducing an Elo loss in the other uses of tropism. Let's see if this helps.
18-12-25 31m tropism_passer diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 16690 W: 3631 L: 3713 D: 9346
sprt @ 10+0.1 th 1 Double effect.
18-12-25 31m kingsafety_Viz2 diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 13212 W: 2812 L: 2911 D: 7489
sprt @ 10+0.1 th 1 Making this struggling (180K games and counting) LTC pass by increasing the most obvious factor in its effect size, its threshold, has been tried...but we could also try to increase tropism itself. I recently had a promising idea that does this...
18-12-25 31m kingsafety_Viz diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 21375 W: 4629 L: 4688 D: 12058
sprt @ 10+0.1 th 1 (Resubmit with new bounds!) A tweak of @Vizvezdenec's promising idea: if the opponent has sufficient material, certain special cases may merit king safety evaluation regardless of kingAttackersCount. In addition to the tropism case by @Vizvezdenec, evaluate king safety if our king flank has no friendly pawns. Note that this differs from PawnlessFlank, which considers pawns of either color and is concentrated on the endgame rather than middlegame.