Stockfish Testing Queue

Pending - 0 tests 0.8 hrs

None

Active - 1 tests

20-10-17 II tune_eval diff
28846/50000 iterations
60514/100000 games played
100000 @ 10+0.1 th 1 Try some tunings based on experience with the simulator - all steps will be explained in the forum.

Finished - 438 tests

14-10-17 II sudden_death diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 312860 W: 57315 L: 58014 D: 197531
sprt @ 16+0 th 1 Try to reduce time losses in sudden death case.
17-10-17 II psqt diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 12039 W: 2145 L: 2261 D: 7633
sprt @ 10+0.1 th 1 Take 2 - without changing piece values.
17-10-17 II psqt diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 237 W: 10 L: 196 D: 31
sprt @ 10+0.1 th 1 Try to tune psqt tables ones more - these are locally tuned values BEFORE doing simulations.
15-10-17 II sudden_death diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 65912 W: 11739 L: 11694 D: 42479
sprt @ 10+0.1 th 1 (standard STC now) Last try: from the previous tests it is obvious that aggressive time usage is unfortunately important for Elo performance, and as this has also slight impact on increment case (should be tested separately), this is my final recommendation for possible reduction of time losses in sudden death case.
15-10-17 II sudden_death diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8636 W: 1646 L: 1504 D: 5486
sprt @ 16+0 th 1 Last try: from the previous tests it is obvious that aggressive time usage is unfortunately important for Elo performance, and as this has also slight impact on increment case (should be tested separately), this is my final recommendation for possible reduction of time losses in sudden death case.
14-10-17 II mtg' diff
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 113963 W: 20008 L: 20042 D: 73913
sprt @ 60/15 th 1 Try to reduce possibility of time losses, take 2 - cleaner solution.
14-10-17 II sudden_death diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 8672 W: 1496 L: 1668 D: 5508
sprt @ 16+0 th 1 Take 2: only 5% of time after move 60 (lowered priority of the first test)
14-10-17 II mtg' diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 39446 W: 8097 L: 8334 D: 23015
sprt @ 1/0.25 th 1 Let's also see how my solution works in another extreme case.
14-10-17 II mtg' diff
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32371 W: 5728 L: 5626 D: 21017
sprt @ 60/15 th 1 Test 60/x time control after report of time losses.
07-10-17 II queen diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 3547 W: 540 L: 683 D: 2324
sprt @ 10+0.1 th 1 Try to keep queens on the board as long as possible.
03-10-17 II imbalance diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 33429 W: 5930 L: 5973 D: 21526
sprt @ 10+0.1 th 1 Imbalance tables - tuned values.
30-09-17 II imbalance_tune diff
47949/50000 iterations
100000/100000 games played
100000 @ 10+0.1 th 1 Last try to tune.
30-09-17 II time2 diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 43894 W: 7650 L: 7660 D: 28584
sprt @ 10+0.1 th 1 Test only one part of recent tuning.
29-09-17 II imbalance diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 85271 W: 15208 L: 15077 D: 54986
sprt @ 10+0.1 th 1 I messed up with the tuning, let's see do I have something useful, take 3.
20-09-17 II mtg diff
LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 126228 W: 23060 L: 23436 D: 79732
sprt @ 40/10 th 1 I noticed one detail which is important to avoid time losses in x/y time controls, and which could be Elo neutral. Test as bug fix with throughput 300.
28-09-17 II imbalance_tune diff
36814/50000 iterations
78339/100000 games played
100000 @ 10+0.1 th 1 Tune imbalance tables, starting from an alternative starting point which was neutral in SPRT test (corrected SPSA bounds).
22-09-17 II herTime diff
LLR: -3.11 (-2.94,2.94) [0.00,5.00]
Total: 46839 W: 5983 L: 5957 D: 34899
sprt @ 60+0.6 th 1 I got a slope of 0.0017 with VO's tool. Low throughput.
28-09-17 II imbalance_tune diff
2690/50000 iterations
5829/100000 games played
100000 @ 10+0.1 th 1 Tune imbalance tables, starting from an alternative starting point which was neutral in SPRT test.
27-09-17 II imbalance diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 46311 W: 8282 L: 8282 D: 29747
sprt @ 10+0.1 th 1 As imbalance tables are certainly hard to tune, I'll take few tries by guess and luck - take 2 - priority -1 so far.
27-09-17 II imbalance diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 26853 W: 4826 L: 4891 D: 17136
sprt @ 10+0.1 th 1 As imbalance tables are certainly hard to tune, I'll take few tries by guess and luck - take 1.
20-09-17 II herTime diff
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 64900 W: 11716 L: 11566 D: 41618
sprt @ 10+0.1 th 1 One more try on using time of our opponent.
19-09-17 II time2 diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 15598 W: 2811 L: 2914 D: 9873
sprt @ 10+0.1 th 1 Take 2: 85% of available time.
19-09-17 II time2 diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 6542 W: 1144 L: 1279 D: 4119
sprt @ 10+0.1 th 1 Instead of incresing Move Overhead, never use more than 50% of available time.
16-09-17 II assorted' diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 17363 W: 3045 L: 3143 D: 11175
sprt @ 10+0.1 th 1 Tuned values.
12-09-17 II tune_assorted diff
38663/40000 iterations
79294/80000 games played
80000 @ 10+0.1 th 1 Tune assorted values.
11-09-17 II MO_normal diff
ELO: -0.21 +-2.3 (95%) LOS: 42.7%
Total: 41000 W: 9301 L: 9326 D: 22373
50000 @ 3+0.03 th 1 And Step 2: measure time losses in increment case with somewhat slower time control (in quick games Move Overhead is very high now).
11-09-17 II MO_normal diff
ELO: 1.96 +-3.2 (95%) LOS: 88.8%
Total: 29000 W: 9199 L: 9035 D: 10766
50000 @ 1+0 th 1 Check whether this variant is as stable as in local test: Step 1 - measure time losses in quick sudden death games.
02-09-17 II time diff
LLR: -4.22 (-2.94,2.94) [0.00,4.00]
Total: 236953 W: 43238 L: 42652 D: 151063
sprt @ 10+0.1 th 1 Tuned values - take 1.
10-09-17 II MO_normal diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 32029 W: 6639 L: 6538 D: 18852
sprt @ 4+0.1 th 1 Try more secure usage of Move Overhead, which is in the spirit of the old TM code.
10-09-17 II MO' diff
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 35262 W: 7426 L: 7331 D: 20505
sprt @ 4+0.1 th 1 Regression test for PR #1248
04-09-17 II qmi diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 41008 W: 7509 L: 7525 D: 25974
sprt @ 10+0.1 th 1 As the tuning was almost neutral try to change one value.
04-09-17 II qmi diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 59678 W: 11071 L: 10939 D: 37668
sprt @ 10+0.1 th 1 And take 2 - add an opposite condition.
02-09-17 II tune_qmi diff
34869/40000 iterations
70567/80000 games played
80000 @ 10+0.1 th 1 Retune QueenMinorsImbalance with different condition. Low throughput so far.
29-08-17 II tune_tmm diff
47716/50000 iterations
96622/100000 games played
100000 @ 10+0.1 th 1 It seems nothing is better to avoid time losses than simply increasing Move Overhead. So, try to continue tuning with larger Move Overhead.
29-08-17 II time-loss diff
ELO: -2.75 +-5.2 (95%) LOS: 14.9%
Total: 9853 W: 2775 L: 2853 D: 4225
30000 @ 1.6+0 th 1 Check this variant in sudden death case.
29-08-17 II master diff
ELO: -3.51 +-5.1 (95%) LOS: 8.9%
Total: 10000 W: 2773 L: 2874 D: 4353
10000 @ 1.6+0 th 1 Sudden death TC is the most sensitive to time losses. Let's check master at 1.6+0.
29-08-17 II time-loss diff
ELO: 2.06 +-6.6 (95%) LOS: 73.0%
Total: 6248 W: 1849 L: 1812 D: 2587
30000 @ 1.6+0 th 1 Smaller check on time losses at sudden death TC.
28-08-17 II time-loss diff
ELO: 0.89 +-1.5 (95%) LOS: 87.4%
Total: 110000 W: 30489 L: 30207 D: 49304
100000 @ 1+0.01 th 1 Measure changes in time management on time losses at VSTC (take 1).
25-08-17 II MO2 diff
LLR: -1.00 (-2.94,2.94) [-3.00,1.00]
Total: 38000 W: 6824 L: 6942 D: 24234
sprt @ 10+0.1 th 1 First try to reduce the number of crashes and time losses. This is a bug fix because an engine now tries to play even if somehow an amount of available time falls below Move Overhead value, and the remaining function now always returns a positive value, except in the case of myTime <= 0.
24-08-17 II herTime diff
LLR: -3.01 (-2.94,2.94) [0.00,5.00]
Total: 11345 W: 1482 L: 1565 D: 8298
sprt @ 60+0.6 th 1 LTC: Take 4.
24-08-17 II herTime diff
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 10703 W: 2020 L: 1849 D: 6834
sprt @ 10+0.1 th 1 Take 4.
22-08-17 II MO diff
ELO: -2.98 +-2.1 (95%) LOS: 0.2%
Total: 39650 W: 7034 L: 7374 D: 25242
40000 @ 10+0.1 th 1 I've a feeling that current TM accepts higher Move Overhead values without an ELO loss (except at VSTC). I don't know how to test this: it is not a simplification, it is not a bug fix, and it is probably not an Elo gain, but it could help with machines like SapphireBrand-3cores (see Stephane's post in the forum). So, I start 40K games with throughput 200.
21-08-17 II time diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 81268 W: 14960 L: 14837 D: 51471
sprt @ 10+0.1 th 1 Try tuned values (non-moves-to go case).
22-08-17 II herTime diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 19047 W: 3474 L: 3518 D: 12055
sprt @ 10+0.1 th 1 Take 3 (less aggressive change).
22-08-17 II herTime diff
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 10229 W: 1830 L: 1912 D: 6487
sprt @ 10+0.1 th 1 Take 2.
22-08-17 II herTime diff
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 5863 W: 1029 L: 1130 D: 3704
sprt @ 10+0.1 th 1 Using time management of our opponent.
21-08-17 II time2 diff
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 22720 W: 4317 L: 4395 D: 14008
sprt @ 40/10 th 1 Try tuned values (moves-to-go case).
19-08-17 II tune_tmm2 diff
59005/60000 iterations
120000/120000 games played
120000 @ 40/10 th 1 Tune moves-to-go case of time management. Tune with variant of Lucas' patch.
18-08-17 II tune_tmm diff
58736/60000 iterations
120000/120000 games played
120000 @ 10+0.1 th 1 Tune non-moves-to-go case of time management (one ck value was incorrect)
18-08-17 II MO diff
LLR: -2.95 (-2.94,2.94) [0.00,4.00]
Total: 18337 W: 3275 L: 3369 D: 11693
sprt @ 10+0.1 th 1 Check the influence of Move Overhead on Elo strength.