Stockfish Testing Queue

Finished - 977 tests

18-12-15 31m RookOnQueen^ diff
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 15159 W: 3398 L: 3193 D: 8568
sprt @ 10+0.1 th 1 Attempt to revive my threat_strongqueen idea with a RookOnPawn-style approach (i.e., based on the rook's rank). Use ThreatByRook[QUEEN] / 2 for now, since it worked well in my previous attempts.
18-12-15 31m RookOnQueen diff
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 13189 W: 2880 L: 2946 D: 7363
sprt @ 10+0.1 th 1 Use b rather than pseudo-attacks.
18-12-14 31m tweak_pruningT diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 79171 W: 17340 L: 17193 D: 44638
sprt @ 10+0.1 th 1 @VoyagerOne's commit "Tweak CMH pruning" commit appears to have made my recent simplification, originally written by @xoto10, work when it previously did not. Changes in this part of search.cpp appear to interact. @VoyagerOne's very recent pruningT also appears like it should interact with these changes, based on its code. Since the framework is empty of normal-priority patches, I would like to see it retested, rebased on PR #1870 (simplify_pruningNPM).
18-12-13 31m tweak_pruningNPM4 diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 63156 W: 10310 L: 10265 D: 42581
sprt @ 60+0.6 th 1 The LTC [0, 5] against the simplification led to a frustratingly ambiguous result--a long yellow run. If this is +1.14 LTC Elo against the simplification, and the simplification is +0.66 LTC Elo against master, in principle this simple [0, 4] could be a clean Elo gain. Merge new master and try. This should be my last test: if this passes, I'll open this [0, 4] PR; otherwise, I'll open a [-3, 1] PR for the successful simplification.
18-12-13 31m tweak_pruningNPM4 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 68472 W: 11277 L: 11130 D: 46065
sprt @ 60+0.6 th 1 @Vizvezdenec's suggestion: I now have both a STC green [0, 4] for this code and a passed STC/LTC [-3, 1] to remove it. Try re-adding this complexity with the [0, 4] tweak added, and test as [0, 5] against the passed simplification. Test directly at LTC because both patches already passed STC against master. (Anticipated result is roughly Elo-neutral failure, but this is fairly speculative, based on the similar STC Elo gains for both patches.) I currently plan on waiting for the result of this test and then opening my PR (or PRs).
18-12-13 31m simplify_pruningNPM diff
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33868 W: 5663 L: 5563 D: 22642
sprt @ 60+0.6 th 1 LTC. I am submitting this LTC even though the [0, 4] conflicts with it and is also performing well--this is the same change as the [0, 4], only further, and has a similar Elo estimate so far. Therefore I would initially guess that that patch could be successfully simplified into this one, if this passes LTC.
18-12-13 31m tweak_pruningNPM4 diff
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 20685 W: 4623 L: 4378 D: 11684
sprt @ 10+0.1 th 1 Further increase: value 15,000.
18-12-13 31m simplify_pruningNPM diff
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 13445 W: 3000 L: 2862 D: 7583
sprt @ 10+0.1 th 1 Increasing this threshold by degrees I originally thought would be ridiculous actually seems slightly Elo-gaining (6K, 7K, 8K, 10K all produced long yellow [0, 4] runs; 15K appears to possibly be promising at the moment). As this threshold increases, this condition activates less and less often but Elo seems to slightly increase. Can we simplify it away altogether?
18-12-12 31m tweak_pruningNPM4 diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 72660 W: 15850 L: 15729 D: 41081
sprt @ 10+0.1 th 1 Value 8000.
18-12-12 31m tweak_pruningNPM4 diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 55411 W: 12127 L: 12073 D: 31211
sprt @ 10+0.1 th 1 6000, 7000, and 8000 all have positive scores but appear insufficient to pass. (The first two were tested on Dec. 1.) Try a radical increase: double. Value 10,000.
18-12-12 31m threat_strongqueen2 diff
ELO: 0.13 +-2.3 (95%) LOS: 54.5%
Total: 40000 W: 8788 L: 8773 D: 22439
40000 @ 10+0.1 th 1 I would like to revive this idea of mine from Nov. 29, but master has changed and it might not still perform well. Quickly check performance before pursuing tuning of a new Score here. I have chosen a fixed number of games because (a) this is for information only and (b) this test has produced very long yellow runs in the past (70K STC, 108K LTC), so this seems like a more efficient use of framework resources. STC because previous results seem to indicate good scaling.
18-12-08 31m extend_abnormal diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 12420 W: 2668 L: 2783 D: 6969
sprt @ 10+0.1 th 1 Tweak to castling extension: extend moves where type_of(move) != NORMAL (that is, promotion, en passant, or castling).
18-12-03 31m queen_attacks3 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 2168 W: 421 L: 542 D: 1205
sprt @ 10+0.1 th 1 Sanity check: queen attacks through bishop (which has always performed poorly so far) and rook, but preserving attackedBy2. (I want to make sure the bishop problem isn't specific to attackedBy2.) Expect quick failure.
18-12-03 31m queen_attacks3 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 44887 W: 9798 L: 9709 D: 25380
sprt @ 10+0.1 th 1 I typed "Us" instead of "s" by accident...and somehow it still compiled and ran! Let's try what I actually intended.
18-12-03 31m queen_attacks3 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 20102 W: 4319 L: 4352 D: 11431
sprt @ 10+0.1 th 1 Another experiment based on discussion with @Rocky640, although it diverges from the original idea discussed with Bryan. Preserve attackedBy2 and only update attackedBy. Rook case only (no bishops), along the file only.
18-12-03 31m queen_attacks3 diff
LLR: -0.64 (-2.94,2.94) [0.00,5.00]
Total: 437 W: 77 L: 103 D: 257
sprt @ 10+0.1 th 1 Rank-and-file approach, but updating only attackedBy (not attackedBy2).
18-12-02 31m queen_attacks diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 40512 W: 8824 L: 8757 D: 22931
sprt @ 10+0.1 th 1 Based on discussion with Bryan. Allow the queen to attack through friendly rooks on the same file. Calculate this before updating attackedBy tables but after Mobility is calculated, because I'm skeptical of making such a large change to such a highly tuned and enormous bonus.
18-12-02 31m queen_attacks diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 13496 W: 2961 L: 3026 D: 7509
sprt @ 10+0.1 th 1 Bugfix to the bugfix for queen_attacks, hopefully solving the pinning problem without enormous regression.
18-12-02 31m queen_attacks2^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 1812 W: 362 L: 486 D: 964
sprt @ 10+0.1 th 1 My attempts at handling pinning seem to make this worse, so instead, naively add the bishop case to the version that has done well at STC. If this fails quickly, either bishops just don't work with this idea, there's a terrible bug in this one-line addition (which I just can't seem to find), or there's an unexpected interaction with the recent change in master.
18-12-02 31m queen_attacks2 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 2053 W: 435 L: 559 D: 1059
sprt @ 10+0.1 th 1 Fixed version. Remove "& b" (it performs terribly) and solve the pinning problem by reordering the code so that the "pos.blockers_for_king(Us) & s" condition comes after the expansion of b.
18-12-02 31m queen_attacks2 diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 1423 W: 264 L: 390 D: 769
sprt @ 10+0.1 th 1 I'm finally ready to try the originally-intended all-sliders case discussed with Bryan and @protonspring. Add in bishops.
18-12-02 31m queen_attacks diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 333 W: 35 L: 172 D: 126
sprt @ 10+0.1 th 1 Merge new master and try a small change (possible bugfix?): I hadn't included "& b" because I thought it would be functionally equivalent, but I now realize it is needed when the queen is pinned. Since I'm not 100% sure this will be an improvement, even if more technically correct, I will leave the other test running for now.
18-12-02 31m queen_attacks diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 26660 W: 5765 L: 5766 D: 15129
sprt @ 10+0.1 th 1 Same rank or same file.
18-12-02 31m queen_attacks diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 317 W: 35 L: 176 D: 106
sprt @ 10+0.1 th 1 Realizing that some later uses of attackedBy[][QUEEN] seem to assume direct attacks, try reordering the code to only apply this expansion to attackedBy2.
18-12-02 31m overload_redux diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 13893 W: 3030 L: 3093 D: 7770
sprt @ 10+0.1 th 1 It occurs to me that some Overload cases are now covered by RestrictedPiece. Retry S(10, 5) but exclude RestrictedPiece to avoid inadvertently giving too much bonus.
18-12-02 31m SliderOnQueen_support diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 27637 W: 5997 L: 5993 D: 15647
sprt @ 10+0.1 th 1 Just the bishop case.
18-12-02 31m SliderOnQueen_support diff
LLR: -3.66 (-2.94,2.94) [0.00,5.00]
Total: 33402 W: 7256 L: 7255 D: 18891
sprt @ 10+0.1 th 1 Just the rook case mentioned by Bryan (not the bishop one), fixed.
18-12-02 31m DoubleProtectedKR1 diff
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 16530 W: 2795 L: 2607 D: 11128
sprt @ 60+0.6 th 1 LTC for @Vizvezdenec.
18-12-01 31m tweak_pruningNPM3 diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 32066 W: 5226 L: 5278 D: 21562
sprt @ 60+0.6 th 1 Rebase onto newest master and attempt a speculative LTC of this 141K yellow. Low throughput (166). I will attempt combo patches if this fails.
18-12-02 31m SliderOnQueen_support diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 32421 W: 7176 L: 7147 D: 18098
sprt @ 10+0.1 th 1 Bugfix: I forgot that SliderOnQueen also applies to bishops, not just rooks, and that case must be handled separately.
18-12-02 31m SliderOnQueen_support diff
LLR: -0.16 (-2.94,2.94) [0.00,5.00]
Total: 2870 W: 624 L: 617 D: 1629
sprt @ 10+0.1 th 1 On the forum, Bryan points out a case where SliderOnQueen is surprisingly blind, perhaps even bugged, with a queen supporting a rook along a file. (See FEN below.) The rook is not given a SliderOnQueen bonus because its landing square further down the file is not attackedBy2[Us]--a condition intended to make sure the landing square is defended--but it will be defended anyway, because the queen will support the rook. Try to fix this case, though it may be too narrow to pass. 7k/1np1br1q/1p1p3r/p2Pp1n1/P1P2pQ1/1NB2P1P/1P2N1PK/4R1R1 w - - 5 56
18-12-01 31m overload_redux diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 21502 W: 4620 L: 4646 D: 12236
sprt @ 10+0.1 th 1 Another of Overload's previous values (and to my knowledge, the last): S(13, 6).
18-12-01 31m overload_redux diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 38085 W: 8266 L: 8211 D: 21608
sprt @ 10+0.1 th 1 I am surprised by the trajectory of the Overload bonus over the course of its three simplifications. The first two (July 18; July 21) expanded its definition to include new positions, and the most recent (today) replaced it with only the newer positions. In other words, the original positions that once gave Elo gains have disappeared. Try a redux Overload patch--the original, narrow version from April--atop the new master.
18-12-01 31m overload_redux diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 24026 W: 5263 L: 5276 D: 13487
sprt @ 10+0.1 th 1 Try a different value this bonus has previously taken, S(16, 7).
18-12-01 31m tweak_pruningNPM diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 141852 W: 31156 L: 30763 D: 79933
sprt @ 10+0.1 th 1 Value 6000.
18-12-01 31m tweak_pruningNPM2 diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 122305 W: 26813 L: 26497 D: 68995
sprt @ 10+0.1 th 1 Value 7000.
18-12-01 31m tweak_pruningNPM2^ diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 67836 W: 14838 L: 14736 D: 38262
sprt @ 10+0.1 th 1 Both directions seem to be performing reasonably well, so try further change in each. Here, value 3000.
18-12-01 31m tweak_pruningNPM^ diff
LLR: -2.94 (-2.94,2.94) [0.00,4.00]
Total: 33740 W: 7356 L: 7387 D: 18997
sprt @ 10+0.1 th 1 Before simplifying away this condition, quickly check to make sure Elo can't be gained with an alternative value. Value 4000.
18-12-01 31m weakKD_attackedBy2^^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 30978 W: 6795 L: 6774 D: 17409
sprt @ 10+0.1 th 1 Half effect (coefficient 25).
18-12-01 31m weakKD_attackedBy2^^^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 19390 W: 4281 L: 4317 D: 10792
sprt @ 10+0.1 th 1 Give extra king danger for weak kingRing squares that are attacked twice by the enemy. Coefficient 50 (a random guess).
18-12-01 31m weakKD_attackedBy2^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 8195 W: 1787 L: 1878 D: 4530
sprt @ 10+0.1 th 1 A shot-in-the-dark attempt at compensation: reduce the singly-attacked case's coefficient.
18-12-01 31m weakKD_attackedBy2 diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 7266 W: 1526 L: 1622 D: 4118
sprt @ 10+0.1 th 1 A shot-in-the-dark attempt at compensation: reduce the constant term.
18-12-01 31m QueenRepulsion diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 8518 W: 1875 L: 1965 D: 4678
sprt @ 10+0.1 th 1 The opposite: endgame only. S(0, 15).
18-12-01 31m QueenRepulsion diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 23038 W: 5094 L: 5112 D: 12832
sprt @ 10+0.1 th 1 A different take on the threat_strongqueen idea. Rather than scaling ThreatByRook[QUEEN], introduce a separate bonus and try middlegame-only. S(25, 0).
18-11-30 31m threat_strongqueen diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 31213 W: 6770 L: 6749 D: 17694
sprt @ 10+0.1 th 1 Return to the simpler (and best so far) version and continue modulating effect size. Divisor 4.
18-11-30 31m threat_strongqueen diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 15873 W: 3421 L: 3475 D: 8977
sprt @ 10+0.1 th 1 See if this 70K STC yellow/108K LTC yellow can be made green. Require that the rook be defended.
18-11-30 31m threat_strongqueen diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 7804 W: 1638 L: 1731 D: 4435
sprt @ 10+0.1 th 1 Require further that the rook not be attacked by two enemies.
18-11-29 31m QueenOverload3 diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 22263 W: 3649 L: 3684 D: 14930
sprt @ 60+0.6 th 1 LTC for @Vizvezdenec.
18-11-29 31m threat_strongqueen^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 108414 W: 18179 L: 17870 D: 72365
sprt @ 60+0.6 th 1 This appears to be almost enough to pass STC (LLR < -2.5 after nearly 70K games). Speculative LTC, low throughput (166).
18-11-29 31m threat_strongqueen diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 70851 W: 15699 L: 15481 D: 39671
sprt @ 10+0.1 th 1 Half effect.