Frage zu den Lösungsergebnissen von Testsuites

By Peter Martan Date 2024-02-06 12:32 Edited 2024-02-06 12:46

Was du einfach machen musst (wenn's dich entsprechend genau interessiert) ist, eine error bar für das jeweilige Ergebnis ermitteln. EloStatTS macht das z.B. automatisch, Frank Sanders hat für MEA- Ergebnisse ein entsprechendes Tool erstellt,

https://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?pid=167687#pid167687

und händisch kannst du auch Stellung für Stellung und Engine für Engine lauter Minimatches als WDL- Ergebnisse (Win nur von der einen, Draw von beiden oder keiner, Loss nur von der anderen von jeweils 2 verglichenen Engines in der vorgegebenen TC gelöst und jeweils von einer einzelnen Stellung und einem einzelnen Enginepaar aus betrachtet für den jeweils einen auszuwertenden Run) und diese Zahlen wieder z.B. in EloStat (vom selben Autor Frank Schubert wie EloStatTS) eingeben, da bekommst du auch WDL- Elo und die entsprechende error bar dazu (die du natürlich genau so gut aus z.B. Performance- Prozenten ausrechnen lassen kannst, welches Maß du nimmst, spielt keine Rolle).
Und all das kannst du für einzelne Runs so machen, wenn dir da die error bar zu groß ist, kannst du beliebig viele Runs auswerten, oder mehr Stellungen nehmen oder andere Stellungen oder mehr Engines oder andere Engines.
Es verhält sich das alles statistisch einfach genau so wie beim game playing. Die Signifikanz richtet sich nach der Selektivität der Testbedingungen und nach der Datenmenge.

Da (beim game playing) könntest du dich ja auch mit einer einzelnen noch so kleinen error bar diesbezüglich nicht zufrieden geben, als du noch und noch mehr Partien für eine noch und noch kleinere error bar, verschiedene Hardware- TCs, verschiedene Eröffnungen und verschiedene Gegner- Pools verlangtest, um die einzelnen Ergebnisse dann zu einer Gesamtsicht zu vereinigen.
Das eine ist immer die reine statistische Signifikanz des einen Tests, das andere die Übertragbarkeit auf andere Tests, eigentlich hat das eine mit dem anderen nur sehr am Rande zu tun.

By Dieter Brandhorst Date 2024-02-06 12:54

Danke, werde das mit Elostat und den WDL einmal nachbilden.

Dieter

By Peter Martan Date 2024-02-06 13:02 Edited 2024-02-06 13:13

Das kann ich dir sehr empfehlen, Dieter.
Es muss ja auch nicht genau EloStatTS sein und es muss auch gar keine Elo- Umrechnung sein, die ist nur für mich der einfachste Weg überhaupt (mehr oder weniger automatisiert) eine error bar für das Ergebnis einer Testsuite zu bekommen. Ansonsten kann man sich natürlich auch mit einer einzelnen Teststellung "begnügen" und mit 2 einzelnen Engines. Bei A-B- Engines reichen dann single thread sogar einzelne Runs, bessere time to solution ist besseres Ergebnis der einen Teststellung und aus. Und mit SMP oder NN- Engines, bei denen single thread auch nicht vergleichbar deterministisch ist, machst du halt soviele Runs, als du je nach Streuung für einen Mittelwert brauchst, der dir verlässlich genug erscheint.

Ich glaube nur immer wieder bei Fragen wie deiner, ob du wirklich die Signifikanz der einzelnen Messergebnisse einzelner Stellungen meinst, oder die "Signifikanz" der verwendeten Stellung(en), das sind 2 völlig verschiedene Signifikanz- Begriffe. Der eine ist berechenbar, der andere reine Geschmackssache, die du aus deinem persönlichen schachlichen Interesse nur für dich selbst allein beurteilen kannst, für wie signifikant du eine einzelne Teststellung hältst, anhand derer du die Spielstärke eines Programms messen willst. Aber um diese Frage kommst du auch nicht herum, wenn du eine bestimmte Eröffnungsstellung für eine halten willst, die für Eng-Eng-Matches zum Ausspielen lassen taugt oder nicht. Wieviele du von welchen Stellungen brauchst für eine bestimmte Power deiner Statistik, und ob du nicht doch lieber t-Test, unabhängig oder verbunden, Mann- Whitney- U oder Wilcoxon oder sonstwas als Formel statt der von Arpad Elo nimmst, das kannst du zum Schluss noch einen Statistiker fragen, spielt aber für solche simple Aufgaben wie die Berechnung, ob das eine oder andere Schachprogramm mehr Punkte gewonnen hat in einer bestimmten Testumgebung, eine relativ kleine Rolle

By Dieter Brandhorst Date 2024-02-06 14:49

Lieber Peter,

meine initiale Fragestellung war folgende: Wieviel der 32 Threads meiner CPU reichen für Stockfish aus, damit keine signifikante Leistungssteigerung (lösen von Testsuites), durch mehr Rechenleistung auftritt. Wenn z.B. dazu 4 Threads ausreichen würden, könnte ich locker mehrere Instanzen der Deepshredder13-GUI gleichzeitig mit unterschiedlichen Engines zum lösen von Testsuites nutzen. Deshalb wollte ich die Lösungswerte für 1,2,4,8,16 und 32 Threads vergleichen.
Ich war aber erstaunt als ich z.B. SF16_8threads, 7 mal den HTC114/1sec. hintereinander machen ließ, Werte von 25 bis 36 Lösungen (Hash wurde selbstverständlich immer wieder gelöscht), mit einem MW=29,57 und einer SD=3,62 erhielt. Will ich nun diesen Mittelwert mit dem Mittelwert einer anderen Engine oder einem Stockfish mit mehr Threads oder mehr Bedenkzeit vergleichen, so muss ich ja untersuchen inwieweit dabei Unterschiede zufällige Schwankungen oder mit hoher Wahrscheinlichkeit (>95%) echt sind. Um diese Signifikanzen geht es mir. Die Streuungen können dabei von Engine zu Engine oder TC zu TC ganz unterschiedlich sein, habe ich festgestellt.

LG Dieter

By Peter Martan Date 2024-02-06 15:03 Edited 2024-02-06 15:22

Dieter Brandhorst schrieb:

Ich war aber erstaunt als ich z.B. SF16_8threads, 7 mal den HTC114/1sec. hintereinander machen ließ, Werte von 25 bis 36 Lösungen (Hash wurde selbstverständlich immer wieder gelöscht), mit einem MW=29,57 und einer SD=3,62 erhielt.

Das erstaunt mich auch, Dieter, soviel Unterschied sollte da in einem vernünftigen GUI mit vernünftigen Stellungen und ebensolcher dazu passender TC nicht sein. (Banksia hat z.B. Gesamt- Zeitverbrauchs- Schwankungen bei ein und derselben Engine, selbst bei praktisch gleichen Lösungszahlen von Run zu Run, die solche Unterschiede wie die von dir geschilderten bewirken können, aber das liegt dann nicht (nur oder vorwiegend) an den Stellungen und nicht (nur oder vorwiegend) an der Engine sondern am GUI und seiner Art mit TC- Vorgaben in Stellungstests an und für sich umzugehen. Bei Banksia würde ich jedenfalls auch immer das Maximum an Extraplies eingeben, das macht die Schwankungen eher etwas kleiner, aber mehr als 2 Engines in einem gemeinsamen Run würde ich da möglichst nie miteinander vergleichen, zum Führen irgendwelcher Listen ist das GUI nicht tauglich, was das Stellungstest- Feature angeht, aber das nur so am Rande. Es ist halt eine weitere Quelle für Zufallsschwankungen, und eine, die man gern übersieht. In z.B. Fritz und Shredder fällt das weitgehend weg.
Mit Ferdinand Moscas MEA- Tool hast du zwar gute Reproduzierbarkeit des Gesamtzeitverbrauchs pro Run und Engine, aber die "Interpretation" der msec/Stellung reißt da bei bestimmten einzelnen Engines (SF- dev- Versionen nicht, aber auch z.B. ein Branch wie ShashChess nimmt sich da viel mehr Zeit, als eigentlich vorgegeben wäre, da sieht man aber zum Schluss, wie weit die Abweichung ist und passt die msec- Vorgabe einfach im Verhältnis an, Lc0 nimmt sich im Gegenteil wieder fast nur die Hälfte der zugeteilten Zeit, da sind 380msec./pos in den meisten Suiten ziemlich genau das, was man vorgeben muss, damit es mit dem Gesamtzeitverbrauch von SF dev. zusammenpasst.

Unnötig lange Einleitung, aber weil ich schon bei den Fehlerquellen war, zuerst eine, die gern missachtet wird, vorne weg.
Hingegen soll "HTC114/1sec" wohl heißen, 1sec/Stellung, wenn es das ist, was du gemacht hast, musst du dich über die große Streuung auch nicht wundern, 1"/pos. ist auf ziviler Hardware und erst recht bei "nur" 8Threads davon viel zu wenig, wenn du nur einzelne Runs (7 müsstest du sonst durch 700 ersetzen und hättest insgesamt wieder einen noch größeren Gesamt- Hardwarezeitaufwand, und du könntest das dann zwar statistisch auch wieder stimmige Ergebnis erst recht mit keinem anderen unter anderen Hardware- TC- Enginepool- Bedingungen vergleichen.
Da können auch noch soviele Extaplies nicht davor schützen, dass die wenigen Stellungen, die überhaupt gelöst werden, von den wenigen, die insgesamt zur Verfügung stehen, zu einem großen Teil gerade noch zufällig in die TC hineinrutschen (dann auch noch zu einem guten Teil nicht aus "richtigen Gründen" sondern ihrerseits zufällig, weil der richtige Zug gerade vor dem Fähnchen nach oben kommt, Extraplies haben keine Chance, das noch zu korrigieren als falsch positiv) oder halt im nächsten Run gerade nicht mehr.

Nimm wenigstens 15"/Stellung für wenigstens 8 Threads mit wenigstens 2 Extraplies, wenn's der alte HTC114 von Vincent Lejeune sein soll (Vincent hatte den seinerzeit für 30 Minuten pro Stellung, allerdings single thread, konzipiert) und probier's damit nochmal im Fritz oder Shredder, dann reden wir weiter

By Dieter Brandhorst Date 2024-02-06 15:23

War in Shredder, aber eben nur 1 Sekunde Lösungszeit. Bei 2 Sekunden TC war es auch noch so. Wobei 2 Sekunden für einen Prozessor schon richtig viel Zeit ist. Mache es trotzdem mal mit 15 und werde berichten.

LG Dieter

By Peter Martan Date 2024-02-06 15:35 Edited 2024-02-06 15:50

Dieter Brandhorst schrieb:

Wobei 2 Sekunden für einen Prozessor schon richtig viel Zeit ist

Nein, Dieter, nicht für diese Stellungen, wie gesagt, vom Sammler für 30 Minuten/Stellung single thread gedacht, und das auch nicht im vorigen Jahrhundert, sondern in der unmittelbaren Nachfolge- Suite der HTC 2022, soo viel hat sich da mit der Hardware- Zeit- Leistung seither auch wieder nicht getan. Findet man die Stellungen als Suite nicht mehr zeitgemäß, soll man sie nicht mehr als alleinige Suite verwenden und schon gar nicht mit völlig unsinnigen TC- Vorgaben. Wenn man's dennoch macht, darf man sich über viel wundern, aber nicht daüber, dass die Zufallsstreuung der an und für sich schon zu wenigen Stellungen dann dementsprechend hoch geht

Mach dich von dem Gedanken frei, dass du hier die Knoten, die du pro Thread mehr hast, in time to solution direkt umrechnen kannst, das ist genau der Denkfehler, dem immer noch erstaunlich viele "Tester" unterliegen, beim game playing ja auch, da fällt's nur schon bei einer kleineren TC- Schwelle nicht mehr auf, weil die Remisrate alles zudeckt, diesen "Bonus", der ja eigentlich ein Malus ist, hast du bei selektiven Teststellungen eben nicht.
Und lass dich nicht von Suiten täuschen, die ich mit 200msec./Stellung laufen lasse, das sind eben auch ganz andere Stellungen und es ist eine andere Art der Auswertung, es ist nicht das alleinige single best move- Prinzip sondern das der verschieden hohen Punktebewertung verschiedener multipler Lösungszüge.
Swaminathan und Corbit haben das damals mit ihrer Strategic Test Suite aufgebracht, aber eben auch gleich mal mit 1500 Stellungen statt 100 oder 114 und auch nur mit wenigen Sekunden/Stellung, was den 200msec. der heutigen Hardware und MEA- Auswertung entspricht.
Die Absicht war (und ist) dabei, die Engine gar nicht so richtig zum Rechnen kommen zu lassen sondern praktisch ihre "statische Eval" mit verschiedenen Punkten pro möglichem Lösungszug zu bewerten. Die Stellungen waren ausgesucht "positionelle", nicht- forcierte, ohne taktisch- knifflige, nur mit gewisser Suchtiefe auffindbare Motive.
Vergiss mal dieses andere Prinzip, wenn du single best move- Suiten wie die von Lejeune verwenden willst und lass dir nichts von Besserwissern einreden, die meinen, sowas könne man heutzutage single thread mit einzelnen Sekunden laufen lassen.
Ja, kann man schon, hat aber halt eine dementsprechend hohe Zufallsstreuung bei entsprechend kleinen überhaupt zählenden Ergebnisswerten. Merke: zuviele Lösungen machen just überhaupt nichts in Hinblick auf die Schwankungsbreite aus, ab einem gewissen Test- immanenten Ergebnis bekommst du keine Diskrimination mehr, aber die error bar geht auch gegen 0, genau so wie mit game playing und hoher Remisrate, die schadet, was die error bar allein angeht, auch just nix, du kannst dann bei 100% Remis auch schon bei ganz wenigen Partien mit error bar 0 sagen, die Engines sind ziemlich gleich stark, so what?

Statistische Signifikanz innerhalb des einzelnen Tests ist das Eine, Aussagekraft in Hinblick auf "overall playing strength" (eine reine Elosion dieser Ausdruck sowieso, es gibt keine nicht stellungsabhängige und damit irgendwie "overall" Spielstärkemessung) und Unterschiede zwischen einzelnen Engines in einzelnen Tests ist das Andere.
Just my two cents mal wieder,

By Dieter Brandhorst Date 2024-02-06 17:41

Alles gut und schön und auch nachvollziehbar. "Doch Versuch macht kluch". Deinen Anregungen folgend mache ich gerade mit der Deepshredder GUI den HTC114 Test mit 15 Sek/Stllung.

Testengine: Stockfish16, genuin, MPV=1, Hash=2048MB, 8 Threads (ca. 6Mio N/s in Grundstellung);Extraplies=2
Hardware : Threadripper 1950X, 3,4 GHZ

Run1: Bisher gelöst:67 von114; 16:26m

        1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16  17  18  19  20
   0 |  15  11  10  -   -   9   -   1   4   9   -   -   1   1   -   1   1   3   -   4
  20 |  -   -   -   -   0   -   0   -   -   -   -   11  0   -   1   1   0   -   -   -
  40 |  5   0   -   3   -   12  -   0   0   -   -   -   -   5   0   -   -   -   6   -
  60 |  3   0   -   0   15  14  0   -   0   0   4   8   -   -   7   2   2   -   0   -
  80 |  10  -   4   0   14  -   0   0   0   -   -   12  -   -   -   6   3   0   3   0
  100|  0   6   0   0   0   -   4   9   -   0   3   -   0   3

Run2:Bisher gelöst:61 von114; 16:40m

        1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16  17  18  19  20
   0 |  3   -   -   -   -   9   -   3   -   6   4   -   1   4   6   1   0   3   -   15
  20 |  -   -   -   -   0   -   0   -   -   -   -   8   0   -   1   4   0   -   -   -
  40 |  3   0   -   6   -   11  -   0   0   -   -   -   -   6   0   -   -   -   3   -
  60 |  -   0   -   0   10  -   0   8   0   0   11  4   -   -   -   3   0   -   0   -
  80 |  4   -   4   0   -   -   0   2   0   -   -   -   -   -   -   2   5   0   1   0
  100|  0   1   1   0   0   -   -   -   6   0   3   -   1   10

Das sind die ersten beiden Runs mit 15 Sek./Stellung. Auffällig ist neben den unterschiedlichen Lösungszahlen 61 vs. 67/114 , dass es 10 Lösungen gibt, die nur in Run1 gefunden werden (2,3,9,61,66,75,85,92,107,108) und 4 Lösungen die Stockfish exklusiv nur in Run2 findet (11,15,68,109) und nur 57 Stellungen die in beiden Runs gelöst werden. Wie kann man das erklären?

By Peter Martan Date 2024-02-06 17:56 Edited 2024-02-06 18:43

Dieter Brandhorst schrieb:

Auffällig ist neben den unterschiedlichen Lösungszahlen 61 vs. 67/114 , dass es 10 Lösungen gibt, die nur in Run1 gefunden werden (2,3,9,61,66,75,85,92,107,108) und 4 Lösungen die Stockfish exklusiv nur in Run2 findet (11,15,68,109) und nur 57 Stellungen die in beiden Runs gelöst werden. Wie kann man das erklären?

Zufall

Drum wär's ja jetzt halt fein, du würdest Stellung für Stellung als Minimatch betrachten zwischen den beiden "Engines" (Runs), und dann vielleicht auch noch bei denjenigen, die in beiden gelöst werden, das auch nicht als Remis, sondern als Punkt werten für diejenige Seite, die eine kürzere Lösungszeit hat, dann machst du händisch das, was EloStatTS automatisch macht. Damit kriegst du nämlich zwar nicht zwangsläufig eine bessere Diskrimination (vor allem bei ein und derselben Engine eher unwahrscheinlich

), aber es interessiert dich ja jetzt auch oder sogar vorrangig die statistische Belastbarkeit, und die steigt mit der Zahl der Versuche, und der Hardware- Zeit jedenfalls an. Sogar mehr, als wenn du nur die Lösungszahlen betrachtest, weil sich ja die einseitigen Lösungen nur teilweise überschneiden, du siehst also bereits, den Zufallseinfluss kannst du relativ leicht quantifizieren und minimieren, indem du nicht nur Lösungen zählst, sondern WDL. Beim game playing hast du als statistisch noch schlechteres Pendant zu den Remis die 1:1-Paare, die bringen auch nur "Scheinpunkte", in Wirklichkeit steigern sie die error bar mehr als die Remis bei gleicher Performance.

Wenn du genug Runs (sei's mit mehreren derselben oder mit verschiedenen Engines) auf die Art wieder in lauter Minimatches zwischen je 2 Engines (Runs) aufgegliedert hast, wird die error bar immer kleiner. Der Unterschied in der Performance halt klarer Weise auch, aber was genau ist jetzt dein Problem?
Dass du genug Runs mit genug Hardware- TC brauchst, oder dass du aus dem Ergebnis halt auch dann, wenn es statistisch abgesichert ist, immer noch nicht unbedingt all das heraus lesen kannst, was du heraus lesen wolltest?
Dass deine beiden "Engine" ungefähr gleich stark sind, hast du ja sogar bei den stark streuenden 2 Versuchen als Ergebnis bekommen. Dein Irrtum besteht einfach darin (wenn ich deine Verwunderung richtig verstehe), dass du meinst, 10 Lösungen Unterschied seien hier relativ zu den Gesamt- Lösungen schon viel, das hängt eben davon ab, womit du das vergleichst. Ich mag jetzt nicht eigens genau deine Testbedingungen wiederholen (ein bisschen stark aberrant kommt's mir übrigens schon immer noch vor, aber so ist das halt mit einzelnen Versuchen oft auch, kann durchaus sein, die nächsten 5 streuen schon viel weniger), aber wenn ich mal mit einer List vergleiche mit ähnlichen Stellungen und ähnlicher Hardware- TC sind z.B. diese beiden Engines mit ungefähr diesen deinen Lösungszahlen in einem solchen Bereich beisammen, was die statistische Unterscheidbarkeit angeht:

  Program                                    Elo   +/-  Matches  Score   Av.Op.   S.Pos.   MST1    MST2   RIndex

 40 Stockfishdev-20230104-9fe9ff00-MV4       : 3509    4   6396    51.4 %   3499    66/128    4.1s    9.4s   0.42
 41 Lc0v0.31.0-dag+git.d99093e3-2660M        : 3507    5   6634    50.6 %   3503    59/128    3.1s    9.5s   0.38

7 Lösungen Unterschied, die sich aber mit den insgesamt 77 Vergleichsruns (anderer Engines) auf 2 Elo relativieren bei einer error bar von 4 bis 5, so what?

Wenn's letzteres ist, musst du einfach mehr als die eine Suite allein nehmen, oder du findest dich damit ab, dass du Engines, die in der Spielstärke nahe beisammen liegen, nur mit Tests diskriminieren kannst, die im Ergebnis für sich allein stehen, z.B. mit time to solution- Messungen jeder einzelnen Stellung. Deren Reproduzierbarkeit ist single thread A-B schon im einzelnen Versuch gegeben, und dann gibt's halt auch solche, die viel SMP- (NN-) Streuung haben und solche mit kleiner, aber da siehst du's wenigstens schneller, um welche Art von Stellung relativ zur Engine es sich handelt.
Das Extrembeispiel für "sie wissen nicht, was sie testen", sehe ich hingegen immer noch im game playing, wenn du schon beim Stellungstesten siehst, wie groß die Zufallsstreuung ist, was sagt dir das über die beim Eng-Eng-Match? Und wie steht's mit der Übertragbarkeit bei der von Match zu Match mittlerweile?
Jouni Uski hat hier mal wieder einen kleinen (small sample size)- Versuch mit game playing, SF16 und Thread- Verdopplung gemacht:

https://talkchess.com/forum3/viewtopic.php?p=958155#p958155

Auch nicht ganz das Ergebnis, das man sich zunächst mal auf Anhieb erwarten würde, aber da hat man sich halt dran gewöhnt zu sagen, ja 400 Partien, was soll's.
Und du willst mit 2 Runs von 114 Stellungen den Remistod im Computerschach rückgängig machen?

By Dieter Brandhorst Date 2024-02-06 18:40

"Der Unterschied in der Performance halt klarer Weise auch, aber was genau ist jetzt dein Problem?"

Das Problem heißt Reproduzierbarkeit. Bei Heuristiken die Zufall mit in ihre Entscheidungsfindung einbinden, wie z.B. MCTS, ist die Varianz der Ergebnisse natürlich dementsprechend höher, die Reproduzierbarkeit geringer und vergleichende Analysen sind nur mit Durchschnittswerten und statistischen Methoden möglich. Nun scheint ja auch Stockfish, wenn auch ohne MCTS propagiert, eine Menge Zufall in seine Variantenberechnung bzw. Heuristik einzubringen, wie die Ergebnisse der Tests zeigen. Das scheint mir der gewichtigerer Grund für die Varianz zu sein als eine zu kurze Bedenkzeit. Ich finde das nicht uninteressant und denke mal einige Engines mit kurzen TCs ( 1 bis 2 Sek/Lsg.) dafür aber mehreren Runs zu vergleichen. Mich würde auch interessieren ob sich z.B. das Anschalten von MCTS in z.B. ShashChess so günstiger darstellt.

By Peter Martan Date 2024-02-06 18:56

Du hast das Wesen eines Stellungstests als automatisch ablaufender Suite noch nicht ganz internalisiert, glaube ich, Dieter.
Ich hab noch nachdem du schon geantwortet hattest, als Edit ein Beispiel einer EloStatTS- Liste eingefügt.
Die Zufallsstreuung, die du so krass findest, ist nichts im Vergleich zu der, die du beim game playing hast, dort wird die Zugfindung noch stärker von Zufall, TC, Eröffnungen und Teilnehmerfeld bestimmt, du meinst nur, es macht nichts, weil nur die ganzen und halben Punkte zählen, beim Stellungstest erhoffst du dir eine Art von Determinismus, die kriegst du aber nicht automatisch dadurch, dass du mehr Versuche mit kürzerer TC machst, die Stellungen müssen in ihren Lösungszahlen zur Hardware- TC und zum Teilnehmerpool passen.
Das Prinzip der statistischen Belastbarkeit ist dasselbe wie beim game playing, zu viele und zu wenige Lösungen (ganze und halbe Punkte) bestimmen das Verhältnis von Unterschied zu Error.
Mit mehr Stellungen, von denen weniger gelöst werden, weil du kürzere TCs nimmst, änderst du daran nichts, du kriegst nur mehr Remis, gegen die du wirklich machtlos bist, auch mit exakter time to solution- Auswertung, da schaden dir die mehr Remis aus zu vielen gelösten weniger, weil die kannst du wenigstens noch mit der Zeitmessung weiter aufschlüsseln.
Aber lass dir deine eigenen Wege nicht verdrießen, ich war immer schon ein Verfechter von, jeder soll so testen, wie er's für richtig hält, man sollte sich halt hin und wieder schon auch ein bisschen um die Ergebnisse der Anderen kümmern und sich vielleicht auch mal was von denen sagen lassen, die's schon länger auf eine bestimmte Art machen, sonst muss man alle Fehler, die die schon lange als solche aus eigener schlechter Erfahrung erkannt haben, erstmal wieder selber machen und hoffen, dass man sie rechtzeitig als solche erkennt, bevor man für sich allein unnötig lang im Dunkeln getappt ist.
Ehrlich, ich meins nicht oberg'scheit, oder jedenfalls nicht nur

By Dieter Brandhorst Date 2024-02-06 19:43

Lieber Peter,

ich will natürlich nicht das Rad neu erfinden und höre gerne die Expertise erfahrener Spezialisten. Deshalb frage ich hier ja nach. So krass finde ich das mit der Streuung auch bei 1 Sekunde/Stellung nicht, alles war signifikant statistisch unterschiedlich zu anderen Engines. So wenig Lösungen waren es bei den anderen Engines eben auch nicht, da scheint der HTC114 -Test speziell gegen Stockfish gerichtet zu sein.

    HTC114/1sec

    SF16    Leptir  Leptir_big_ultra    ShCh34.5_Tal    cool_Iris11.8   Lc0BT3  Lc0BT4  TB:Lc0BT3+Leptir

1   36       56      62                    44                   49        56         60            69
2   31       61      63                    42                   39        61         63            66
3   28       56      59                    37                   44        60         64            66
4   25       63      60                    43                   48        58         64            65
5   27       61      63                    40                   49        58         63            70
6   33       63      61                    44                   48        59         64            66
7   27                                                                                             67

MW  29.57   60.00    61.33                41.67                 46.17   58.67        63.00       67.00
2SD  3.62    5.89     2.98                 4.99                  7.25    3.20         2.83        3.38
Min 25      56       59                   37                    39      56           60           65
Max 36      63       63                   44                    49      61           64           70

Das habe ich vor einigen Tagen schon mal gemacht und so wild ist das mit den Streuungen und den Lösungen gar nicht.
Z.B. unterscheidet sich TripleBrain(Lc0BT03+Leptir) durchaus statistisch signifikant von Leptir solo oder Lc0BT03 solo.70 Lösungen in der Spitze von TripleBrain bei 1 Sek/Lösung scheint mir auch nicht zu wenig zu sein.

VG Dieter

By Peter Martan Date 2024-02-06 20:23 Edited 2024-02-06 20:45

Du willst das Rad nicht neu erfinden, machst es aber gerade

Weil du statt der Elo- error bar eine Mittelwert- Schwankung als dein persönliches Maß der statistischen Relevanz einführst, änderst du ja nichts daran, dass du dieses dein persönliches Maß erst wieder mit dem abgleichen müsstest, was du an bisher relevanten error bars beim Schach kanntest.
Nur dazu scheint mir der Vergleich mit den Elo aus dem game playing sinnvoll, man sieht, was die WDL- Rechnung an schachlich relevanten Signifikanzintervallen bietet. Wenn du nicht irgend so einen Vergleich hast, woher weißt du, was deine statistischen Werte für eine schachliche Bedeutung haben? Dass du eine Unterscheidung an Punkten zwischen 2, 3 oder 4 Engines bekommst, die dich persönlich gerade interessieren und die du relativ zur statistischen Schwankung jetzt plötzlich doch wieder "nicht so wild" findest, was hilft dir das bei Engines, die mehr Schwankung als Unterschied bieten? Gerade hast du dich noch gewundert, dass ein- und dieselbe Engine selbst mit längerer TC noch Schwankungen bot, die du schon für schlechte Reproduzierbarkeit gehalten hast.
Einzelne Engines direkt gegeneinander zu unterscheiden, und seien sie noch so nahe beisammen, ist kein Problem, wenn du dich auf einzelnen Stellungen verlässt, bei denen der Unterschied halt groß genug ist.
Du bist von t-Tests aufgebrochen statt der Elo- Formel, statistische Relevanz zu beurteilen, jetzt genügen dir dann doch einfach Punktezahlen, ohne dass du dir weitere Gedanken machst, wieviel die Unterschiede relativ zur Zufallsschwankung zählen.

Wolltest du deine Ergebnisse jetzt mit denen Anderer und den unter Beteiligung stärker unterschiedlicher Engines vergleichen, müsstest du deine "error bars" erst wieder mit irgendeiner statistisch anerkannten Formel mit dem vergleichen, was ansonsten auch in einem bunteren Mix, z.B. aus WDL berechnet wurde.
Willst du sie nicht vergleichen, ist's auch ok, aber dann kommst du immer noch nicht drum herum, die relative Wertigkeit der Resultate, die du mit der einen und mit der anderen Suite, der einen und der anderen Hardware- TC und mit dem einen und mit dem anderen Enginepool bekommst.
Verstehst du, worauf ich hinaus will? Ich habe nie erreichen wollen, dass ich mit Stellungstests genauere oder bessere Elo bekomme und war mir immer bewusst, dass es andere sind, aber das sind auch Fernschachelo relativ zu over the board zwischen Menschen erspielte und reine Computerschach- Elo.
Die völlige Abkopplung schachlicher Performance- Messungen voneinander ist ein Weg, den man gehen kann, wenn man nur mehr mit einer bestimmten Art für sich allein testen will, ansonsten hat's halt schon auch (noch, wer weiß, wie lange) irgendwie Sinn, das Computerschach und das Schach als solches irgendwie als ein gemeinsames Spiel zu sehen.
Ich komme selbst in diesem einen Thread von dir jedenfalls nicht umhin, eine gewissen Inkonsequenz in dem zu finden, was du einerseits zuerst bei der kurzen TC schlimm zufällig fandest und jetzt aber eigentlich doch eh recht relevant. Ich bin wieder an dem Punkt, an dem du zusätzlich auch noch zwischen rein statistischer Signifikanz (die ja bei der einzelnen statistischen Aufgabe auch immer von der Merkmalsdifferenz der zum messenden Daten abhängt aber jedenfalls mit ankerkannten statistischen Methoden arbeiten muss) und schachlicher Signifikanz unterscheiden musst. Wenn dir deine Messungen diesbezüglich mehr sagen als die allgemein üblichen statistischen Methoden (und damit das game playing, das du dann auch gar nicht mehr mit deinen Ergebnissen vergleichen kannst) dann hast du alles, was du brauchst, sonst hast du zwar das Rad neu erfunden, weißt aber deshalb noch nicht, wohin du damit fahren willst

By Dieter Brandhorst Date 2024-02-09 12:16

Sehe gerade, dass ich ein Statistikbeispiel hier noch gar nicht gegeben habe. Will ich z.B. die Ergebnisse von CoolIris 11.8. mit denen von Leptir vergleichen, reicht ein Vierfeldertest.

Man zählt die Häufigkeiten der Lösungsergebnisse der Runs jeder Engine zusammen. Also für Leptir sind das 360 und für CoolIris 11.8. sind das 277 aus den jeweils 6 Runs. Die theoretisch mögliche Gesamtlösungsanzahl bei 6 Runs mit dem HTC114 wäre 6 mal 114=684. Schon hat man alle Werte für einen Vierfelder- oder Chi-Square-Test den man online hier: https://www.signifikanzrechner.de/chi-quadrat-test/ durch das Eintragen von 4 Zahlen: Stichprobengröße jeweils 684 und unter erfolgreiche Versuche einmal 277 für CooolIris und einmal 360 für Leptir. Es kommt ein p-Wert von nahezu 0, also fast absoluter Signifikanz für einen nicht zufälligen Unterschied zustande.
Ein einfacher und statistisch belastbarer Test, der die Aussage macht das mit fast 100%-iger Wahrscheinlichkeit die Ergebnisse von Leptir unter den hier gegebenen Voraussetzungen besser sind als die von CoolIris 11.8 und nicht auf Streuung oder Zufall beruhen.

VG Dieter

By Peter Martan Date 2024-02-09 13:48 Edited 2024-02-09 14:27

Dieter Brandhorst schrieb:

Ein einfacher und statistisch belastbarer Test, der die Aussage macht das mit fast 100%-iger Wahrscheinlichkeit die Ergebnisse von Leptir unter den hier gegebenen Voraussetzungen besser sind als die von CoolIris 11.8 und nicht auf Streuung oder Zufall beruhen.

Suppi, aber woher weißt du jetzt, wie sich das verhält, wenn du eine dritte Engine dazu nimmst, und oder andere Stellungen und oder eine andere Hardware- TC?
Nämlich, wenn du's nicht eigens neu ablaufen lässt, aber bitte wieder mit allen engines of interest von vorn, weil deine statistischen Aussagen vom vorigen Test ja wieder jeder Vergleichbarkeit mit dem neuen entbehren. Nicht nur haben sie keine direkte statistische Vergleichbarkeit, sondern vor allem fehlt ihnen jede Grundlage außer dem frommen Wunsch, dass das bei Schach als Spiel und den Engines, die du vergleichst, schon irgendwie so ähnlich sein wird, egal welche Bedingungen genau herrschen und welche Engines genau mitspielen. Das ist schon beim game playing nicht so, dass es da keine Rolle spielte, ob Round Robin oder Spießrutenlauf oder Schweizer System, und mit welchen Engines, welchen Eröffnungen und welcher Hardware- TC, beim Stellungstest hast du noch dazu relativ zur Größe des Datenmaterials weitaus mehr Selektionsbias in der Auswahl deiner Stellungen, das ist ein Vorteil, wenn du weißt, was dich an welchen Stellungen genau interessiert in Hinblick aufs Ergebnis, an Übertragbarkeit von Test zu Test ist's ein Nachteil. Was dir fehlt, wenn du nicht wenigstens ein irgendwie gemeinsames Maß hast, ist jegliche Vermutung über das quantitative und qualitative Ausmaß der Transitivität deiner Testumgebungen.

Und selbst wenn du mit jedem einzelnen Test deiner simpelsten Art zufrieden bist, sowie er die Minimalanforderungen erfüllt, die du statistisch an ihn knüpfen kannst, eins könnte dich zusätzlich zu der Erkenntnis, die zwei Engines werden bei dem einen Test wahrscheinlich nicht rein zufällig die Nase vor der anderen haben, wie groß diese Nasenlänge, die die eine vor der anderen liegt, wie viel die an an schachlicher Relevanz zählt, weißt du von deinem einen Test unter den einen Bediungen allein absolut nicht.
Das alleinige einzelne Verhältnis des Unterschieds an Gesamtlösungszahlen zur Standardabweichung bei einer bestimmten Zahl von Wiederholungen des selben Tests ist auch für sich allein quantitativ in keiner Weise aussagekräftig, weil sowohl die Zufallsschwankung als auch die Differenz der Lösungszahlen ein Test- immanentes Verhältnis wiedergeben.
Praktisch meine ich einfach das: es täuscht völlig haltlos in die eine oder andere Richtung, anzunehmen, weil der Unterschied zwischen den gemittelten Lösungszahlen im Verhältnis zur Schwankungsbreite bei einer bestimmten Wiederholungszahl so und so groß ist, ist der Unterschied zwischen den beiden Engines so und so groß, er ist es nur im Verhältnis zur Schwankung bei ein und demselben Test. Und selbst da würde ich jetzt wenn ich mir schon die Arbeit mache, eine Suite genau zu testen auf die Valenz ihrere Stellungen für bestimmte Engines und bestimmte Hardware- TC, dann doch versuchen ein möglichst hohes Verhältnis von Diskrimination zu error bar zu bekommen und nicht mit der geringst möglichen Relation zufrieden sein, die schon überhaupt ein kleines Plus für die Differenz relativ zur Irrtumswahrscheinlichkeit hat. Ich würde versuchen, die Stellungen, die Suiten für die Engines und den Hardware- Zeitaufwand zu nehmen, der am meisten bringt, und schon sind wir wieder bei derselben Frage: was nehme ich für Stellungen, Suiten, für was für eine Hardware- Zeit für welche Engines.
Es ist einfach ebenso wie beim game playing nicht egal, ob ich SF- Branches und -Versionen und Lc0- Compiles und -Netze allein untereinander vergleiche, dafür brauche ich mehr Stellungen von mehr Varianz an Hardware- Zeit- "Schwierigkeit", als für einen Test, in dem ich einerseits SF und Lc0 und andererseits auch schwächere Engines einer breiteren Range vergleichen will.
Um Leptir und Cool Iris allein gegeneinander zu vergleichen, mag dir das Ergebnis eines einzelnen Tests genügen, schon wenn du die beiden aber auch nur head to head gegeneinander games ausspielen lässt, siehst du, wie du da völlig verschiedene Ergebnisse (und ruhig alle in der heiligen Kuh Elo gemessen

) bei entsprechend stark verschiedenen Eröffnungen und entsprechend verschiedener Harware- TC bekommst. Erst recht, wenn du vielleicht noch das Setting an Parametern der einen und der anderen Engine ein bisschen änderst. Und du wirst sehr viel mehr game bei ansonsten halbwegs fairen Bedinungen brauchen als deine HTC114 und 6 runs, um wenigstens überhaupt eine halbwegs vernünftige LOS zu bekommen. Will sagen, dein Einzelergebnis sagt einfach außer dir, weil du dich damit zufrieden gibst, sonst niemandem irgendwas, schon gar nicht, ohne das Parameter- Setting der einen und der anderen Engine wenigstens in einem einzelnen Gegenversuch ein bisschen zu verändern, je nachdem, wie und wie sehr du's macht, hast du viel schneller als beim game playing auch einfach eine Ergebnisumkehr. Und dann könntest du anfangen dich zu fragen, welches Setting soll ich jetzt für welchen Test nehemen, wenn's mir ja gar nicht primär auf die Performance bei einem bestimmen head to head mathc einer bestimmten Hardware- TC ankommt, sondern auf irgenwelche anderen zusäztlichen Qualitäten. Die wären's ja eigentlich auch, die der Stellungstest zusätzlich zum game playing schneller, genauer oder überhaupt abbilden sollte.
Sorry, ist halt so.

By Max Siegfried Date 2024-02-06 18:32

Dieter Brandhorst schrieb:

Hallo zusammen,

ich habe bemerkt, dass die Ergebnisse von verschiedenen Engines und Testsuites, zum Beispiel beim HTC114, bei mehrmaligen Durchführungen auf derselben Hardware nicht immer identisch sind. Stattdessen variieren sie um einen Mittelwert. Das deutet darauf hin, dass für einen aussagekräftigen Vergleich solcher Testergebnisse statistische Verfahren wie der U-Test oder der t-Test notwendig sind, um zufällige Unterschiede möglichst auszuschließen. Es scheint, als müsste man jeden Test unter jeder Bedingung mehrfach durchführen. Mich interessieren eure Erfahrungen zu diesem Thema. Habt ihr ähnliche Beobachtungen gemacht?

LG Dieter

Man startet doch keinen Test mehrfach.

Du nimmst die BanksiaGUI.
Wählst bei Test 1000 mal wiederholen aus.
Siehst dir die Ergebnisse an.

Gelöste Aufgaben, während der 1000 Wiederholungen, werden ausgeblendet und nur noch die nicht gelösten Aufgaben wiederholt, bis die 1000 Wiederholungen durch sind.

By Dieter Brandhorst Date 2024-02-06 18:57

"Gelöste Aufgaben, während der 1000 Wiederholungen, werden ausgeblendet und nur noch die nicht gelösten Aufgaben wiederholt, bis die 1000 Wiederholungen durch sind"

Das ist aber eine Logik die davon aus geht, das was in Run1 gelöst wurde, in Run2 wieder gelöst werden kann und nicht wiederholt werden muss. So ist es aber nicht. Was Stockfish in Run1 löst, löst er in Run2 noch lange nicht und vice versa. Eine einmal von einer Schachengine gelöste Aufgabe kann nicht von einer Wiederholung ausgeschlossen werden und als konstant gelöst betrachtet werden, wenn der Zufall in der Entscheidungsfindung eine Rolle spielt.

By Reinhold Stibi Date 2024-02-06 19:30

Was habt ihr denn für ein Problem.

Mit Fritz GUI unterscheiden sich bei Wiederholungen der Tests die Werte nur um 1 oder 2 Stellungen, das ist doch
ganz normal.

Mit der Umrechnung der Testergebnisse auf Elo-Werte halte ich gar nichts; das ist doch Quatsch.

Die Elo-Werte kommen hauptsächlich aus dem positionellen praktischen Spiel.

Stellungstest zeigen die taktische Stärke.

By Dieter Brandhorst Date 2024-02-06 19:50

Danke, dann werde ich die Tests nochmal mit der Fritz-GUI machen. Wäre ja ein Ding, wenn es an der GUI läge.

VG Dieter

By Peter Martan Date 2024-02-06 20:49 Edited 2024-02-06 21:44

Entschuldige jetzt noch die vollends unbedarfte Frage (aber was weiß ich, wieviel Erfahrung du überhaupt schon mit Stellungstest- Suiten hast?): das Häkchen bei
"Exakte Zeit"
hast du bei der Zeit pro Zug- Vorgabe im Shredder- GUI schon gesetzt, ja?
Sorry, nur um sicher zu sein

Edit: mittlerweile hat es mich natürlich nicht mehr ruhen lassen, mal auch wieder mit SF dev. 2 runs mit je 8 Threads der 16x3.5GHz- CPU, der HTC114- Suite und 15"/Stellung laufen zu lassen im Shredder (13)- GUI, sogar beide gleichzeitig, das ist ja überhaupt der Hauptvorteil relativ zu Fritz, man kann in 2 verschiedene Protokoll- Dateien zwei Lösungsfiles simultan schreiben lassen. Das geht zwar bei Fritz auch, aber man hat nichts davon, wenn man beide runs im selben .cbh- file haben will. Verschmelzen kann man 2 davon nicht wirklich, man müsste es Partie um Partie machen, da ist man schneller, nacheinander neu zu starten.

Das sind die zwei Ergebnisse

Stockfish dev-20240203-f2b6b5cf0

Bisher gelöst: 69 von 114 ; 13:57m


         1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20
 -------------------------------------------------------------------------------------
   0 |   -   3   9   -   -   0   -   -   3   0   -   -   1   0   8   0   0   0   -   0
  20 |   1   -   -   -   0   -   0   -   6   -   -   -   4   0   1   0   0   -  14   -
  40 |   0   0   -   -   -   -   -   0   4   -   -   -   -   4   6   -   -   -   -   -
  60 |   -   2   -   0   -   -   0   -   0   0   3   4   -   -   3   2   6   -   0   -
  80 |   0   0   0   0   8   0   0   0   0  10   1  10   8   -   0   0   0   0   1   0
 100  |   2   0   0   0   0   -   -   0   -   0   0  12   0   0

TotTime: 17:11m SolTime: 13:57m

Und:

Stockfish dev-20240203-f2b6b5cf0

Bisher gelöst: 66 von 114 ; 14:27m

         1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20
 -------------------------------------------------------------------------------------
   0 |   -   6   -   -   -   1   -   2   3   0   -   -   0   0   -   0   0   5   -   0
  20 |   2   -   -   -   0   -   0   -  13   -   -   -   -   0   0   0   0   -   -   -
  40 |   1   0   -   -   -   -   -   0   0   -   -   9   -   2   4   -   -   -   3   -
  60 |   -   5   -   0   -   -   0   -   0   0   -   5   -   -   7   3   3  11   0   -
  80 |   0   0   0   0   -   0   0   0   0   7   0  12   -   -   0   0   0   0  10   0
 100  |   0   0   0   0   0   -   -   0   -   0   0   9   0   2

TotTime: 17:14m SolTime: 14:27m

Drei von 114, das ist eine für mich normale Schwankung, 7 wird vielleicht auch hin und wieder vorkommen, aber ich würde es schon für einen Ausreißer halten.
Wenn ich mal wieder viel freie Hardware- Zeit habe, probier' ich das Ganze nochmal single thread und mit 30 oder vielleicht sogar 60"/pos., das müsste das Rauschen noch einmal deutlich vermindern, ohne dass die Lösungszahlen stark einbrechen.

By Dieter Brandhorst Date 2024-02-07 16:13

Zitat: "Drei von 114, das ist eine für mich normale Schwankung,..."

Wie sagte Joseph Beuys so schön: ja, ja, ja, ja....nee, nee, nee, nee..

Wenn es wirklich nur 3 von 114 wären. Wenn du dir die beiden Runs einmal genau ansiehst, wirst du feststellen, dass es nur 62 Aufgaben gibt, die auch wirklich in beiden(!) Runs von der Engine gelöst wurden. Dagegen gibt es 7 Aufgaben, die Stockfish exklusiv in Run1 löst (3,15,33,39,71,85,93) und 4 Aufgaben exklusiv in Run2 (8,52,59,78). Die 7 die in Run2 nicht gelöst wurden, konnten durch die 4 Aufgaben wiederum die exklusiv in Run2 gelöst wurden etwas kompensiert werden. 7-4=3, also daher der relativ kleine Unterschied. Es gibt aber in den beiden Runs insgesamt 7+4=11 Aufgaben die von der Engine ganz unterschiedlich gelöst bzw. nicht gelöst wurden.

VG Dieter

By Peter Martan Date 2024-02-07 17:49

Dieter Brandhorst schrieb:

Wenn du dir die beiden Runs einmal genau ansiehst,

Ich hab' sie nicht nur Stellung für Stellung verglichen, sondern auch nach den Lösungszeiten und in WDL umgerechnet.

https://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?pid=168269#pid168269

Zitat:

Die Shredder- Tabellen aus meinem obigen 66 zu 69 2-run Beispiel so übereinander gelegt, dass du die gleichen Spalten direkt untereinander hast und leicht die Zeiten Stellung für Stellung vergleichen kannst:

[url]

[/url]

Dann die Stellungen, die im einen run relativ zum anderen gewonnen wurden und die verlorenen und die Remis in EloStat eingegeben:

<code>Wins = 20
Draws = 80
Losses = 14
Av.Op. Elo = 3500

Result : 60.0/114 (+20,=80,-14)
Perf. : 52.6 %
Margins :
68 % : (+ 2.5,- 2.5 %) -> [ 50.1, 55.2 %]
95 % : (+ 5.0,- 5.0 %) -> [ 47.7, 57.6 %]
99.7 % : (+ 7.6,- 7.5 %) -> [ 45.1, 60.2 %]

Elo : 3518
Margins :
68 % : (+ 18,- 18) -> [3501,3536]
95 % : (+ 35,- 35) -> [3484,3553]
99.7 % : (+ 54,- 52) -> [3466,3572]</code>

Was folgern wir daraus: die Standardabweichung allein zum Vergleich mit der Streuung der gelöst- nicht gelöst- Zahlen ist nur die halbe Wahrheit

By Dieter Brandhorst Date 2024-02-06 22:29

Ja, das mit dem Häkchen exakte Zeit und auch das löschen der Hashtables ist mir natürlich bekannt . Um dir ein relevanteren Eindruck über die Varianz einer Engine zu machen solltest du mindestens 5 bis 6 Runs mit einer Engine machen, nicht nur 2. Das was ich gemacht habe ist kein Hexenwerk, sondern eine ganz normale und obligatorische wissenschaftliche Herangehensweise bei dem Vergleich zweier Stichproben und deren zugrunde liegenden Grundgesamtheiten. Natürlich spielt hier die Frage eine Rolle, ob es zwischen den Engines relevante Unterschiede bei der Lösung von Schachaufgaben gibt und inwieweit das von der Hardware und/oder von der Art der Engine abhängt. Die zu prüfende Hypothese lautet aber immer, sind die Abweichungen der Mitttelwerte zweier Stichproben zufällig, oder mit hoher Wahrscheinlichkeit nicht zufällig. Das gilt auch für die Lösung einer Aufgabensammlung. Das dies alles nichts mit der Spielstärke zu tun hat, zeigt wohl die Erfahrung, dass Stockfish immer noch in jedem Turnier die Nummer eins ist, beim Lösen von Schachaufgaben aber längst nicht immer.
VG Dieter :->

By Peter Martan Date 2024-02-06 23:17 Edited 2024-02-06 23:52

Dieter Brandhorst schrieb:

Um dir ein relevanteren Eindruck über die Varianz einer Engine zu machen solltest du mindestens 5 bis 6 Runs mit einer Engine machen, nicht nur 2.

Das kommt eben auch schon drauf an, was du unter Varianz verstehst. Was sie im statistischen Zusammenhang des Tests bedeutet, dafür brauchst du zusätzliche Angaben.

Zitat:

Das was ich gemacht habe ist kein Hexenwerk, sondern eine ganz normale und obligatorische wissenschaftliche Herangehensweise bei dem Vergleich zweier Stichproben und deren zugrunde liegenden Grundgesamtheiten. Natürlich spielt hier die Frage eine Rolle, ob es zwischen den Engines relevante Unterschiede bei der Lösung von Schachaufgaben gibt und inwieweit das von der Hardware und/oder von der Art der Engine abhängt. Die zu prüfende Hypothese lautet aber immer, sind die Abweichungen der Mitttelwerte zweier Stichproben zufällig, oder mit hoher Wahrscheinlichkeit nicht zufällig.

Das was du gemacht hast, ist einzelne Zahlenwerte zu ermitteln, was sie für eine statische Relevanz für die Fragestellung haben, darauf gehst du in keiner Weise ein, weder wissenschaftlich noch sonst irgendwie.
Was gibtst du denn in deinen t-Test ein, wenn du den als Alternative zur Eloformel eingangs überlegt hast?

Die Abweichung einzelner Messwerte von einem Mittelwert ohne Ansicht einer Verteilungskurve, das ist kein t-Test, das ist keine Alternative zur Eloformel, das ist nichts anderes als Durchschnittsrechnung. Was sagt dir das über die Wahrscheinlichkeit aus, mit der dein nächster Versuch wenigstens so ähnlich verlaufen wird, selbst unter genau gleichen Bedingungen? Wie groß der Einfluss des Zufalls gewesen ist und wie groß er beim nächsten Mal zu erwarten ist?

Du hast zum Schluss des einen Tests ein Durchschnittsergebnis und es ist mit keinem anderen solchen anders als anhand genau der Zahlen des ersten vergleichbar, du kannst ihn nur genau so wiederholen, wie du es schon gemacht hast und daraus ableiten, wie sehr er abweicht.

Schon gar nicht mehr als das kannst du vergleichen, wenn du eine einzelne Engine dazu nimmst oder weglässt, ohne wieder alle Messwerte von vorher neu in deine statistische Berechnung einzubeziehen, schon gar nicht. Drum brauchst du von jedem einzelnen Test eine Aussage über die Wahrscheinlichkeit, mit der die Ergebnisse innerhalb von Signifikanz- Intervallen liegen, über die du dir in dem Fall klar werden musst, dass du eben nicht nur einzelne Runs einzeln vergleichst, sondern verschiedene Kollektive von Engines , möglichst auch noch unter verschiedenen Stellungs- und Hardwarezeit- Bedingungen.

Ein Beispiel, das dir den Unterschied zwischen dem, was du machst, und dem, was man einfachster Weise machen könnte (und müsste, egal mit welchen Maßzahlen, wenn man error bars haben wollte, Elo sind ja beim EloStat- Tool auch gar nicht das einzige Maß, die Prozent- Performance wird auch angegeben, anderes Maß, andere error bar, aber jedenfalls auch zum Zwecke der Vergleichszahlen, die über das reine Abzählen der Punkte oder Lösungen hinaus geht).

Die Shredder- Tabellen aus meinem obigen 66 zu 69 2-run Beispiel so übereinander gelegt, dass du die gleichen Spalten direkt untereinander hast und leicht die Zeiten Stellung für Stellung vergleichen kannst:

Dann die Stellungen, die im einen run relativ zum anderen gewonnen wurden und die verlorenen und die Remis in EloStat eingegeben:

Wins   = 20
Draws  = 80
Losses = 14
Av.Op. Elo = 3500

Result     : 60.0/114 (+20,=80,-14)
Perf.      : 52.6 %
Margins    :
 68 %      : (+  2.5,-  2.5 %) -> [ 50.1, 55.2 %]
 95 %      : (+  5.0,-  5.0 %) -> [ 47.7, 57.6 %]
 99.7 %    : (+  7.6,-  7.5 %) -> [ 45.1, 60.2 %]

Elo        : 3518
Margins    :
 68 %      : (+ 18,- 18) -> [3501,3536]
 95 %      : (+ 35,- 35) -> [3484,3553]
 99.7 %    : (+ 54,- 52) -> [3466,3572]

Da hast du jetzt alles, was du brauchst, um diesen einen Test mit diesen beiden runs in seiner statistischen Relevanz einzusortieren und den kannst du jetzt mit beliebig vielen anderen runs derselben Engine und mit beliebig vielen von anderen Engines vergleichen.

Und nein, es ist nicht die einzige Methode, aber es ist für mich die einfachste (wenn's mir nicht ohnehin EloStatTS automatisiert abnimmt, was aber halt nur aus einer Fritz- .cbh heraus geht oder mir aus einer MEA- Auswertung das Tool von Frank Sanders auch automatisiert anbietet), deine ist für mich keine vergleichbare.
Du zählst die Unterschiede an Lösungszahlen und vergleichst sie mit denen anderer Runs und den Mittelwerten.

Mit statistischen Methoden wie einem t-Test (den ja du als Alternative zur Eloformel vorgeschlagen hast, nicht ich) hat das, was du tust, nichts zu tun, du kannst so keine 2 verschiedene Tests (seien sie auch noch so sehr ähnlicher Art) miteinander vergleichen, und du kannst auch vom einzelnen Test, und umfasst er noch so viele noch so schachlich relevante Stellungen mit noch so guter Hardware- TC, auch vom einzelnen Test kannst du keine Aussagen über die Einsortierung der Zahlenwerte, die du ermittelst, in ihrer statistischen Relevanz treffen durch bloßes Abzählen und Bestimmung einer Mittelwert- Abweichung. Das trägt dem keine Rechnung, was die einzelne Stellung relativ zu den anderen Stellungen im direkten Engine- Engine- Vergleich bedeutet. Nicht einmal statistisch, geschweige denn schachlich. Die schachliche Aussage wird nicht dadurch besser, dass man die Ergebnisse in Elo ausrechnet, sondern dadurch, dass man im direkten Engine- Engine- Vergleich bewertet.

Oder sag' mir halt einfach, was deine Zahlenwerte für Signifikanzintervallle in ihrer Wahrscheinlichkeit haben, mehr oder weniger vom Zufall oder mehr oder weniger von der Engine- Performance selbst abzuhängen?
Sagen wir wie allgemein üblich und wie z.B. auch bei Elostat berechnet, in einem 68 und einem 95%- Intervall?
Wie groß ist die Wahrscheinlichkeit, dass die Zahlen, die du raus bekommst, mehr oder weniger Zufall oder mehr oder weniger Engine- Performance sind. Welcher Art von Performance auch immer, taktisch, positionell, wie auch immer man das dann noch klingend nennen will, das ist auch völlig schnurzpiep, ich bin völlig zufrieden, wenn ich weiß, von welcher Suite unter welchen Hardware- Zeit- Bedingungen sie erspielt wurden, aber wenn ich nicht wenigstens diese Art der statistischen Bewertung habe, kann ich gar nichts untereinander vergleichen, jedenfalls nicht besser sondern schlechter als ich es anhand einer einzelnen Stellung kann. Mit der kann ich mich auch immer wieder zufrieden geben, da genügt es mir auch zu sehen, wie stark die SMP- Streuung einzelner Versuche ist, aber mit Statistik im eigentlichen Sinn hat das eben just nix zu tun.

By Dieter Brandhorst Date 2024-02-06 23:58

Also, ich habe nie behauptet einen Student- t- Test angewendet zu haben, dem eine Normalverteilung zugrunde legt. Ich habe einen verteilungsfreien Rangsummentest den "Mann-Whitney-U-Test" angewendet. Dieser nichtparametrische Test wird verwendet, um zu beurteilen, ob zwei unabhängige Stichproben aus derselben Population stammen oder ob Unterschiede in den Medianen der Populationen bestehen, aus denen die Stichproben gezogen wurden. Er ist besonders nützlich, wenn die Voraussetzungen für den t-Test nicht erfüllt sind, etwa bei nicht normalverteilten Daten oder wenn die Stichprobengrößen klein sind.
Die einfache und zweifache Standardabweichung der Mittelwerte geben ja genau das, was du als Fehlerbalken bezeichnest an. Plusminus 1SD (68,27%) und plusminus 2SD (95,45) und plusminus 3SD(99,7%). Die 2 fache SD habe ich ja in meiner Tabelle weiter oben angegeben. Allerdings setzt dies, genauso wie die Eloberechnung eine symmetrische Normalverteilung der Werte voraus.
Ich werde morgen einmal die Abbildungen mit Fehlerbalken und die zugehörigen Wahrscheinlichkeiten meiner Tests mitteilen, ist mir jetzt zu spät. Übrigens sind die Fehlerbalken der Elozahlen nichts anderes als die Standardabweichungen der errechneten Elozahlen.

By Peter Martan Date 2024-02-07 00:23 Edited 2024-02-07 00:44

Lass gut sein, Dieter, anscheinend hab' ich deine Auswertungen zu wenig gewürdigt, sehe aber auch beim nochmals Durschauen nirgends eine Erwähnung dessen, was du da statistisch alles veranstaltet hast außer Mittelwerte und Standardabweichung einzutragen.
Jetzt interessiert mich dann (am Rande) nur noch, wo dann der Vorteil deiner Methode relativ zur ja doch nach wie vor um einiges gängigeren der Auswertung mit einem Elostat- Tool ist, wenn du doch auch wieder ähnliche statistische Methoden für notwendig hältst.

Die Kernfrage, wieviel Zufalls- Streuung und wieviel statistische Signifikanz du mit welcher Suite und welcher Hardware- TC bei welchen Engines erreichst, steht hingegen so und so nach wie vor im Raum. Falls ich dahingehend missverständlich war, dass mir die statistische Auswertung einer Suite wichtiger sei als die Suite selbst, so ist's natürlich nicht.

Falls wir dieser Kernfrage dann jetzt doch endlich noch einmal wieder etwas näher treten wollen: keine einzelne noch so gute Suite sagt soviel wie mehrere gute gemeinsam sagen, die man jeweils in der für sie (und die Engines) passenden TC laufen lässt, das wieder sagt auf jeden Fall mehr, als alle Teststellungen, deren man habhaft wird, in eine gemeinsame Suite zu packen und die dann über einen gemeinsamen Hardware- TC- Kamm zu scheren, damit erreicht man bei aller statistischen Genauigkeit nicht mehr als mit dem Versuch vom Eiswasser und dem kochenden solchen, in das man je eine Hand taucht, um eine statistisch angenehme Durchschnittstemperatur zu erreichen

Und jede Suite ist so gut wie die Stellungen, die drin sind, und wie sie an Thematik und "Schwierigkeit" (im Wesentlichen Hardware- Zeit zur Lösung) zusammenpassen.
Die alte HTC114 ist nach wie vor eine der guten für mich, für die heutigen Spitzenengines gibt sie mir relativ zu ähnlichen, die ich für mich persönlich draus und aus anderen gebaut habe, mittlerweile zu wenig Mischung aus Selektivität und Sensitivität her oder anders ausgedrückt, zu wenig Homogenität, und ich kann's halt eigentlich wieder nicht anders als statistisch formulieren, sie hat mir zu wenig Signifikanz, zu wenig Diskrimination relativ zu den error bars von Engine zu Engine, da hab' ich einfach für das, was mir wichtig ist, Besseres sowohl dieser taktischen single best move- Art als auch anderer Arten. Das Ganze ist immer auch eine Frage von wieviel Aussage bekommt man mit welchem Gesamt- Hardwarezeitaufwand.

Für die besten allein ist sie (die HTC114) im Schnitt auch schon zu leicht (was sich aber eben durch einfach kürzere TC allein auch nicht ausgleichen lässt, das geht z.B. beim Eret noch eher, obwohl oder gerade weil der im Schnitt noch etwas leichter ist, aber halt homogener), weil dann bei ihr wieder die Lösungszahlen relativ zur Gesamtzahl zu stark sinken und die Zufallsstreuung von run zu run zu viel relative Rolle spielt, darüber wenigstens sind wir uns ja, denke ich, doch irgendwie einig geworden, und für ein breiteres Teilnehmerfeld sind die notwendigen TC- Ranges zu eng, um die ganz oben mit denen ganz unten in einer gemeinsamen TC zu haben und daraus eine Liste zu machen.
Das ist hingegen auch wieder so ein wesentlicher Vorteil von EloStatTS: du kannst (in bestimmten Grenzen) durchaus auch verschiedene TCs für verschiedene Engines derselben Suite nehmen, die besser abschneidenden Engines machen den Zeitnachteil der Vorgabe durch die Auswertung der genauen Lösezeiten immer wieder mehr als wett.
Und es kommt auch immer wieder vor, dass Engines mit einigen wenigen Lösungen weniger besser im Gesamtscore abschneiden, weil sie die direkt Eng-Eng-verglichenen besseren Zeit- Indices haben.
Und jetzt endlich wieder genug für jetzt, aber es ist das halt immer wieder eins dieser Themen für mich, bei denen ich ins Plaudern komme

By Dieter Brandhorst Date 2024-02-07 09:51 Edited 2024-02-07 09:56

"Das ist hingegen auch wieder so ein wesentlicher Vorteil von EloStatTS: du kannst (in bestimmten Grenzen) durchaus auch verschiedene TCs für verschiedene Engines derselben Suite nehmen, die besser abschneidenden Engines machen den Zeitnachteil der Vorgabe durch die Auswertung der genauen Lösezeiten immer wieder mehr als wett."

Lieber Peter,

ElostatTS vergleicht primär Lösungszeiten! Es generiert daraus Elozahlen in dem es den Vergleich aller Engines untereinander wie ein Schachturnier, Jeder gegen Jeden, betrachtet. Die Lösungszeiten der Programme bilden dabei die Grundlage für den "Spielausgang" 1, 0 oder 1/2. Ich hoffe bis hierhin sind wir uns einig.

Schauen wir uns doch jetzt bitte einmal die beiden Runs etwas genauer an, die du gestern selbst generiert und gepostet hast.

In Run2 benötigt Stockfish für die Aufgabe 99 ganze 10 Sekunden und in Run1 nur 1 Sekunde. Ein Unterschied von Faktor 10! Wie kann das sein? Das nenne ich mal Varianz. Aufgabe 2: 6 gegen 3 Sekunden, Aufgabe 3: nur in Run1 gelöst, Aufgabe6: 1 gegen 0 Sek, Aufgabe 8: nur in Run2 gelöst, usw. Welche dieser Lösungszeiten von Stockfish möchtest du denn für die Elostatauswertung und zum Vergleich mit anderen Engines heranziehen? Dabei tritt die wahre Bandbreite der Lösungszeiten einer Engine sicherlich noch nicht in 2 Runs in Erscheinung, das müssten schon mehr sein. Die Lösungszeiten einer Engine über mehrere Runs für jede Aufgabe zu mitteln und erst dann in ElostatTS einzubringen, erscheint mir dringend erforderlich.
Für jede Engine lediglich die Lösungszeiten eines Runs in einen Vergleich einzubringen grenzt m.E. eher an Würfeln.

VG Dieter

By Peter Martan Date 2024-02-07 10:17 Edited 2024-02-07 10:49

Du schilderst ganz richtig, dass EloStatTS die Stellungen einzeln als Minimatches zwischen je 2 Engines bewertet und dazu auch die genauen Lösezeiten heranzieht, das scheint mir aber halt auch genau das, was dem reinen Zählen von Lösungen abgeht.
Dass die Zeit, die die Engine braucht, auch bei allen anderen Methoden, Suiten automatisch ablaufen zu lassen, ein oder das wesentliche Kriterium ist, macht nicht den großen Unterschied bei EloStatTS (oder dem Tool von Frank Sanders, das das auch so in WDL umrechnen lässt), aber dass es auf diese Art (mit dem genauen Lösungszeitvergleich) noch einmal um das weniger "Remis" werden, was an gemeinsam gelösten Stellungen noch durch unterschiedliche Zeiten (oder bei MEA Punkte) in ganze Punkte verwandelt wird, das macht schon einen Unterschied im Endergebnis.

Und ja, die Streuung ist immer wieder bei der einzelnen Stellung beachtlich, aber das liegt natürlich auch wieder an den Stellungen. Und du könntest, wenn du die TC daran anpasst, natürlich bei A-B durch single thread da viel dagegen halten, drum hat Vincent Lejeune ja ursprünglich 30 Minuten single thread verglichen in der Liste, die er lange geführt hat.

Wie oft du den einzelnen Run ansonsten wiederholen willst, um die Streuung mit einzurechnen, ist Geschmackssache, ich gebe nur neuerlich zu bedenken, dass eben jeder einzelne neue Run von EloStatTS wieder genauer aufgeschlüsselt wird, dass es wieder nicht nur das Zählen der Lösungen ist, sondern WDL (damit auch der Elo- Berechnung beim game playing besser vergleichbar) und dass nicht nur die Wiederholungen mit derselben Engine genauer eingehen, sondern dass auch mit jeder neuen Engine, die dazu kommt, die alten Runs wieder neu einzeln Stellung um Stellung verglichen werden, dein Datenstock wächst also nicht nur um einen Run, sondern um alle Minimatches, die alle jedes Mal wieder neu aufgesetzt werden.

Es spricht für mich halt insgesamt schon viel für EloStatTS, schade, dass es nur mit Fritz funktioniert und dass man Fritz nicht in mehreren Instanzen in eine gemeinsame .cbh schreiben lassen kann, (oder mehrere, die vom selben Stand ausgehen, zum Schluss verschmolzen, auch funktionieren, hab's probiert, geht leider nicht mit MEA, sodass die Ergebnisse stimmen) auch dass keine kürzere TCs als 1" möglich ist, stört ein bisschen heutzutage.

Was relativ zu MEA dann noch fehlt, ist die Möglichkeit, mehr als einen einzelnen single best move von Stellungen mit mehreren ähnlich guten Abspielen bewerten zu lassen vom GUI. Mehrere unkommentierte Alternativzüge werden ohnehin alle als bm beurteilt (im .epd- String kann man ja auch beliebig viele hinter der bm- Syntax eintragen) aber eine Unterscheidung nach einer Art Punktesystem, das wäre schon noch ein paar Nummern besser.
Dabei bräuchte es auch da gar nicht soo viel GUI- Aufrüstung: das ? gilt ohnehin für den am, das ?!, !?, ! und eventuell noch das !! wären schon 4 weitere Stufen, dazu noch das jetzt schon gültige vorangestellte = (äquivalent ist) und dann vor allem noch die Hierarchie, in der man die Varianten in den Baum eintragen könnte (was im Fritz halt auch nicht so klappt wie z.B. im Shredder) das wäre in Summe schon mehr als genug an Punkte- Äquivalenten, mehr als 5, höchstens mal 6 Alternativzüge gebe ich in MEA praktisch auch nie ein. Stellungen, die noch mehr ähnlich gute Abspiele haben, eignen sich halt doch nicht so gut als Teststellungen für die Suite wie weniger mulitple Lösungen, single best move hingegen schränkt stark ein, macht heutzutage die Auswahl schon ziemlich automatisch praxisferner, man muss mehr und mehr auf die komponierten Studien zurückgreifen, wenn man Stellungen sucht, die von den besten Engines bei einzelnen forcierten Abspielen nicht im Handumdrehen gelöst werden, und dann gebe ich auch bei der Gelegenheit immer wieder zu bedenken, dass die Stellungen mit einzelnen forcierten Abspielen ja insgesamt eigentlich die "leichteren" sind, relativ zu einer Eröffnungsstellung mit einer breiten Palette von ähnlich bis gleich starken Alternativzügen und einem auch unmittelbar danach viel breiter auffächernden Spielbaum an zu bewertenden Blattstellungen.

Jedenfalls gäbe es noch Vieles, was man sich wünschen könnte, das Umrechnen in (besser gesagt einfach das Zählen als) WDL ist mir nicht wegen der Elo so wichtig, wobei ich das Maß als solches, wenn man jetzt schon im ganzen übrigen Schach nach wie vor damit rechnet in den verschiedensten Sparten (und da gibt's wirklich gewaltige Unterschiede mittlerweile, seit das Computerschach das der Menschen so dominiert, aber auch schon allein beim Menschen sind es praktisch verschiedene Sportarten, daher auch eigene Rankings und Ratings, die Turnier- TC, Schnellschach, Blitz und Bullet hergeben), das Maß als solches finde ich einfach Elo für die Stellungstests um nichts schlechter als ein anderes Maß, wie gesagt, man hat auch wenigstens schon die automatisierten Tools dafür und statistisch relativieren muss man die Ergebnisse sowieso auch, wenn man mehr als 2 Engines oder runs miteinander vergleichen will, und (was man beim Stellungstest ja sowieso auch muss) mehr als eine Suite und mehr als eine TC.

Halte uns auf dem Laufenden, was du weiter an Erkenntnissen fasst, Dieter, eine etwas breitere Liste von Engines würde mich mal interessieren, vor allem auch, weil da halt EloStatTS (Fritz, weil dass da in der einen .cbh beliebig viele Runs so genau Engine für Engine gespeichert wird, das ist ja wieder ein Alleinstellungsmerkmal von diesem GUI, EloStatTS geht dann nur davon aus, was es da an Kommentaren vorfindet) schon auch eine Speicher- und Darstellungsart bietet, die ihrer Art sucht. Dass die error bar mit der Zahl der runs automatisch immer weiter sinkt (umso mehr, je mehr Engines, die starke Performance haben, weil sie mehr Matches bringen als die Engines mit weniger Lösungen insgesamt), das müsste schon auch ganz stark in deinem Sinn sein.

Edit, ich finde einfach kein Ende: was du noch bedenken müsstest, wenn du jetzt jede Engine mit mehreren runs mit anderen vergleichst, zählt es umso mehr, welche Engines mit welchen verglichen werden, weil außer dem Kriterium der Performance im einzelnen run auch noch das der größeren oder kleineren Varianz zwischen den runs dazu kommt. Eine Engine mit weniger Streuung punktet dann anders als eine mit mehr, bei den schwächeren wirst du vermutlich mehr Streuung haben, sie wird jedenfalls automatisch relativ zu den Lösungszahlen mehr ausmachen, wenn du da nicht wie mit EloStatTS jeden wiederholten run auch mit allen anderen gemeinsam neu berechnen lässt, bekommst du automatisch mehr Differenzen zwischen den Ergebnissen verschiedener Listen. Single thread und SMP macht automatisch mehr Unterschied, A-B und NN vermutlich auch, single thread wie bei A-B gibts bei Lc0- artigen Engines praktisch gar nicht, du hast auch noch MCTS erwähnt...

By Torsten Cuber Date 2024-02-06 21:34 Edited 2024-02-06 21:36

"Mit der Umrechnung der Testergebnisse auf Elo-Werte halte ich gar nichts; das ist doch Quatsch.

Die Elo-Werte kommen hauptsächlich aus dem positionellen praktischen Spiel.

Stellungstest zeigen die taktische Stärke."

Lieber Reinhold,
da stimme ich dir absolut zu, deswegen betone ich ja immer wieder, daß ich mit meinen Tests keinerlei Aussagen treffe über die"praktische Spielstärke", sondern dass es mir nur darum geht, herauszufinden, welche Engine für die Analyse am besten geeignet ist.
Analyse ist ja nichts anderes als die Suche nach Fehlern.
Und genau dafür ist die taktische Spielstärke so entscheidend.
Liebe Grüße vom Torsten

By Peter Martan Date 2024-02-06 21:54

Ihr wollt das hier alle mit Gewalt nicht verstehen, dass ich die Elo für die einfachste Methode halte, einen statistischen Aussagewert zu bekommen, weil's da noch und noch Tools gibt, die daraus auch eine error bar ausrechnen.
Ob du die direkt aus den Lösungszahlen errechnest oder aus Performance- Prozenten oder Zentimeter oder Kilogramm, ist schnurzpiep, und du musst dich natürlich auch nicht für deine eigenen Interessen allein darum kümmern, wie das eine deiner ureigenen Ergebnisse mit dem beliebigen anderen deiner ebenfalls ureigenen korrelliert, aber wenn's dich halt nunmal interessiert (könnte doch sein, nein?), was spricht dann dagegen, dasselbe übliche Maß zu verwenden wie im ganzen übrigen Schach?
Regt sich ja auch keiner drüber auf, dass sich die menschlichen Schachspieler auch immer noch erfrechen, ihre Spielstärke in Elo zu messen, oder?

Wenn man nicht imstande ist, Elo aus dem einen Match oder Turnier zu denen aus einem anderen zu relativieren, wenigstens bei Menschen zu unterscheiden zwischen denen einer Turnierperformance, einer Jahresperformance, einer ewigen Bestenliste, was auch immer es da noch und noch für völlig verschiedene Elo gibt, muss er sich das mit dieser Maßzahl halt überhaupt endlich abschminken.
Ist doch wirklich wahr, immer diese völlig unnötige Korinthenkackerei, um mal wieder einen Ausdruck aus dem Schweizerdeutsch zu nehmen

By Kurt Utzinger Date 2024-02-06 23:10

Peter Martan schrieb:

[...]
Ist doch wirklich wahr, immer diese völlig unnötige Korinthenkackerei, um mal wieder einen Ausdruck aus dem Schweizerdeutsch zu nehmen

Hallo Peter
Der Ausdruck KORINTHENKACKER ist mir als Deutschweizer unbekannt. Wir kennen
dafür folgende Wörter: Tüpflischisser und/oder Pünktlischiesser
Gruss
Kurt

By Peter Martan Date 2024-02-06 23:28

Entschuldige, Kurt, du hast völlig recht, der Korinthenkacker ist nicht in der Schweiz zu Hause sondern in Deutschland (in Österreich sagen wir auch anders, ich will jetzt lieber gar keine Alternativ- Ausdrücke aus dem näheren dialektischen Umfeld bringen, die mir einfallen, wären alle noch etwas ordinärer, was aber auch nicht unbedingt etwas nur Abfälliges allein haben muss, ist ordinär doch primär einfach das, was einem gewöhnlich scheint), was ich meinte, war der Tüpflischisser.
Auch ein viel netterer Ausdruck als der von mir fälschlich verwendete, finde ich

By Reinhold Stibi Date 2024-02-06 23:28 Edited 2024-02-06 23:32

Peter, die error bar kein mir den Buckel runterrutschen.

Die Bewertungen der Teststellungen kann nicht in Elo ausgewertet werden weil
die Statistik nur Zahlen kennt aber nicht den Wert einer einzelnen Stellung.
Da zählt eine relativ einfache Stellung genauso viel wie eine ganz schwierige.

Es gibt besondere Stellungen deren Lösung natürlich viel mehr zählt als
eine Durchschnittliche.
Es zählt also nicht nur die Menge sondern auch die Qualität/Inhalt und das kann
die error bar nicht bringen.

Darum ist eine Berechnung nach Elo bei Teststellungen Quatsch.

By Peter Martan Date 2024-02-06 23:36

Und also schließt er messerscharf, dass nicht sein kann, was nicht sein darf.

Weißt du, Reinhold, es ist mir ja eigentlich wirklich ziemlich schnurzpiepegal, worin du deine, sie ihre, er seine Ergebnisse angibt, ich hätte dafür halt gern für mich persönlich dann auch wenigstens das Recht, meine ihrerseits so anzugeben, wie ich's für richtig halte, dann nämlich halt, um es noch einmal zu betonen, wenn es sich um meine Ergebnisse handelt.

Wenn jemand dieses und jenes auf seine Art machen will und dabei niemandem etwas wegnimmt, bin ich immer auf dessen oder deren Seite bis zu dem Moment an, wo er sie es mir Vorschriften darüber machen will, ich ich's zu machen habe oder gar auf welche Art ich's nicht machen dürfe. Wie gesagt immer vorausgesetzt, ich füge dabei auch niemandem Schaden zu

By Reinhold Stibi Date 2024-02-06 23:45

Peter, man darf doch verschiedener Meinung sein.

Wenn dir die Erro Bar bei Teststellungen gefällt, ist doch gut. Ich finde sie halt
bei Teststellungen nicht angebracht und zu wenig aussagekräftig.
Im praktischen Spiel gibt es nichts besseres.

Reinhold

By Lothar Jung Date 2024-02-09 08:25 Upvotes 1

Bei LC0 BT4 5000000 mit RTX 4070ti streut die HTC 114 Lösungsanzahl bei 30 sec. zwischen 86 und 89.
Es sind jedoch immer die gleichen Positionen, die nicht gelöst werden.
Es liegt meist daran, das LC0 eine „zweitbeste“ Lösung wählt, die aber auch zum Gewinn führt.
Bei kleineren Netze ergibt sich aufgrund der höheren KN/sec. aber geringere Policy eine andere Lösungsstruktur.
Eigentlich sind Tests zwischen unterschiedlichen Netzen nicht direkt vergleichbar.

By Max Siegfried Date 2024-02-28 17:44

Dieter Brandhorst schrieb:

Man kann aber man muss nicht.
Je leichter eine Testsuite, desto stärker die Schwankungen bei der Gesamtanzahl der gelösten Aufgaben. Wenn die Engine an 100 von 111 Aufgaben knapp scheitert, dann kann sie theoretisch schon beim zweiten Versuch diese 100 Aufgaben knapp lösen.

Verwende eine sehr schwere Testsuite bei langer Bedenkzeit, dann hast du kaum Schwankungen.
File name : Top Chess Engines Testsuite 2024 v2.pgn
Total test items   : 115
Test for    : best moves
Total engines : 1
Timer : movetime: 60
Expand ply    : 1
Elapsed : 1:05:44
Laps    : 1
Total tests : 115
Total corrects    : 17 (14%)
Ave correct elapse : 00:16
Status    : completed

Correct/Total:
Lc0 v0.31.0-dev+git.unknown: 17/115

Failed tests (hit *):
1. Lc0 v0.31.0-dev+git.unknown:
1, 2, 3, 5, 6, 7, 9, 10, 11, 13, 14, 15, 16, 17, 19, 20, 21, 22, 23, 24, 26, 27, 28, 29, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 47, 49, 50, 51, 52, 53, 54, 56, 57, 59, 60, 61, 62, 64, 65, 66, 67, 68, 69, 71, 72, 73, 75, 76, 77, 78, 79, 82, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114

Successful tests:
1. Lc0 v0.31.0-dev+git.unknown:
0, 4, 8, 12, 18, 25, 30, 46, 48, 55, 58, 63, 70, 74, 80, 81, 83

By Dieter Brandhorst Date 2024-02-09 10:56

Lieber Peter,

trotzdem beruhen Elostat und ElostatTS usw. in erster Linie auf Vorhersagen und Annahmen, von denen man einfach nicht weiß ob sie stimmen, also Spekulation!
Es wird versucht einen mögliches Partieergebnis zwischen 2 Engines vorherzusagen, so als hätten sie die zu lösende Stellung gegeneinander ausgespielt. Aus diesen Vorhersagen errechnet man eine Elozahl. Grundlage für die Vorhersage sind die Lösungsergebnisse und Lösungszeiten für die Aufgaben.
Mit der Richtigkeit dieser Vorhersagen steht und fällt alles! Was bei dieser Vorgehensweise sofort ins Auge fällt und sicher falsch ist, ist anzunehmen, das man eine von beiden Engines nicht gelöste Aufgabe eines Stellungstests als remis werten kann. Wie bitte kann man aus dem Fakt, das beide Engines eine bestimmte Aufgabe nicht lösen können, ableiten sie würden beim Ausspielen dieser Stellung gegeneinander Remis spielen? Das ist Astrologie.
Die Lösungszeiten mit einzubeziehen, ist ebenfalls wage. Das ginge sowieso nur single thread, da ansonsten die Streuungen der individuellen Lösungszeiten zu hoch sind.
Einer von vielen Gründen für bessere Lösungszeiten einer Engine gegenüber einer anderen, ist sicher die Selektivität bei der Suche. Er werden durch höhere Selektivität weniger Varianten berechnet und somit die Lösung schneller gefunden. Das kann aber beim Ausspielen der Stellung aber genau den gegenteiligen Effekt haben. Durch hohe Selektivität wird zwar die Anfangslösung schneller gefunden, aber beim Ausspielen der Stellung werden zu viele Fehler aufgrund der hohen Selektivität und Übersehen gemacht. Das ist m.E. auch nicht zielführend.

VG Dieter

By Peter Martan Date 2024-02-09 11:20 Edited 2024-02-09 11:26

Dieter Brandhorst schrieb:

Nein.
Man bewertet einfach die einen Stellungen als gewonnen, wenn sie nur von einer Engine im jeweils einzelnen Vergleichsrun gelöst werden, und es müssen ja absolut keine single winning game changer sein. Auch so ein weit verbreiteter Irrtum, Stellungstest wäre gleichbedeutend mit Test von single best moves, die die einzigen sein müssen, die den Ausgang der Partie relativ zu allen anderen zwingend verändern, das ist die engste Definition aber bei Weitem nicht die einzig mögliche, und es sind bei Weitem nicht die einzig interessanten Stellungen, im Gegenteil sind es die Ausnahmen und in Partien kommen sie in der Regel nur bei Schlagzügen vor oder wenn der König im Schach steht, von diesen single game changers sind hingegen wieder weitaus die meisten trivial in ihrer "Lösung", heutzutage noch echte unanzweifelbare single game changer zu finden, die nicht sofort von allen Engines gelöst werden, zwingt mehr und mehr zu Stellungen in der Auswahl, die eben beim normalen Eng-Eng-Match nicht aufs Brett kommen und damit auch meistens irgendwie praxisferner sind, man muss mehr und mehr auf die komponierten anti- engine- puzzles zurückgreifen, gegen die man natürlich auch immer einwenden kann und muss, dass sie mit dem game playing weniger zu tun haben).
Die Stellungen, die von beiden Engines innerhalb deiner (zwangsläufig willkürlich gewählten) Zeitvorgabe im Vergleichsrun gelöst werden, kannst du alle als Remis werten, als ganze Punkte kannst du sie für die Seite werten, die's schneller findet, oder du kannst das lassen, du hast recht, dass das eine Willkür ist, das andere aber auch, du findest dich dann einfach mit einer höheren Remisrate ab und brauchst einfach, um wieder gleich große Performance- Unterschiede zu bekommen, mehr und oder selektivere Stellungen. Nimmst du zuviele zu selektive für die Hardware- TC und die Engines, bekommst du zwangsläufig dadurch wieder mehr Remis (du musst sie nicht so nennen, aber wie auch immer du sie nennst, sie zählen statistisch als solche).
Mach dich von dem Gedanken frei, dass du mit Stellungstests dieselben Ergebnisse wie im game playing bekommen musst, wenn das dein einziges Intersse ist, warum dann überhaupt? Ums game playing als zusätzliches Spielstärke- Kriterium wirst du ja sowieso nicht herumkommen und auch bei dem musst du die Ergebnisse relativieren nach den prinzipiell selben Kriterien wie beim Stellungstest, nach Wahl der (Eröffnungs-) Stellungen, Hardware- TC und Zahl und Art der Engines.
Ich kann dir wirklich nicht mehr helfen, als dir noch und noch Möglichkeiten anbieten, wie du Stellungstests statistisch signifikanter, reproduzierbarer und in sich stimmiger machen kannst, außer halt wie gesagt, interaktiv für jede einzelne Stellung für sich.
Überleg' dir mal, was du bei diesem völlig deinem persönlichen Vorgehen überlassenen interaktiven Stellungstest für die relevanten Stellungen und für die relevanten Messwerte hältst und wie du sie ermitteln würdest, und dementsprechend wähle dann für die Suiten (wenn du die überhaupt auch laufen lassen willst) die Vorgaben und die Tools, wie's dir am besten zusagt. Dann bekommst du die Ergebnisse, die dich am meisten interessieren, dass sie mehr oder weniger aber jedenfalls immer für sich allein stehen werden, damit musst du leben. Das eine Eng-Eng-Match, das dir alle Fragen beantwortet, die du an schachliche Leistungen von Menschen und Maschinen haben könntest, wirst du auch nicht leicht finden.
So what?

By Peter Martan Date 2024-02-13 07:13 Edited 2024-02-13 07:18

Peter Martan schrieb:

so sähe dann eine Liste von 5 Engines bzw. deren Versionen aus, wenn jede je 5 Runs (R2- R5 als Zusatz im sonst gleichen Namen) absolviert von 336 Stellungen in MEA- Syntax mit dem Tool von Frank Sanders in WDL umgerechnet.

Und hier dieselben 336 Stellungen mit 8 Engines (bwz. deren Versionen), wieder je 5 runs, 5"/pos., A-B wieder single thread, Lc0 auch auf derselben Hardware wie zuvor mit denselben beiden Netzen. Aber diesmal mit einem neuen Toool von Frank Sanders, das jetzt mit den Shredder- Protokolldateien statt den MEA- log- files arbeitet und statt der Punkte von MEA die Lösungs-Zeiten zum Aufschlüsseln der vom Eng-Eng-Paar gleichermaßen gelösten Stellungen verwendet, also sehr ähnlich EloStatTS. Der Hauptvorteil dem gegenüber hingegen, dass man die Shredder- files aus mehreren Concurrencies zum Schluss gemeinsam auswerten kann.
Die einzelnen Runs hab' ich diesmal nicht wieder jeden für sich gewertet, sondern jeweils als einen gesammelten Datenpool der einzelnen Engine zugeordnet, SC ist ShashChess:


   # PLAYER       :  RATING  ERROR  PLAYED     W     D     L   (%)  CFS(%)
   1 SF240101     :    3500   ----   11760  6773  1043  3944  62.0      97
   2 SF240203     :    3494      6   11760  6626  1133  4001  61.2     100
   3 SC34.6       :    3457      6   11760  5757  1519  4484  55.4      67
   4 SC34.5       :    3456      6   11760  5735  1512  4513  55.2     100
   5 Dragon3.3    :    3407      6   11760  4949  1245  5566  47.4     100
   6 Lc02815      :    3363      6   11760  4266  1016  6478  40.6      89
   7 Lc05000      :    3359      6   11760  4177  1053  6530  40.0     100
   8 Berserk12    :    3348      7   11760  3871  1251  6638  38.2     ---

Die 336 Stellungen, die ich jetzt, wenn ich mich zwischen 3en davon entschieden habe, welche ich drinlasse, auf 333 reduzieren werde, sind übrigens per Mail von mir zu haben, hochladen werde ich weiterhin nichts mehr, meine Suiten ändern sich laufend und dann müsste ich ständig die Links aktualisieren. Diese 336 sind übrigens zu einem sehr großen Teil ohnehin hinlänglich bekannt. 100 Eret, 190 Arasan 2021 und der Rest (für Engines) leichte Endspiel- Studien aus der HHdb.

By Lothar Jung Date 2024-02-13 07:48 Edited 2024-02-13 07:57 Upvotes 1

Die Einordnung von LC0 0.31rev. BT4 500000 gibt die Suite der Lächerlichkeit preis.
141 Elo Unterschied zu Stockfish ist absurd. Unglaublich!
https://tcec-chess.com/
Deine Ergebnisse sind nicht ernst zunehmen.

By Peter Martan Date 2024-02-13 07:51 Edited 2024-02-13 08:23

Dann ist's ja gut, dass es sich (wieder) nicht um 0.30 dev. (schon gar nicht um 0.30rev., wie du diesmal schriebst) sondern wieder um 0.31 dev. handelt.

SCNR
Übrigens gehe ich davon aus, dass mit STC- game- playing mit meiner 3070ti, würde ich mir wenigstens 2000 Partien head to head antun, (und mit TC meine ich wirklich time als Maß und nicht Knoten, wie in dem von dir zuletzt geposteten Test, in dem Knoten von Lc0 mit solchen von SF als Maß der "TC" verwendet wurde, das fand ich wirklich lustig

) durchaus auch das 2815M- Netz die Nase vorn haben könnte, in den meisten anderen Suiten, in denen ich's mit unterschiedlicher TC probiert habe, sind die beiden jedenfalls auch meistens (so wie hier) innerhalb der error bar beisammen.
Wenn du dann fertig bist mit Lachen (wozu die Preisgabe ja wohl hoffentlich wenigstens gut gewesen sein wird) hab' ich da ein Pendant mit denselben Engines und derselben Vorgangsweise und der für 15"/Stellung gedachten 128er- Suite, A-B mit je 8 Threads und Lc0 wieder mit denselben Netzen und der 3070ti:


   # PLAYER      :  RATING  ERROR  PLAYED     W     D     L   (%)  CFS(%)
   1 Lc05000M    :    3500   ----    3200  1091  1280   829  54.1      89
   2 Lc02815M    :    3493     11    3200  1050  1289   861  53.0     100
   3 SC34.6      :    3475     11    3200   876  1439   885  49.9      65
   4 SC34.5      :    3473     11    3200   880  1406   914  49.5      96
   5 SF240101    :    3463     11    3200   808  1446   946  47.8      99
   6 SF240203    :    3451     10    3200   730  1470  1000  45.8     ---

Auch hier kommen die beiden nicht aus der error bar gegeneinander, aber ich hab' mir gedacht, es freut dich sicher, wenn dein Schätzchen auch mal was anführt

Nein, im Ernst, es sind die Stellungen, die längere Hardware- TC brauchen, bei denen 8 Threads der guten A-B-Engines relativ weniger Hardware- TC sind als 5"/pos. single thread bei Eret und Arasan, und da wirkt sich dann das Ungleichgewicht in der "Leela- Ratio" indirekt proportional aus.
Nur zur verbalen interpretativen Einordnung, auf die es dir bei Suiten ja immer in erster Linie ankommt

Edit: ich sehe, du hast deine Tippfehler korrigiert, schade, dass ich sie nicht mit Zitieren verewigt habe, jetzt verstehst nur mehr du meinen ersten Satz und mein erstes Smiley.
Aber die Elo, die in deinem gestrigen Match auf der Seite von Lc0 rausgekommen sind, sodass anhand ihrer sogar SF im Ranking hinter beiden Lc0- Netzen gelandet ist, wirst du ja hoffentlich auch nicht für solche gehalten haben, die man irgendwelchen anderen vergleichen kann, oder? Ich meine, ernsthaft, Knotenzählung als gemeinsame "TC" im Match zwischen Lc0 und SF, geht's noch?

Und wer sagt dir überhaupt, dass das was bei diesen meinen jüngsten Listen unter Rating steht, Elo sind? Steht das irgendwo?

Sag einfach, wenn sie dir als Ergebnis nicht gefallen, Schmählo zu ihnen und bei der 128er- Liste, wo Lc0 führt, sagst du Elo, oder du lässt dir selber irgendwelche Ausdrücke einfallen, die dir schachlich verbal-interpretativ mehr sagen.

By Peter Martan Date 2024-02-13 15:06 Edited 2024-02-13 15:13

Zitat:

es sind die Stellungen, die längere Hardware- TC brauchen, bei denen 8 Threads der guten A-B-Engines relativ weniger Hardware- TC sind als 5"/pos. single thread bei Eret und Arasan, und da wirkt sich dann das Ungleichgewicht in der "Leela- Ratio" indirekt proportional aus.

Sollte heißen "bei denen 8 threads der A-B-Engines und 15"/pos. relativ weniger Hardware- TC sind als 5"/pos. single thread bei Eret und Arasan". Die 15" haben bei den 8 threads als Zeitanteil der Hardware- TC im zitierten Satz gefehlt.

Aber abgesehen von solchen Kriterien, die eben die gute oder schlechte TC für eine bestimmte Suite, eine bestimmte Hardware und bestimmte Engines ausmachen, zeigen die beiden Beispiele auch die Schwachstelle der neuen Auswertung, wenn man sie als solche sehen will, und nicht ohnehin jeden Test für sich allein nur mit möglichst großem Abstand von Diskrimination zu error bar haben will, weil sonst wär's ja direkt wieder eine Stärke:
Dass die von einem Engine- Paar innerhalb der TC gleichermaßen gelöste einzelne Stellung schon bei jedem messbaren Zeitvorteil als ganzer Punkt für die schnellere Seite gerechnet wird, ist dann überbewertet, wenn die Unterschiede in der Zeit minimal sind im Vergleich zur TC. Nun werden so kleine Unterschiede bei (für die Engines und die Hardware- Zeit) "leichten" Stellungen häufiger vorkommen als bei Stellungen, die allen Teilnehmern mehr Rechenzeit abverlangen, und sie werden als ganze Punkte dann in Summe relativ mehr zählen, wenn mehr Stellungen von mehr Engines gleichermaßen schnell, weit innerhalb der TC gelöst werden.
Ein einzelner Kontroll- Run zwischen SF dev. und Lc0 mit dem 5000M- Netz mit denselben Stellungen und derselben Hardware- TC mit EloStatTS ausgewertet, schaut so aus:

   Program                                    Elo   +/-  Matches  Score   Av.Op.   S.Pos.   MST1    MST2   RIndex

  1 Stockfishdev-20240203                    : 3510   10    317    52.7 %   3490   309/336    1.2s    1.5s   0.95
  2 Lc0v0.31.0-dag+git.a4877961-5000M        : 3490    9    317    47.3 %   3510   283/336    1.2s    1.8s   0.90

MST1  : Mean solution time (solved positions only)
MST2  : Mean solution time (solved and unsolved positions)
RIndex: Score according to solution time ranking for each position

Wenn man die so errechneten Elo überhaupt mit game playing Elo vergleichen will, ist der Abstand viel realistischer. Das ist in der Auswertung die feinere Klinge von EloStatTS, das eben nicht einfach nur die Minimatches an der absoluten Zeit adjudiziert, sonden komplexere Formeln zum Vergleich mit den anderen Zeit- Indices heranzieht.
Aber es stellt sich halt wieder mal die Frage: will man "nur" Ergebnisse, die denen bestimmter head to head matches möglichst nahe kommen, wozu dann überhaupt beides machen, das Eng-Eng- game playing match und den nicht ausgespielten Stellungstest?

Oder will man als Ergänzung und als Gegenstück zum game playing bestimmte Sonderleistungen (um sie nicht gleich wieder hochklingend "taktisch", "positionell", "aggressiv" oder "defensiv" zu nennen) eigens anhand von bestimmten Sonderstellungen in ein eigenes Ranking und vielleicht noch Rating einordnen. (Auch die UHO- Stellungen, die ich für MEA- Suiten verwende, selektiere ich danach weiter, wie groß die Anzahl ungefähr gleich starker Abspiele ist, wie sehr die unterscheidbar sind voneinander und ob sie im Gegenstück zur klassischen single best move Stellung eben auch nicht zu forciert sind.) Frank Sanders hingegen hat auch eine Mittelding- Liste dadurch erstellt, dass er STS- Stellungen ausspielen hat lassen:

https://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?pid=166865#pid166865

Zitat:

Und wer sagt dir überhaupt, dass das was bei diesen meinen jüngsten Listen unter Rating steht, Elo sind? Steht das irgendwo?

Im Ernst, in diesem Sinn ist jedes Ergebnis, das deutlicher ist im Sinn der Ergebnisspreizung, vor allem, wenn's in sich gut statistisch abgesichert ist (die Diskrimination mit relativ wenig error daher kommt), primär einmal kein Nachteil gegenüber einem, von dem man nachher (nach der Ergebnis- Ermittlung) auch nicht mehr weiß als vorher.

Was es schachlich bedeutet, muss man sowieso anhand der Stellungen definieren. Kurz gesagt, sind die 336 für das neue Tool von Frank Sanders (für die harte WDL- Umrechnung direkt aus den Lösezeiten aus der Shredder Protokolldatei) mit dieser Hardware- TC nur grenzwertig geeignet, bzw. man muss die Ergebnisse, die man da dann mit einem neuen Tool bekommt, halt auch erst einmal wieder einordnen lernen zu denen, die man bisher mit denselben Stellungen hatte.
Immerhin hatte ich mit Eret und Arasan- Suite einerseits und den 128 für etwas mehr Hardware- TC noch immer etwas schweren alten Stellungen andererseits schon lange nicht mehr so viel Spaß bei der Auswertung.
Tut mir wirklich leid, wenn ich dadurch wieder einmal jemandes Elosionen angekratzt habe