Stockfish Testing Queue

Pending - 0 tests 0.0 hrs

None

Active - 1 tests

18-12-19 31m combo_O_SS diff
LLR: 0.57 (-2.94,2.94) [0.00,4.00]
Total: 25544 W: 4340 L: 4228 D: 16976
sprt @ 60+0.6 th 1 Framework is completely empty, so speculative LTC for this 82K yellow. Low throughput (166).

Finished - 803 tests

18-12-19 31m combo_O_SRAP diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 6840 W: 1430 L: 1567 D: 3843
sprt @ 10+0.1 th 1 Combo: my tweak_outpost (STC 190K yellow; LTC 66K yellow) and @Rocky640's SpaceRankAndPawn (Aug. 29; STC 29K green; LTC 64K yellow).
18-12-19 31m combo_O_SS diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 82471 W: 18020 L: 17861 D: 46590
sprt @ 10+0.1 th 1 Beginning to search for other nearly-successful [0, 4]s to push my own (STC 190K yellow; LTC 66K yellow) through. Try @protonspring's ps_shelter31 (Nov. 14; STC 125K yellow; LTC 77K yellow).
18-12-18 31m tweak_outpost diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 66615 W: 11194 L: 11134 D: 44287
sprt @ 60+0.6 th 1 Speculative LTC for 190K yellow. Low throughput (166).
18-12-18 31m tweak_outpost diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 190243 W: 41786 L: 41203 D: 107254
sprt @ 10+0.1 th 1 For bishops and knights that can reach an outpost, require that the outpost square be unoccupied--not only by friendly pieces, but also enemy ones. Ideally we would like to make sure the outpost isn't defended, but we can't easily in this part of the code. However, I assume that we don't typically search positions where enemies occupy outposts and are clearly hanging--one side would be clearly winning--so perhaps this can serve as an indirect way of assessing outposts' defense.
18-12-18 31m simplify_outpost diff
LLR: -2.94 (-2.94,2.94) [-3.00,1.00]
Total: 36565 W: 7912 L: 8148 D: 20505
sprt @ 10+0.1 th 1 Do we need to check that we don't occupy the outpost square? If we do, we can still reach that outpost--it just takes two moves rather than one.
18-12-18 31m noMobPawnThreat diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 12962 W: 2764 L: 2832 D: 7366
sprt @ 10+0.1 th 1 ThreatByPawnPush, double effect.
18-12-18 31m noMobPawnThreat^ diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 23630 W: 5122 L: 5138 D: 13370
sprt @ 10+0.1 th 1 Derived from Bryan's ideas and analysis on Cscuile Game 27. Give extra ThreatByPawnPush if the enemy target has no mobility. Here, double.
18-12-18 31m noMobPawnThreat diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 12881 W: 2797 L: 2865 D: 7219
sprt @ 10+0.1 th 1 The analogous approach, applied to ThreatBySafePawn instead.
18-12-17 31m simplify_candidatePasse diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 93489 W: 20433 L: 20453 D: 52603
sprt @ 10+0.1 th 1 Experiment with the effect size of bonus in the simplified version. 3/4.
18-12-17 31m simplify_candidatePasse diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75116 W: 16227 L: 16539 D: 42350
sprt @ 10+0.1 th 1 Experiment with the effect size of bonus in the simplified version. 1/4.
18-12-17 31m simplify_candidatePasse diff
LLR: -2.95 (-2.94,2.94) [-3.00,1.00]
Total: 22215 W: 4765 L: 4973 D: 12477
sprt @ 10+0.1 th 1 Much more radical version: eliminate candidate passers altogether. (Performance of / 2 and / 4 seems similar, so there's a small chance it makes no difference at all.)
18-12-17 31m simplify_candidatePasse diff
LLR: -2.95 (-2.94,2.94) [-3.00,1.00]
Total: 42369 W: 6903 L: 7124 D: 28342
sprt @ 60+0.6 th 1 LTC. If we have two doubled pawns, which would otherwise be considered passed, do we need to not consider the back pawn passed?
18-12-17 31m simplify_candidatePasse diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 16750 W: 3707 L: 3576 D: 9467
sprt @ 10+0.1 th 1 If we have two doubled pawns, which would otherwise be considered passed, do we need to not consider the back pawn passed?
18-12-17 31m BlockSqAttack diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 20364 W: 4424 L: 4455 D: 11485
sprt @ 10+0.1 th 1 More complex logic: if the blocking square is enemy-occupied, we attack it, and it is either attacked by our pawn or not doubly defended.
18-12-16 31m BlockSqAttack diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 20633 W: 4514 L: 4544 D: 11575
sprt @ 10+0.1 th 1 My last attempt, handling a sub-case (~attackedBy[Them][PAWN]) only, was -2.2 Elo while the original was +0.85. Sanity check: try the opposite case.
18-12-16 31m BlockSqAttack diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 10160 W: 2176 L: 2257 D: 5727
sprt @ 10+0.1 th 1 @Vizvezdenec's suggestion. Make sure the blockSq isn't pawn-defended. (If we capture, then they can recapture with a pawn, and our pawn cannot become a passer.)
18-12-16 31m BlockSqAttack diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 32712 W: 7110 L: 7081 D: 18521
sprt @ 10+0.1 th 1 A passed pawn is safe to advance not only if the blockSq is empty, but if it is enemy-occupied and attacked by one of our pawns. (Since the pawn is passed, the enemy is not a pawn. Thus, this anticipates unblocked passed pawns one move early--the blocker is forced to move away.)
18-12-16 31m PinnedPasser diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 24126 W: 5271 L: 5284 D: 13571
sprt @ 10+0.1 th 1 A passed pawn is not "free to advance" if it is pinned to our king. Consider this to be the same as the case where the block square is occupied.
18-12-16 31m PinOpacity diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 6776 W: 1444 L: 1542 D: 3790
sprt @ 10+0.1 th 1 No attacks through pieces pinned to our king.
18-12-15 31m simplify_RestrictedPiec diff
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 37078 W: 6125 L: 6030 D: 24923
sprt @ 60+0.6 th 1 LTC. Use ~stronglyProtected to calculate RestrictedPiece.
18-12-15 31m RookOnQueen diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 42330 W: 9279 L: 9202 D: 23849
sprt @ 10+0.1 th 1 Double effect. Though this applies to a very narrow case, it is a substantial bonus.
18-12-15 31m RookOnQueen^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 25220 W: 5447 L: 5455 D: 14318
sprt @ 10+0.1 th 1 So far, it seems that increased effect size is an improvement. Try triple effect.
18-12-15 31m RookOnQueen diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 17899 W: 3978 L: 4021 D: 9900
sprt @ 10+0.1 th 1 Quadruple effect (2 * ThreatByRook[QUEEN]).
18-12-15 31m simplify_RestrictedPiec diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35924 W: 7978 L: 7885 D: 20061
sprt @ 10+0.1 th 1 A fairly intuitive simplification: ~stronglyProtected is quite similar to (and simpler than) ~attackedBy[Them][PAWN] & ~attackedBy2[Them]. The only difference is that this includes squares attacked twice by both sides.
18-12-15 31m RookOnQueen diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 39752 W: 8742 L: 8678 D: 22332
sprt @ 10+0.1 th 1 Apply the bonus if the rook is aligned with the enemy king and the enemy queen.
18-12-15 31m RookOnQueen^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 8046 W: 1279 L: 1370 D: 5397
sprt @ 60+0.6 th 1 LTC. 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.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.