Stockfish Testing Queue

Finished - 1408 tests

18-11-21 31m passerAttackBy2_2 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 15859 W: 3452 L: 3505 D: 8902
sprt @ 10+0.1 th 1 I now have two strong STCs which have scaled very poorly. Adapt the stronger of the two and apply it only to the middlegame eval. Since LTC spends more time in the endgame, perhaps this can preserve the strong STC performance while improving the awful scaling.
18-11-21 31m passerAttackBy2_2 diff
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 11578 W: 2588 L: 2401 D: 6589
sprt @ 10+0.1 th 1 Bugfix: My 5.2K red was meant to use "else if", not "if". Check whether this makes a significant difference; this could fail quickly.
18-11-21 31m passerAttackBy2_2 diff
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 5211 W: 1128 L: 1234 D: 2849
sprt @ 10+0.1 th 1 A narrower take on the best version so far: require that one of the two defenders be a rook. k += 2.
18-11-20 31m passerAttackBy2_2 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 7039 W: 1146 L: 1241 D: 4652
sprt @ 60+0.6 th 1 LTC (with new master merged). k += 2 for doubly protected passers.
18-11-19 31m simplify_kingdanger_pr diff
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75226 W: 12563 L: 12529 D: 50134
sprt @ 60+0.6 th 1 Merge new master and retest the LTC, as requested by @snicolet. See https://github.com/official-stockfish/Stockfish/pull/1821.
18-11-20 31m passerAttackBy2 diff
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 34399 W: 7677 L: 7376 D: 19346
sprt @ 10+0.1 th 1 Revisiting an old idea with a new approach, inspired by a game Bryan recently posted on the forum (Game 201 of Stage 3 of CCC Blitz Battle). k += 2 in the passed pawn evaluation if, despite a lack of defense on the promotion path, we doubly defend the pawn on its current square.
18-11-20 31m extend_discoverpawn diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 29978 W: 6604 L: 6588 D: 16786
sprt @ 10+0.1 th 1 Bryan's recent analysis of Game 201 of Stage 3 of CCC Blitz Battle raises an important pattern that, to my knowledge, we do not directly handle. A piece may be "pinned" indirectly if moving it allows a discovered check. This is most obvious when the opponent has a discovered check through a blocked pawn. Extend moves that unblock the pawn, by moving its blocking piece away or moving another piece to a square it can capture.
18-11-20 31m discoverpawn diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 28501 W: 6282 L: 6273 D: 15946
sprt @ 10+0.1 th 1 Rather than using an extension in search.cpp, try a simple S(15, 15) static eval bonus.
18-11-20 31m passerAttackBy2 diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 20115 W: 4381 L: 4414 D: 11320
sprt @ 10+0.1 th 1 Looks somewhat promising so far. Try double effect (k += 4).
18-11-17 31m simplify_kingdanger diff
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 164771 W: 26463 L: 26566 D: 111742
sprt @ 60+0.6 th 1 LTC: Delete the tropism term from kingDanger without compensation.
18-11-18 31m extend_Qexchange2 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 13316 W: 2756 L: 2822 D: 7738
sprt @ 10+0.1 th 1 The opposite: endgame only.
18-11-18 31m extend_Qexchange2^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 7481 W: 1601 L: 1696 D: 4184
sprt @ 10+0.1 th 1 I think there may still be an Elo-gainer in this area. Try extending queen exchanges only when we are in the opening/middlegame.
18-11-17 31m simplify_kingdanger diff
LLR: -2.95 (-2.94,2.94) [-3.00,1.00]
Total: 37797 W: 6037 L: 6249 D: 25511
sprt @ 60+0.6 th 1 LTC for -40. Let's see if this version scales better...
18-11-17 31m simplify_kingdanger diff
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33357 W: 7219 L: 7120 D: 19018
sprt @ 10+0.1 th 1 Constant term -40.
18-11-17 31m simplify_kingdanger diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 12518 W: 2795 L: 2656 D: 7067
sprt @ 10+0.1 th 1 No compensation--just delete the tropism term from kingDanger.
18-11-16 31m tweak_kptune diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 29123 W: 6292 L: 6342 D: 16489
sprt @ 10+0.1 th 1 I forgot to include some of the SPSA changes--sorry. Test the fixed version.
18-11-16 31m tweak_kptune diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 16689 W: 3586 L: 3685 D: 9418
sprt @ 10+0.1 th 1 Notably, almost every coefficient in kingDanger decreased in the large king/pawn tuning session. I think this seems suspicious--see if there's an Elo-gainer hiding in the other changes. Do not change king danger.
18-11-16 31m simplify_kingdanger diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 101948 W: 21641 L: 22002 D: 58305
sprt @ 10+0.1 th 1 Retry this simplification originally by @GuardianRM. There are at least three reasons to do this: (1) This was originally run as [0, 4], but I think [-3, 1] are the appropriate bounds; (2) I want to see how this interacts with my recent simplification/increase of tropism; (3) the coefficients from the big king/pawn tuning are trending in this direction for all three values modified here (this merely goes twice as far).
18-11-16 31m qWeight diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 40918 W: 6528 L: 6554 D: 27836
sprt @ 60+0.6 th 1 LTC for @xoroshiro: Other way.
18-11-16 31m extend_castle2 diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 44703 W: 9501 L: 9492 D: 25710
sprt @ 10+0.1 th 1 Extending only non-castling king moves that change castling rights is currently performing terribly. Try only extending castling itself. Do not extend king moves that change castling rights in general. (corrected bounds)
18-11-16 31m extend_castle2 diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 25834 W: 5505 L: 5511 D: 14818
sprt @ 10+0.1 th 1 A narrower condition than master (just castling moves, rather than king moves generally), compensated by a double (2 ply) extension.
18-11-15 31m extend_castle diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 14976 W: 3204 L: 3262 D: 8510
sprt @ 10+0.1 th 1 extension -= ONE_PLY instead. My motivation is that @GuardianRM's nearly successful patch seemed to do this for any rook move when we could castle. For example, if we could castle kingside, then moves from the queenside rook were also un-extended. Selectively apply that patch only to the rook that is breaking castling rights.
18-11-15 31m extend_castle diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 12948 W: 2677 L: 2745 D: 7526
sprt @ 10+0.1 th 1 Extend rook moves that change castling rights, not just king moves.
18-11-16 31m extend_castle2 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 6511 W: 1335 L: 1434 D: 3742
sprt @ 10+0.1 th 1 A smaller change to extension of moves that change castling rights: don't extend castling itself, only other king moves.
18-11-15 31m extend_castle diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 46930 W: 10043 L: 9947 D: 26940
sprt @ 10+0.1 th 1 A variation on @GuardianRM's almost-passed RookCastlingExtensions from a few days ago. Replace extension -= ONE_PLY with extension = DEPTH_ZERO: the former, I think, frequently results in an "extension" of -1 ply, which seems odd. (Extension is either 0 or 1 before this point in the code.)
18-11-15 31m extend_noshuffle diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 10644 W: 2231 L: 2310 D: 6103
sprt @ 10+0.1 th 1 For rule 50 counts between 20 and 30 (the range in @vondele's nearly successful LTC), subtract one ply from extension if the move is shuffling. This allows that extension < DEPTH_ZERO, but a patch that allowed that recently performed well (RookCastlingExtensions), so I'm not concerned by this.
18-11-15 31m extend_noshuffle diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 14131 W: 2957 L: 3019 D: 8155
sprt @ 10+0.1 th 1 Derived from @vondele's tests. Rather than extending moves that break the shuffling, cancel extensions for any shuffling move with 25 < rule50_count() < 50. Note: because of the required high rule50 count, this does not change bench. This doesn't mean it won't have a large effect, e.g., http://tests.stockfishchess.org/tests/view/5beb17780ebc595e0ae3596a
18-11-14 31m extend_Qexchange^ diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 19120 W: 4098 L: 4136 D: 10886
sprt @ 10+0.1 th 1 Based on @SFisGOD's recent Qext3. Expand on that definition of queen exchange to include not just cases where we take a queen with a queen, but also cases where we capture a queen with another piece but leave ours hanging. These are queen exchanges too.
18-11-14 31m extend_Qexchange diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 7779 W: 1610 L: 1703 D: 4466
sprt @ 10+0.1 th 1 Require that depth < 6 plies. (Depth < 12 doesn't seem to change the bench...)
18-11-13 31m extend_OCBcreation diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 8110 W: 1708 L: 1799 D: 4603
sprt @ 10+0.1 th 1 Add a depth condition, depth < 4 plies.
18-11-13 31m extend_OCBcreation diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 6854 W: 1415 L: 1512 D: 3927
sprt @ 10+0.1 th 1 Extension for moves that create OCB positions, i.e., (1) we have one bishop, (2) the opponent has two, and (3) the move captures a bishop of the same color as our own.
18-11-13 31m extend_Npromotion diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 8074 W: 1692 L: 1784 D: 4598
sprt @ 10+0.1 th 1 An attempt to directly implement an idea Mindbreaker posted on the forum's suggestions thread. Extend promotions to a knight. (I've tried a few things I haven't used before here; please check my work.)
18-11-13 31m extend_OCBcapture diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 6811 W: 1426 L: 1524 D: 3861
sprt @ 10+0.1 th 1 In OCB positions, extend captures of non-pawn material.
18-11-12 31m BishopThroughRook diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 23258 W: 5025 L: 5043 D: 13190
sprt @ 10+0.1 th 1 ThreatByMinor only, with half effect.
18-11-12 31m BishopThroughRook^^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 36239 W: 7764 L: 7719 D: 20756
sprt @ 10+0.1 th 1 Inspired by Bryan's work on TCEC 13 Superfinal Game 36 and @Rocky640's patch based on it. However, I think that modifying b directly is too broad a change, since it is used in many different contexts, some of which may be regressions (especially, I suspect, mobility). I think this is a more direct implementation of the original idea: add ThreatByMinor in this case but don't change other bonuses.
18-11-12 31m BishopThroughRook^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 11691 W: 2436 L: 2510 D: 6745
sprt @ 10+0.1 th 1 Try ThreatByRank for bishops through enemy rooks, not ThreatByMinor.
18-11-12 31m BishopThroughRook diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 7655 W: 1596 L: 1690 D: 4369
sprt @ 10+0.1 th 1 Do both, directly mirroring the original (defended | weak) & attackedBy[Us][BISHOP] case.
18-11-11 31m extend_QImbalance diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 22080 W: 4658 L: 4682 D: 12740
sprt @ 10+0.1 th 1 The version that extended only if depth < 2 performed much worse than the version that extended at all depths. This may just be the noisiness of the SPRT result, but just in case it isn't, try only extending if depth >= 4.
18-11-11 31m extend_QImbalance diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 18396 W: 3894 L: 3936 D: 10566
sprt @ 10+0.1 th 1 I don't know much about extensions, but inspired by the recent extension for king moves that change castling rights, I would like to try a small experiment. Positions where only one side has queens have been discussed on the forum as an opportunity for improvement. In these positions, try extending queen moves. (Notably, this dramatically increases the bench.)
18-11-11 31m extend_QImbalance diff
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 8294 W: 1728 L: 1818 D: 4748
sprt @ 10+0.1 th 1 Since I suspect that may be too many extensions, only extend for depth < 2 plies.
18-11-09 31m tweak_castleExtension diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 9183 W: 1850 L: 1977 D: 5356
sprt @ 10+0.1 th 1 To my knowledge, we haven't tried different values for this depth threshold. As a shot in the dark, try cutting it in half to depth < 6 plies.
18-11-09 31m simplify_tropism diff
LLR: -1.16 (-2.94,2.94) [-3.00,1.00]
Total: 141723 W: 30350 L: 30690 D: 80683
sprt @ 10+0.1 th 1 Since this seems to raise the average value of tropism by about 25% in bench, decrease tropism's two coefficients (CloseEnemies and a kingDanger constant) to compensate.
18-11-09 31m simplify_tropism^ diff
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 56941 W: 9172 L: 9108 D: 38661
sprt @ 60+0.6 th 1 LTC. Don't exclude squares we attack with pawns from b2.
18-11-09 31m simplify_tropism^ diff
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 20942 W: 4550 L: 4427 D: 11965
sprt @ 10+0.1 th 1 Do we need to exclude squares we attack with pawns from b2? If the enemy doubly attacks a square near our king, that seems quite dangerous regardless.
18-11-05 31m tune_movepick diff
8398/10000 iterations
17441/20000 games played
20000 @ 20+0.2 th 1 @protonspring's recent tests directed my attention to this value in movepick.cpp, which seems fairly arbitrary but appears to have received no attention in the past year, despite all our recent tuning. Try giving it a quick tuning run. Double the default ck, because I have never had satisfactory results with the default.
18-11-05 31m MinorBlockingRook2 diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 14182 W: 2973 L: 3035 D: 8174
sprt @ 10+0.1 th 1 Simple S(10, 0) penalty if our immobile minor blocks our rook along the back rank.
18-11-04 31m MinorBlockingRook diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 11715 W: 2468 L: 2542 D: 6705
sprt @ 10+0.1 th 1 Only reduce mob if the minor is on the back rank.
18-11-04 31m MinorBlockingRook diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 16464 W: 3513 L: 3564 D: 9387
sprt @ 10+0.1 th 1 Just knights.
18-11-04 31m MinorBlockingRook^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 15725 W: 3377 L: 3431 D: 8917
sprt @ 10+0.1 th 1 Just bishops.
18-11-04 31m MinorBlockingRook^^ diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 5192 W: 1047 L: 1152 D: 2993
sprt @ 10+0.1 th 1 An attempt to indirectly address TrappedRook problems. Track which friendly minors are unable to move (i.e., attack no squares which are not occupied by friendly pieces or attacked by enemy pawns), and exclude them from the rook's mobility area when calculating mobility. Note: the change to Evaluation::value() should guarantee that bishops and knights are evaluated before rooks and queens, so cannotMove[Us] should be populated when pieces() is called for Pt == ROOK.