Stockfish Testing Queue

Pending - 0 tests 0.0 hrs

None

Active - 0 tests

Finished - 1086 tests

19-02-22 31m lmr_promotion diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 29839 W: 6550 L: 6567 D: 16722
sprt @ 10+0.1 th 1 Merge the two best-performing versions of the same idea: more extension and less reduction for any promotion.
19-02-20 31m extend_castlefawn diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 25897 W: 5723 L: 5759 D: 14415
sprt @ 10+0.1 th 1 Even more castling extension if castling directly into a fawn pawn. (Note for approver: castling moves are encoded as "king takes rook", so the to_sq for kingside castling is actually "on" the H file (and queenside, A file). Please let me know if someone has a less ugly way of coding this.)
19-02-20 31m lmr_promotion diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 14479 W: 3180 L: 3273 D: 8026
sprt @ 10+0.1 th 1 Less LMR for all promotions was promising, but just for queens was terrible. Try less LMR for underpromotion.
19-02-20 31m lmr_promotion^ diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 60223 W: 13305 L: 13172 D: 33746
sprt @ 10+0.1 th 1 Based on @mstembera/@vondele ideas for extensions, but applied to LMR. Less reduction for promotions.
19-02-20 31m lmr_promotion diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 18835 W: 4113 L: 4184 D: 10538
sprt @ 10+0.1 th 1 Less reduction for promotions (queen promotion only).
19-02-20 31m outpost_futurePasser diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 13339 W: 2909 L: 3008 D: 7422
sprt @ 10+0.1 th 1 Removing eg component. S(10, 0).
19-02-20 31m outpost_futurePasser diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 14382 W: 3107 L: 3200 D: 8075
sprt @ 10+0.1 th 1 Simple S(10, 10) bonus.
19-02-18 31m outpost_futurePasser diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 17424 W: 3787 L: 3865 D: 9772
sprt @ 10+0.1 th 1 Initial attempt based on Bryan's analysis of TCEC 14 Superfinal Game 49. More Outpost bonus for an occupied, pawn-defended rank-6 outpost whose exchange creates a rank-6 passer. Require that the opponent have a minor to exchange for this outpost.
19-02-17 31m TrappedRook_fawn diff
LLR: -2.94 (-2.94,2.94) [0.50,4.50]
Total: 13557 W: 2922 L: 3019 D: 7616
sprt @ 10+0.1 th 1 Bugfix: require that the enemy-pawn-attacked squares on our second rank not be occupied by our pieces.
19-02-17 31m KingMoves diff
LLR: -2.96 (-2.94,2.94) [0.00,3.50]
Total: 19744 W: 3169 L: 3290 D: 13285
sprt @ 60+0.6 th 1 There's no reason to leave the framework empty for hours with a promising test waiting...speculative LTC for @MJZ1977's 170K STC yellow.
19-02-17 31m TrappedRook_fawn diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 10526 W: 2236 L: 2348 D: 5942
sprt @ 10+0.1 th 1 Half effect.
19-02-17 31m TrappedRook_fawn diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 21356 W: 4651 L: 4710 D: 11995
sprt @ 10+0.1 th 1 Double trapped rook if the enemy has a fawn pawn in the area. Inspired by TCEC Superfinal Game 63, Lc0 1-0 SF.
19-02-16 31m lmr_attack diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 13303 W: 2887 L: 2986 D: 7430
sprt @ 10+0.1 th 1 This is by far the largest change I have attempted in search, where I lack experience; please correct me if I have made errors. It has long been suggested to do less reduction for the attacking side if the weak side has high king danger, but king danger is too expensive to calculate in search. Maybe lazy eval isn't! If we have lots of non-pawn material, and an eval well beyond what can be explained by lazy evaluation, we almost certainly have some sort of attack or dynamic advantage. Apply less reduction in this case.
19-02-16 31m lmr_attack diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 9691 W: 2065 L: 2182 D: 5444
sprt @ 10+0.1 th 1 Even more lazy (and hopefully more efficient): do not probe Pawns or evaluate them.
19-02-15 31m combo_TOP_outpost diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 24335 W: 5250 L: 5319 D: 13766
sprt @ 10+0.1 th 1 Combo some old promising tweaks of mine, since the framework is nearly empty. (I have no idea whether they will still perform well...)
19-02-14 31m passed_protection diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 9228 W: 1984 L: 2103 D: 5141
sprt @ 10+0.1 th 1 Check whether this substantially narrower case (candidate passers only) can therefore tolerate larger effect. Double effect (divisor 16 -> 8).
19-02-14 31m passed_protection diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 41791 W: 9259 L: 9217 D: 23315
sprt @ 10+0.1 th 1 Opposite effect: candidate passers only.
19-02-14 31m threat_strongqueen3 diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 26079 W: 5770 L: 5805 D: 14504
sprt @ 10+0.1 th 1 In November, this was a 70K STC and 108K LTC yellow--back when we used [0, 5] bounds for both. Respin with new bounds. Master already has ThreatByRook[QUEEN] but applies this only to "weak" queens, but queens are always weak to threats by lesser pieces. Give ThreatByRook[QUEEN] / 2 bonus for a rook attack against a "strong" queen.
19-02-14 31m passed_protection diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 10366 W: 2217 L: 2330 D: 5819
sprt @ 10+0.1 th 1 My take on MJZ's idea. Don't apply this increased bonus for candidate passers, only for "real" ones.
19-02-13 31m passerUnsafe_ABP diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 14015 W: 3015 L: 3110 D: 7890
sprt @ 10+0.1 th 1 More complex take. Only consider squares defended by our non-passed pawns. If a square is defended by a passed pawn, we might trade two passers for one--which probably isn't a good idea. (Sometimes this is a useful tactic for promotion, but search should take care of that.)
19-02-13 31m passerUnsafe_ABP diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 33325 W: 7339 L: 7339 D: 18647
sprt @ 10+0.1 th 1 A really intuitive idea: a square in front of a passer is not unsafe if we attack it with a pawn. (I suspect this may have been tried before, but I'm curious and the framework is mostly empty.)
19-02-13 31m lmr_pawnPushVsK2 diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 34373 W: 7565 L: 7560 D: 19248
sprt @ 10+0.1 th 1 An insight to try to turn this 165K yellow green: we should only apply this if the opponent cannot castle. If they can, pressuring the king is likely of little use.
19-02-13 31m lmr_pawnPushVsK2 diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 10942 W: 2340 L: 2450 D: 6152
sprt @ 10+0.1 th 1 Only if we have a friendly rook on the file to support the push.
19-02-12 31m MBP_neighbors diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 8537 W: 1825 L: 1947 D: 4765
sprt @ 10+0.1 th 1 Require that there be friendly pawns on neighboring files before giving MinorBehindPawn bonus with friendly pawns.
19-02-10 31m lmr_pawnPushVsK~9 diff
LLR: -2.96 (-2.94,2.94) [0.00,3.50]
Total: 30554 W: 4985 L: 5076 D: 20493
sprt @ 60+0.6 th 1 Speculative LTC for 165K yellow.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 62411 W: 13782 L: 13638 D: 34991
sprt @ 10+0.1 th 1 Comparatively small change to 165K yellow: NPM > RNB rather than RNN.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 25288 W: 5569 L: 5608 D: 14111
sprt @ 10+0.1 th 1 Code reorder of 165K yellow: apply to pawn captures too, not only pawn pushes.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 14736 W: 3184 L: 3276 D: 8276
sprt @ 10+0.1 th 1 Stricter NPM: NPM > QR.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 14373 W: 3087 L: 3181 D: 8105
sprt @ 10+0.1 th 1 Less strict NPM condition: NPM > RN.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 11295 W: 2406 L: 2515 D: 6374
sprt @ 10+0.1 th 1 165K yellow is very close...before speculative LTC, try a few more variations. @ElbertoOne's suggestion: 2 plies.
19-02-09 31m extend_passercreation diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 6156 W: 1267 L: 1401 D: 3488
sprt @ 10+0.1 th 1 Extend captures (except pawn moves) that create passed pawns.
19-02-09 31m extend_passercreation^ diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 3491 W: 704 L: 852 D: 1935
sprt @ 10+0.1 th 1 Extend captures that create passed pawns.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 165291 W: 36466 L: 35817 D: 93008
sprt @ 10+0.1 th 1 @vondele recommended trying a NPM condition. NPM > R + 2N.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 59580 W: 13099 L: 12970 D: 33511
sprt @ 10+0.1 th 1 Initial (very preliminary) results are promising--but I have many more ideas to test. No explicit NPM condition, but require that the pawn be in front of the king. The enemy king is more likely to be near relative rank 8 in the middlegame, making this tacitly a game-phase condition; however, it also corrects for the fact that I'm not sure I want to affect pawn pushes behind the enemy king in the endgame. Include the king's neighboring files in this version.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 44440 W: 9675 L: 9621 D: 25144
sprt @ 10+0.1 th 1 Just on the enemy king files, not the neighboring ones.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 38664 W: 8517 L: 8491 D: 21656
sprt @ 10+0.1 th 1 Less reduction for pawn pushes near the enemy king.
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 18969 W: 4078 L: 4149 D: 10742
sprt @ 10+0.1 th 1 Relative rank restriction, this time only on the enemy king file. (If the event that any of these STCs pass, I'll likely be asleep and would be grateful to anyone who starts the LTC.)
19-02-09 31m lmr_pawnPushVsK diff
LLR: -2.94 (-2.94,2.94) [0.50,4.50]
Total: 14369 W: 3109 L: 3202 D: 8058
sprt @ 10+0.1 th 1 King file only and NPM restriction.
19-02-08 31m comment_semiopenFiles diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 51765 W: 11359 L: 11627 D: 28779
sprt @ 10+0.1 th 1 Surprised by recent failure. Try two small fixes: (a) change the type of semiopen_file() to match, removing an unnecessary conversion; (b) reorder the fields in the struct. Since they are stored in order of declaration, it's possible that having a Bitboard (64 bits) after the ints (32 bits) was causing some sort of sub-optimal memory layout, though I'm not sure...
19-02-08 31m comment_semiopenFiles diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 57789 W: 12481 L: 12759 D: 32549
sprt @ 10+0.1 th 1 There has been a lot of confusion about semiopenFiles. It is an "int" to save space only but is actually a Bitboard in effect; combined with a lack of documentation, it has tripped up numerous users in the past year (including me). Check that there's no regression in making it a true Bitboard as it arguably should be, and add a detailed comment.
19-02-08 31m SiberianOutpost3 diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 13952 W: 3032 L: 3128 D: 7792
sprt @ 10+0.1 th 1 Rank 6 only.
19-02-08 31m SiberianOutpost3 diff
LLR: -2.94 (-2.94,2.94) [0.50,4.50]
Total: 13957 W: 3038 L: 3133 D: 7786
sprt @ 10+0.1 th 1 Don't double an occupied Outpost if it is more than three squares from the nearest non-pawn enemy.
19-02-08 31m BishopBackward diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 18314 W: 4090 L: 4164 D: 10060
sprt @ 10+0.1 th 1 Also require ~attackedBy2[Them].
19-02-08 31m BishopBackward diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 14462 W: 3100 L: 3193 D: 8169
sprt @ 10+0.1 th 1 @Alayan-stk-2's idea: require pos.non_pawn_material(Us) > BishopValueMg.
19-02-08 31m BishopBackward diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 44282 W: 9731 L: 9677 D: 24874
sprt @ 10+0.1 th 1 S(35, 35)
19-02-08 31m SliderNoBlocker diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 33138 W: 7221 L: 7222 D: 18695
sprt @ 10+0.1 th 1 Exclude our king blockers.
19-02-08 31m SliderNoPawn diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 29400 W: 6510 L: 6529 D: 16361
sprt @ 10+0.1 th 1 Logical follow-up to @Vizvezdenec's 83K yellow, SliderNoPawn1. Exclude pawns that are stopped by enemy double pawn attacks.
19-02-08 31m BishopBackward diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 56116 W: 12250 L: 12139 D: 31727
sprt @ 10+0.1 th 1 S(15, 15) for enemy pawns that are (i) bishop-attacked, (ii) bishop-defended, (iii) not pawn-defended, and (iv) blocked by us.
19-02-08 31m BishopBackward diff
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 33383 W: 7318 L: 7318 D: 18747
sprt @ 10+0.1 th 1 S(25, 25)
19-02-08 31m BishopBackward diff
LLR: -2.95 (-2.94,2.94) [0.50,4.50]
Total: 16445 W: 3544 L: 3627 D: 9274
sprt @ 10+0.1 th 1 Also inspired by TCEC 14 Superfinal Game 11. In the position below, one of the most striking features is the relative activity of the light-squared bishops. Give a bonus for bishop attacks on bishop-defended backward pawns. This combines the most striking features of Overload (relative immobility of the defending bishop, susceptibility to built-up attacks) with two insights specific to this case: (a) because the pawn is backward in the chain, the defender is probably defending from behind and the attacker in front--making this a proxy for "good"/"bad" bishops; (b) because the pawn is backward, it has much lower mobility and is much weaker than was typical for Overload. S(15, 15). 2b1q2r/k3r1b1/4pRP1/1p1pP2p/p1pP1N1B/PnP4B/1P3QRK/8 b - - 4 45