Max Siegfried schrieb:
1.MultiPV ist MultiPV das kennt doch jeder.
2.Full Depth Threads bedeutet einfach ausgedrückt: Es wird nichts abgeschnitten (kein Pruning).
Wenn jeder MultiPV kennt, sollte auch jeder wissen, dass dabei bei den zu primary variants erhobenen auch weniger abgeschnitten wird, als bei non primaries. Nun kommt's dann einfach drauf an, bei welcher Stellung welche Varianten wieviel Pruning erfahren, wenn sie non primaries sind, und bei wievielen zu primaries erhobenen wieviel weniger abgeschnitten wird, und ob die entsprechende eine Variante mit dem best move schon bei denen dabei ist, die du für MultiPV vorgibst. Dein eines Beispiel sagt nur, dass bei den gerade mal 50 Stellungen in den gerade mal 2 runs mit den 2 Settings, die du vergleichst, einmal 4 Lösungen mehr vorgekommen sind, noch dazu überschneiden sich die gelösten nicht ganz, auf die Schnelle sehe ich z.B. im FDT- run die nr. 41 nicht unter den gelösten. Was du bräuchtest, dass du auf solche oder ähnliche Art halbwegs statistisch relevante Ergebnisse hättest, wären viel mehr Stellungen, die du viel öfter laufen ließest, möglichst im Vergleich mit viel mehr Engines oder Settings, dann bekämst du ein Bild von der schachlich- statistischen Relevanz (so sind die 8% einfach 8% ohne jeden Bezug zu einer Performance, die andere Stellungen und andere Engines im Vergleich dazu ergäben, du hast keinen Bezug zu irgendeiner Art von Schwankungsbreite, weil du eine solche einfach nicht kennst. Wenn von 50 Stellungen jeweils fast die Hälfte nicht gelöst wird, ist das bei diesen 2 runs der in Summe ziemlich ebenso große Pool wie der der gelösten, in welcher Zeit wären von diesen im Finstern liegenden annähnernd 50% die Ergebnisse bei mehr Hardware- Zeit gewesen? Welche anderen Engines hätten wieviele und welche dieser Stellungen bei einer bestimmten Hardware- TC gelöst und welche anderen Stellungen dafür nicht?
Ein Minimum an statistischer Relevanz schaut z.B. so aus:
325 Stellungen, (übrigens hat diese Andrea Manzo auch auf seinen sites veröffentlicht und verwendet sie zu seinen Testzwecken und zeigt Resultate mit ihnen) von denen allein bei mir in bisher 64 gespeicherten runs zwischen 120 und 308 Lösungen pro run erreicht worden sind bei einer gemeinsamen Hardware- TC von 6 threads und 30"/Stellung. Mit allen diesen runs wird jeder neue Stellung für Stellung und Engine für Engine bzw. Setting für Setting neu verglichen, in Hinblick auf die Zahl der Lösungen und für jeden einzelnen run jede einzelne Stellung in Hinblick auf die genauen Lösungszeiten im direkten WDL- Vergleich, nur die zwischen 2 runs gleichermaßen nicht gelösten und die genau gleich schnell gelösten werden als "Remis" gerechnet, das bringt Distinktion zwischen den runs und senkt die schachlich relveante error bar um jeden neuen run und alle neuen direkten WDL- Vergleiche.
Da sieht's dann bei der 41.1- Version so aus:
Program Elo +/- Matches Score Av.Op. S.Pos. MST1 MST2 RIndex
15 ShashChess41.1GD-6t-MCTS1-MuPV4 : 3533 2 17307 54.9 % 3499 252/325 4.8s 10.5s 0.66
27 Stockfish-260307-6t-MuPV4 : 3519 2 16767 52.8 % 3499 234/325 4.3s 11.5s 0.62
40 ShashChess41.1GD-6t-FDT2-MuPV1 : 3495 2 16336 49.2 % 3501 212/325 4.6s 13.4s 0.57
41 ShashChess41.1GD-6t-MCTS1-MuPV1 : 3495 2 16423 49.2 % 3501 218/325 5.2s 13.4s 0.54
44 Stockfish-260307-6t-MuPV1 : 3492 2 16321 48.7 % 3501 211/325 5.1s 13.8s 0.55
MST1 : Mean solution time (solved positions only)
MST2 : Mean solution time (solved and unsolved positions)
RIndex: Score according to solution time ranking for each positionFTD2 heißt 2 Full depth threads, GD steht für Gold Digger, MultiPV und MCTS sind selbst erklärend. Im FTD2- run hab' ich MCTS dafür weggelassen, weil sonst nur 3 von 6 für A-B- übrig geblieben wären, das scheint mir im Vergleich zu 6 zu viel Unterschied. Aber will man jetzt genauer wissen, wie sich die Kombi von MCTS und FDT bei welcher Gesamtzahl an threads und welcher Hardware- TC auswirkt, muss man's extra laufen lassen, Rückschlüsse funktionieren sogar bei so knapp beisammen liegenden Werten nicht, oder eigentlich gerade auch bei denen nicht, wei sie im statistischen Rauschen eher untergehen (vorausgesetzt, man kennt ein solches, auch nicht ganz richtig, untergehen tun sie auch ohne das, nur weiß man's nicht, wie sehr sie's tun
).
Was sehen wir: es sind 6 Lösungen weniger bei gleichen StatTS- Elo, weil die time indices dafür um das besser sind, ist der FDT2- runs sogar um einen Platz weiter oben gereiht, jedenfalls sind die beiden runs hier aber in keiner Weise statistisch relevant unterschieden, wenn man nicht nur due Lösungen allein zählt und nicht nur bei so wenigen Stellungen und nur 2 runs für sich allein betrachtet. Und MultiPV=4 hat ungleich mehr gebracht.
Die Frage war übrigens, die ich an Walter gerichtet hatte und nicht an dich, welche Stellung hat bei welchem Full depth threads- Setting ein um wieviel bessere time to solution relativ zu einem bestimmten (für die Stellung ebenfalls nützlichen) MultiPV- Setting und wie groß ist da die statistische Schwankungsbreite. Bei einer einzelnen Stellung kann man ja leicht soviele Versuche machen, dass sich eine halbwegs relevante Schwankungsbreite zeigt.
Aber nehme wir einfach mal eine Stellung, die ShashChess auch single thread flott löst, z.B. diejenige, die ich auch hier verwendet habe
https://talkchess.com/viewtopic.php?p=990539#p990539der direkte YACPD- Lind daraus
https://www.yacpdb.org/#search/M0I0XC8xcjJwM1wvcjJwMXAyXC9ia3AxUDFwMVwvMXAxUDFQUHBcL3AxUDFLMlBcL1BQQjVcLzgvLy8vLy8vLy8vLy8vLzEvMS8xLzA=/1Zunächst mal single thread ohne FDT:
Engine: ShashChess41.1GD (1024 MB)
von the ShashChess developers (see AUTHORS
20/35 0:01 -5.84 1.c4+ Kxc4 2.Ld3+ Kd5 3.exf6 cxd4+
4.Kf3 exf6 5.Lxa6 Ta7 6.Lc4+ Kxc4
7.b3+ Kd3 8.Lxf6 Ta8 9.fxg5 Tf8
10.Kg2 Tg8 (3.731.404) 2443
...
28/49 0:38 -7.25 1.exf6 exf6 2.Lxf6 gxf4+ 3.Ke2 axb2
4.c4+ Kxc4 5.dxc5 dxc5 6.Lxb2 Kb5
7.Kf3 Ld8 8.Ld3+ c4 9.Lf5 Lg5 10.Lc8 Txa2
11.Lxb7 Txb2 12.Ke4 Ld8 13.Kf5 Kc5
14.Le4 (97.247.196) 2527
29/51 0:44 -4.95++ 1.La4+ (113.655.862) 2536
29/67 0:48 -4.32 1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6
4.d5+ Kd7 5.e6+ Kc8 6.f5 Lc7 7.Ke2 Tb8
8.Kd3 La5 9.Kd2 Kb7 10.Ke2 Tc8
11.Kd3 Lb6 12.Ke2 Txd8 13.Ke1 La7
14.Kf2 (128.621.803) 2651
...
42/70 1:13 -4.29 1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6
4.d5+ Kd7 5.e6+ Ke8 6.f5 Kf8 7.Kd2 Kg7
8.Ke3 Kh6 9.Ke2 Ta8 10.Kf2 Td7
11.Kf1 Lc7 12.Ke2 Ta6 13.Kf2 Lb6
14.Lc7 (236.858.792) 3236
Wir verzichten hier darauf zu warten, bis die Eval die einzig wirkllch richtige mit 0.00 würde, weil wir wissen, dass das in dieser Stellung mit dieser Engine auch mit vielen Threads sehr lange nicht passiert, aber die ersten 6 Züge der Output- Line zeigen ja, dass der einzig richtige Weg gefunden ist, die Festung steht.
und dann mit FDT=1, natürlich wieder single thread und allen anderen Parametern auch wie zuvor:
3B4/1r2p3/r2p1p2/bkp1P1p1/1p1P1PPp/p1P1K2P/PPB5/8 w - -
Engine: ShashChess41.1GD (1024 MB)
von the ShashChess developers (see AUTHORS
20/36 0:01 -5.86 1.exf6 exf6 2.c4+ Kxc4 3.Ld3+ Kd5
4.Lxa6 Ta7 5.Lxf6 cxd4+ 6.Kf3 Txa6
7.bxa3 gxf4 8.Kxf4 d3 9.Ke3 d2
10.Kxd2 b3+ 11.Kd3 bxa2 (3.305.460) 2490
...
32/55 1:52 -7.54 1.exf6 exf6 2.Lxf6 gxf4+ 3.Kf3 axb2
4.c4+ Kxc4 5.dxc5 dxc5 6.Lxb2 Ld8
7.Lb3+ Kb5 8.g5 Lxg5 9.Lc1 Te7
10.Kg4 c4 11.Lb2 cxb3 12.axb3 Td7
13.Kxg5 f3 14.Kg4 (284.807.180) 2540
33/57 3:15 -5.85 1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6
4.d5+ Kd7 5.e6+ Kc8 6.Lxa5 gxf4+
7.Kxf4 Txa5 8.Kf5 Tc7 9.Kg6 Kb7
10.Kh6 Ka8 11.Kg7 Taa7 12.Kg6 Kb7
13.Kf7 Ta8 14.Kg7 (496.657.093) 2542
...
36/72 3:22 -4.03 1.La4+ Kxa4 2.b3+ Kb5 3.c4+ Kc6
4.d5+ Kd7 5.e6+ Kc8 6.f5 Lxd8 7.Kf2 Lb6
8.Kf1 Tb8 9.Kg2 Ta7 10.Kf2 Kc7
11.Ke1 Th8 12.Kf2 Kd8 13.Ke2 La5
14.Kf3 (523.604.988) 2587
Dauert halt einfach deutlich länger, braucht, weil single thread eher deterministisch, auch keinen MultPV- Vergleich, weil's ja offensichtlich auch default die best line flott nach oben bringt. Wieviel da jetzt "abgeschntten" wurde, bevor die Lösungsvariante die primary wurde, können wir nur vermuten, aber viel wird's wohl nicht gewesen sein, infolgedessen kostet die an brute force näher angesiedelte (wirklich brute force ist wohl auch noch einmal eine Nummer anders) dadurch, dass sie noch weniger abschneidet, einfach beides, besser gesagt, addiert Zeit zu beidem, zur time to depth und zur time to solution. Was jetzt bei welcher Stellung welchen Unterschied in diesen beiden Kriterien macht, untersucht man entweder anhand jeder Stellung, die einen interessiert, einzeln, SMP halt auch mit entsprechend vielen runs, bis man eine halbwegs relevante Schwankungsbreite hat, oder man nimmt genug Stellungen, sowohl solche, die schnell gelöst werden als auch solche, die länger brauchen und vergleicht sie mit genug Engines, Settings, Runs, dann kann man statistische relevante Aussagen für das eine Stellungs- Hardware- TC- Engine(-setting)- Sample machen, beachtet man, wie's EloStatTS macht, außer den Lösungszahlen auch die Lösungszeiten Stellung für Stellung, oder man vergleicht entsprechend viele unterschiedliche Hardware- TC- Vorgaben, dann gibt das irgendwann einen Eindruck übers Verhältnis von distinction to error bar (ein Tool wie EloStatTS sagt einem, wann das inwieweit der Fall ist, nämlich wie groß die für die Anordnung relevante error bar relativ zur Unterschiedsgröße ist).
So wie du das machst, kann man's auch machen, ich würde aber halt sagen, da kann man's auch genau so gut (nein besser, weil's Strom und Hardware- Zeit spart) sein lassen.
Weil es beides nicht tut: es untersucht nicht die schachlich relevanten Unterschiede der einzelnen Stellungen und andererseits auch nicht einmal die statische Relation genau dieser einen very small sample size in Relation zu einem jedenfalls viel größeren, weil very big bias
Forum
CSS-Shop