Stockfish Testing Queue

Finished - 1741 tests

15-01-07 SC manual_pawns diff
LLR: -2.95 (-2.94,2.94) [-1.50,4.50]
Total: 1416 W: 246 L: 350 D: 820
sprt @ 15+0.05 th 1 Only reward advanced pawns in pawn endgames with many pawns. Local speed-up ca. 2%.
15-01-08 SC ks_tempo diff
LLR: -2.96 (-2.94,2.94) [-1.50,4.50]
Total: 34973 W: 6923 L: 6934 D: 21116
sprt @ 15+0.05 th 1 Value tempo more if KS is low (and a tiny little bit less if not)
15-01-09 SC ks_tempo_tuning diff
54772/50000 iterations
100000/100000 games played
100000 @ 15+0.05 th 1 Almost passed STC with more or less random pars, see how far we can go after tuning. Schedule 100k games, I will stop if it converges early.
15-01-10 SC ks_tempo diff
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 84573 W: 17028 L: 16688 D: 50857
sprt @ 15+0.05 th 1 Using tuned values from spsa session
15-01-10 SC same_tempo diff
LLR: 3.27 (-2.94,2.94) [-1.50,4.50]
Total: 10497 W: 2163 L: 2016 D: 6318
sprt @ 15+0.05 th 1 Parameter from ks_tempo_tuning converged to (in average) exactly 2*Eval::tempo, suggesting that the factor 2 in search should actually be 1. Test whether doubling Eval::tempo and removing factor 2 from search.cpp does help. Mantainers should feel free to reschedule this as (-3, 1)
15-01-10 SC same_tempo diff
LLR: -2.96 (-2.94,2.94) [0.00,6.00]
Total: 6909 W: 1066 L: 1136 D: 4707
sprt @ 60+0.05 th 1 Parameter from ks_tempo_tuning converged to (in average) exactly 2*Eval::tempo, suggesting that the factor 2 in search should actually be 1. Test whether doubling Eval::tempo and removing factor 2 from search.cpp does help. Mantainers should feel free to reschedule this as (-3, 1)
15-01-16 SC tempo_endgames diff
LLR: -2.96 (-2.94,2.94) [-1.50,4.50]
Total: 6422 W: 1219 L: 1308 D: 3895
sprt @ 15+0.05 th 1 Disable post null-move trick in the search when 3 or less pieces are on the board, since tempo is accounted for in specialized endgames evaluation. This could make some difference for detecting stalemates or zugzwang in KXK endgames.
15-01-17 SC tempo_endgames diff
LLR: -2.95 (-2.94,2.94) [-1.50,4.50]
Total: 45948 W: 9174 L: 9154 D: 27620
sprt @ 15+0.05 th 1 Disable post null-move trick in the search when 3 or less pieces are on the board, since tempo is accounted for in specialized endgames evaluation. This could make some difference for detecting stalemates or zugzwang in KXK endgames. Now with the correct inequality. It did not change the bench because no KXK positions are reached in bench.
15-01-17 SC tempo_endgames diff
LLR: -4.03 (-2.94,2.94) [-1.50,4.50]
Total: 22623 W: 3665 L: 3751 D: 15207
sprt @ 60+0.05 th 1 Disable post null-move trick in the search when 3 or less pieces are on the board, since tempo is accounted for in specialized endgames evaluation. This could make some difference for detecting stalemates or zugzwang in KXK endgames. LTC after a almost passed STC.
15-01-27 SC no_null_trick diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 14324 W: 2769 L: 2956 D: 8599
sprt @ 15+0.05 th 1 Testing removal of post-null move evaluation trick as a simplification.
15-01-31 SC no_tempo diff
ELO: -8.65 +-2.1 (95%) LOS: 0.0%
Total: 42000 W: 8017 L: 9062 D: 24921
40000 @ 15+0.05 th 1 Measure how much elo is tempo evaluation worth.
15-02-01 SC search_tempo diff
ELO: -0.14 +-4.4 (95%) LOS: 47.6%
Total: 10000 W: 2128 L: 2132 D: 5740
10000 @ 9+0.03 th 1 Do not add tempo during evaluation and move it completely to search. Now tempo is being added for specialized endgames. It should not change anything (apart of specialized endgames).
15-02-04 SC tuned_tempo diff
LLR: -2.97 (-2.94,2.94) [-1.50,4.50]
Total: 9188 W: 1771 L: 1853 D: 5564
sprt @ 15+0.05 th 1 Increase tempo value in middlegame and decrease in endgame.
15-02-04 SC tuned_tempo diff
LLR: -2.96 (-2.94,2.94) [-1.50,4.50]
Total: 10206 W: 1974 L: 2053 D: 6179
sprt @ 15+0.05 th 1 Decrease tempo value for middlegame and increase for endgame.
15-02-05 SC tuned_tempo diff
LLR: -2.96 (-2.94,2.94) [-1.50,4.50]
Total: 8077 W: 1601 L: 1686 D: 4790
sprt @ 15+0.05 th 1 Bugfix for tempo evaluation. More tempo value in endgames.
15-02-05 SC tuned_tempo diff
LLR: -2.95 (-2.94,2.94) [-1.50,4.50]
Total: 12197 W: 2416 L: 2489 D: 7292
sprt @ 15+0.05 th 1 More tempo value in middlegames, bugfix
15-02-07 SC search_tempo_game_phase diff
LLR: -2.97 (-2.94,2.94) [-1.50,4.50]
Total: 19773 W: 3911 L: 3964 D: 11898
sprt @ 15+0.05 th 1 Game phase based tempo value (faster version), take 1. More tempo value for endgames.
15-02-07 SC search_tempo_game_phase diff
LLR: -2.97 (-2.94,2.94) [-1.50,4.50]
Total: 17531 W: 3508 L: 3567 D: 10456
sprt @ 15+0.05 th 1 Game phase based tempo value (faster version), take 2. More tempo value for middlegame.
15-02-07 SC search_tempo_king_dista diff
LLR: -2.96 (-2.94,2.94) [-1.50,4.50]
Total: 23776 W: 4839 L: 4880 D: 14057
sprt @ 15+0.05 th 1 King distance based tempo value. More tempo if kings are distant.
15-02-08 SC search_tempo_king_dista diff
28685/30000 iterations
60000/60000 games played
60000 @ 15+0.05 th 1 Tune king distance based tempo.
15-02-08 SC search_tempo_game_phase diff
19566/20000 iterations
40000/40000 games played
40000 @ 15+0.05 th 1 Tune game phase based tempo evaluation.
15-02-09 SC search_tempo_game_phase diff
LLR: -2.95 (-2.94,2.94) [-1.50,4.50]
Total: 22535 W: 4558 L: 4602 D: 13375
sprt @ 15+0.05 th 1 Tuned value for gampe phase based tempo evaluation.
15-02-09 SC search_tempo_king_dista diff
LLR: -2.95 (-2.94,2.94) [-1.50,4.50]
Total: 6997 W: 1313 L: 1400 D: 4284
sprt @ 15+0.05 th 1 Tuned values for king distance based tempo.
15-02-09 SC tune_tempo diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 52492 W: 10509 L: 10476 D: 31507
sprt @ 15+0.05 th 1 In all the tempo tuning SPSA, tempo was increased in average. Is tempo +1 enough?
15-02-09 SC tune_tempo diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 55084 W: 10923 L: 10882 D: 33279
sprt @ 15+0.05 th 1 And tempo +2?
15-02-10 SC search_tempo_game_phase diff
LLR: -2.97 (-2.94,2.94) [-1.50,4.50]
Total: 9934 W: 1968 L: 2048 D: 5918
sprt @ 15+0.05 th 1 Game-phase based tempo evaluation. Probe material table instead of computing game phase every time. Same bench and speed-up 0.50% wrt the version which failed STC.
15-02-11 SC search_tempo_game_phase diff
LLR: -2.97 (-2.94,2.94) [-1.50,4.50]
Total: 7308 W: 1387 L: 1474 D: 4447
sprt @ 15+0.05 th 1 A further try on tempo evaluation. Restore feature of ignoring tempo for specialized evaluations. (I removed it to avoid increasing the code too muchl).
15-02-12 SC tune_tempo diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 38725 W: 6532 L: 6561 D: 25632
sprt @ 60+0.05 th 1 Both tempo += 1 and tempo += 2 were "yellow" at STC. Test tempo += 2 at LTC and then call it a day.
15-02-19 SC ortho_threats diff
ELO: -23.35 +-4.5 (95%) LOS: 0.0%
Total: 10000 W: 1822 L: 2493 D: 5685
10000 @ 15+0.05 th 1 Orthogonality experiment, take 1. Replace threats evaluation by linear combination of king, passed_pawns and mobility. Coefficients obtained from bench. A quick check to see how much Elo is lost.
15-03-09 SC oppbis_eval diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 1710 W: 246 L: 407 D: 1057
sprt @ 15+0.05 th 1 Simplify scaling with opposite-colored bishops.
15-03-09 SC oppbis_eval diff
LLR: -2.95 (-2.94,2.94) [-3.00,1.00]
Total: 2332 W: 423 L: 591 D: 1318
sprt @ 15+0.05 th 1 Simplify scaling with opposite-colored bishops, bugfix. I somehow got the values completely wrong in the previous test.
15-04-14 SC pieceValuesMP diff
LLR: -2.97 (-2.94,2.94) [-1.50,4.50]
Total: 15466 W: 2898 L: 2963 D: 9605
sprt @ 15+0.05 th 1 Test whether speed-up when using tables instead of formulas in capture ordering is enough to pass STC.
15-04-16 SC pieceValuesMP_tune diff
27147/30000 iterations
58000/60000 games played
60000 @ 30+0.05 th 1 Tune capture score table. Rescheduling after fixing the nodestime in base. Again a bugfix, hope I got everything right this time.
15-04-17 SC pieceValuesMP_tuned diff
LLR: -2.96 (-2.94,2.94) [-1.50,4.50]
Total: 15738 W: 2970 L: 3034 D: 9734
sprt @ 15+0.05 th 1 Use values from SPSA tuning for ordering of captures in MovePicker.
15-04-17 SC pieceValuesMP_subtree diff
LLR: -2.96 (-2.94,2.94) [-1.50,4.50]
Total: 4984 W: 927 L: 1020 D: 3037
sprt @ 15+0.05 th 1 Last try on capture ordering: try to capture first with heavy pieces in order to reduce subtree size.
15-04-18 SC bestMoveChanges diff
ELO: -5.05 +-4.3 (95%) LOS: 1.1%
Total: 8387 W: 1377 L: 1499 D: 5511
20000 @ 60+0.2 th 1 Scales BestMoveChanges with the log2 of the moveCount to see if it makes any difference. Testing with 30+0.01 to be a multiple of TCEC time control and with nodestime since change is only in time management.
15-04-18 SC pieceValuesMP_simple diff
LLR: 3.71 (-2.94,2.94) [-3.00,1.00]
Total: 64363 W: 12299 L: 12214 D: 39850
sprt @ 15+0.05 th 1 Would pure MMV logic be enough?
15-04-19 SC pieceValuesMP_simple2 diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 36177 W: 6968 L: 6874 D: 22335
sprt @ 15+0.05 th 1 As Joona pointed out: MVV/LVA also aims to define exactly the ordering in which captures are searched, which is left open by MVV only. Try a more compact implementation of MVV/LVA.
15-04-19 SC bestMoveChanges diff
ELO: 1.18 +-2.8 (95%) LOS: 79.6%
Total: 20000 W: 3404 L: 3336 D: 13260
20000 @ 60+0.2 th 1 Since time consumption in instable moves is increased by the new scaling, decrease overall optimum time by 20%. If it improves with respect to previous verison, I will tune it.
15-04-20 SC pieceValuesMP_simple diff
LLR: -2.97 (-2.94,2.94) [-1.50,4.50]
Total: 1340 W: 202 L: 304 D: 834
sprt @ 15+0.05 th 1 For completeness: is pure LVA logic good enough?
15-04-21 SC pieceValuesMP_simple diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 69976 W: 11056 L: 11011 D: 47909
sprt @ 60+0.05 th 1 Would pure MMV logic be enough? LTC