Mit ShashChess 18.2 habe ich eine neue Liste gestartet, weil je mehr es werden in einer Lösungs- .cbh, desto mehr Einträge kommen dazu, die man aus der geklonten .pgn wieder händisch herauslöschen muss. Die Einträge sind Hash- Angaben, keine Ahnung, warum die bei manchen Stellungen vor die Kommentare kommen zu den Engines, die teilnehmen, ElostatTS wertet sie dann aber als eigene Engines (das sind die "Geisterengines", von denen ich am Anfang schrieb), das manuelle Löschen mit einem Editor wird immer mühsamer und irgendwann ist das Progamm dann nicht mehr imstande, vernünftige Resultate zu schreiben.

Ich hoffe ein Workaround gefunden zu haben, um das zu vermeiden, auch dieser Tipp kam von Horst Wandersleben.
Die von Fritz geschriebene .pgn mit Aquarium öffnen (gleich die .cbh, die Aqua ja auch sollte lesen können, bringt das GUI regelmäßig zum Absturz, schade) und damit noch einmal ins .pgn- Format (das ja von verschiedenen GUIs verschieden interpretiert wird) von Aquarium (beim mir 2020) exportieren, das hat bei dem einen ersten Versuch, den ich so gemacht habe, die Hash- Einträge nicht übernommen.

http://talkchess.com/forum3/viewtopic.php?p=905971#p905971

Nur, um das Interesse an dem feinen Tool von Frank Schubert weiter zu wecken, weckt weiter

Um meine Versuche mit verschiedenen Sammlungen von Teststellungen zusammen zu fassen:

Prinzipiell gibt es für mich keinen Unterschied mehr zwischen "positionellen" und taktischen Teststellungen, man könnte Eröffnungsstellungen, Mittelspiel- und Endspielstellungen genau so in best move- Sammlungen automatisch ablaufen lassen, wenn man bei denjenigen (Stellungen), die mehr als einen gleichwertigen Lösungszug haben, immer einfach so viele, wie eine ungefähr gleich hohe Eval haben (sollten) mit einem dem jeweiligen Alternativ- Zug voran gestellten = als .cbh- Kommentar versehen, dann werden alle solchen Züge als gefunden oder nicht gefunden gewertet, man erspart sich das doch irgendwie sehr subjektive Punktesystem und kann die Ergebnisse wieder genau so wie bei den single best move- Sammlungen mit ELOStatTS auswerten.

Worum man aber so und so nicht herum kommt: bestimmte Stellungstypen (mehr als eine Unterscheidung nach einem Time to Solution bzw. Time to Eval- Schlüssel braucht's aber auch da eigentlich nicht, wenn's nur um die Rechenzeit geht) mit bestimmten Hardware- TC- Vorgaben versehen.

Was die bekanntesten Sammlungen angeht, würde ich sagen,  ab 8 avx2- Kernen und oder einer einzelnen 3070- GPU: Arasan 5"/Stellung, Eret 10, HTC114 30. Das in einen gemeinsamen Top mit 10" klappt auch, genauer ist's halt, zuerst die einzelnen Suiten mit jeweils selektivster und sensitivster einzelner TC laufen zu lassen und dann die Lösungs- cbh- files in eine gemeinsame .pgn zu kopieren, die ElostatTS dann auswertet.

Mit den Sammlungen mit mehreren Lösungszügen ebenfalls die jeweils besten Hardware- TCs in einzelnen Suiten bestimmen und auch in die gemeinsame Lösungs- .pgn kopieren, that's it.

Die positionellen Stellungen könnte man aus solchen Sammlungen wie STS rekrutieren und oder einfach zusätzlich beliebige Eröffnungs- Mittel- und Endspielstellungen mit ein paar Eich- Engines im MultiPV laufen lassen, die 2, 3, 4 (...) Züge mit Evals in einer gemeinsamen Range (wenn man's genauer haben will, nach ein bisschen Forward- Backward und nicht die Absolutwerte der Evals vergleichen sondern ihre Relationen zueinander als Quotient) als gleichwertige Lösungen in der Testsuite definieren.

In ein paar Jahren melde ich mich wieder, wenn's fertig ist, obwohl man's ja auch jetzt schon mit den vielen Sammlungen, die es gibt, mehr als ausreichend finden könnte, findet

Die BanksiaGUI kann jetzt Test Suits lösen.

https://banksiagui.com/download/

Run test suites: another new feature for developers/testers. As usual, it is designed to maximize efficiency/convenience for users. They can create a new test within only a few clicks, re-do a test with only one click. The test is very flexible: data can be loaded from files or pasted from the clipboard, chess positions can be turned on/off individually, run with multi engines, concurrencies to speed up/reduce the time… All results are displayed with rich information. Those also are displayed in text form to easily copy and save to compare, refer later

Ein pgn zu epd Umwandlungstool mit vielen Optionen:

https://glarean-magazin.ch/2008/08/02/gratis-downloads-musiknoten-materialien-schach-e-books-kostenlose-materialien-pop-rock-klassik/#Kostenlose-Schach-Materialien

Hier der „Lc0 Testing Guide“:

https://lczero.org/dev/wiki/testing-guide/

Hier das Tool zur Ordo Berechnung:

https://github.com/michiguel/Ordo/wiki/Ordo

Hier ein sehr praktisches und vielseitiges Tool zur Analyse von pgn-Dateien/ Datenbanken „pgn-extract“:

https://www.cs.kent.ac.uk/people/staff/djb/pgn-extract/help.html

Hier ein Link zu einem CSS-Thread zu Stefan Pohls Tool „Short Game Analyzer“:

https://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?tid=13249

Hier der Link auf zwei Testsuits von 1500 Stellungen für Engines und Lc0 mit dem MEA Analysetool:

https://rebel13.nl/misc/sts.html

Ein Weiteres besonderes Positivum des neuen Tools von Ed Schröder und Ferdinand Mosca:

Man kann mehrere Instanzen gleichzeitig laufen lassen, wenn man die .batch- files mehrmals startet, und es werden trotzdem alle Resultate in eine gemeinsame Liste eingetragen, auch wenn man nur ganz knapp zeitversetzt neue runs startet, während die alten noch laufen. So wie einer fertig ist, wird das .html- Ergebnis aufgeschlagen, jeder neu fertig werdende Lauf bekommt ein neues .html- Fenster mit allem, was bis dahin in der einen  Liste drin war und neu dazu gekommen ist.

Und was man mit einer .epd testet, kann man in aus der mea_results.csv kopieren und ein andere solche einfügen und so Ergebnisse verschiedener Einstellungen in eine gemeinsame Liste zusammenfügen mit der make-html.bat. Am einfachsten geht das mit gleichnamigen Files in einem anderen Ordner, jetzt verstehe ich auch erst, warum das im Download gleich mit 2 Ordnern angelegt wird, die sehr Ähnliches, teilweise auch Gleiches doppelt enthalten.

Schon sehr schön durchdacht, das ganze Package.

Z.B.:
Eine batch- Datei läuft mit LC0 und einem Netz x mit 300 msec,. gleichzeitig werden 3 andere Engines single threaded mit 100msec. über eine zweites batch- file gestartet, dann fügt man den ersten und den zweiten LC0- Lauf (nacheinander, damit sie sich nicht die GPU teilen müssen) in die .csv- Datei der anderen  Liste ein:



Die Fische single thread (damit wird auch die Reproduzierbarkeit besser) mit 100msec./Pos., LC0 (mit den 2 Netzen im Namen) mit 300msec, 2 CPU- Threads und der 3070ti GPU.
Die verschieden lange Initialisierungszeit von A-B und LC0 lässt sich schwer abschätzen, EloStatTS hat dazu die Offset.pgn im Download, aber die Leela- Ratio ist sowieso auch eine Frage für sich, so what,
regards

Hab' mal händisch den Eret für MEA editiert:

https://www.dropbox.com/s/iwsiujd0ofdvju4/MEA111.epd?dl=0

Leider funktioniert er mit dem Mosca- tool nur eingeschränkt, hier

http://talkchess.com/forum3/viewtopic.php?p=937088#p937088

mit Ed Schröder schon ein paar Postings darüber gewechselt, wir (vielleicht meldet er sich ja aber dort noch einmal, sonst probier' ich's vielleicht in seinem eigenen Forum weiter, ich selbst für mich allein hab's jetzt mal aufgegeben) finden keinen Syntax- Fehler mehr in der .epd, trotzdem meckert MEA in der Konsole immer noch rum, auch wenn bis zu einer TC von 999msec LC0 dann dennoch gewertet wird und es mit den Fischen bis 30 Threads so funktioniert, ist irgendwo TC- abhängig und Engine- abhängig ein Bug drin, der manche Runs immer wieder abbrechen lässt. Ich würde ja sagen, das liegt am MEA- Tool, bin aber nicht Python- kundig genug, dem dann auch selbst auf die Schliche zu kommen.
Schade, schon der Eret allein würde mit very short TC ganz gute Diskrimination selbst der stärksten Engines bringen:



Auch dieses Tool von Ferdy

https://github.com/fsmosca/STS-Rating/blob/master/tools/

installiere ich mir vorläufig nicht, vielleicht schafft's ja jemand Anderer damit oder händisch weitere Stellungen außer den 594 aus dem STS, die nicht allzu leicht sind

https://www.dropbox.com/s/x4qmr9ucykk0r76/594.epd?dl=0

und hier

https://www.dropbox.com/s/yu7dnjpofa6bb8n/1024.epd?dl=0

gemeinsam mit ebensolchen aus Eret, Arasan, HTC und aus meiner eigenen Puzzle- Sammlung enthalten sind, in ein funktionierendes MEA- Format zu bringen, diese Stellungen würden dann in Summe (sag ich mal, ohne es noch probieren zu können, händisch wird mir das zu mühsam, vor allem die Suche nach Syntax- Fehlern macht das vom Zeitaufwand her für Einen allein unüberschaubar) sicher reichen, mit TCs um eine Sekunde herum gute Selektivität und Sensitivität der Suite zu bekommen, wenn die schweren gelösten Stellungen um das mehr Punkte durch MEA erhalten, was die zu leichten weniger zählten.
Die 1024 als single best move suite funktioniert auch ohne MEA, aber entweder es bleiben bei sehr kurzen TCs zu viele Stellungen ungelöst oder es werden mit zu langen zu viele gelöst. Das alte Problem von Sensitivität und Selektivität, im Fall der Suiten ja nur von der Hardware- TC und dem Engine- Pool abhängig, ansonsten könnten man ja immer einfach beliebig viele leichte und schwere Stellungen zusammenschmeißen und hoffen, dass so wie mit dem einen Fuß im Eiswasser und dem anderen im kochenden eine angenehme Durchschnittstemperatur herauskäme. Auf die Stellungs- Sammlungen umgelegt, würde das für bestimmte Engines sogar funktionieren, aber halt nicht für einen größeren Pool. Mit MEA gemeinsam würde man das stark verbessern können in der Anwendbarkeit für größere TC- Unterschiede und breitere Engine- Samples, sowohl mit kleinerer Anzahl an Stellungen als auch mit größeren in einem bunteren Mix.

Just hoping and holding on...

Der letzte Stand, mit diesen 310 Stellungen in MEA- Syntax bin ich jetzt schon recht zufrieden:

http://talkchess.com/forum3/viewtopic.php?p=937191#p937191

Vielleicht noch 23 schwere (damit's runde 333 sind, und das Verhältnis von sehr leicht, leicht und schwer zueinander stimmt), wenn dann die MEA- Punkte noch etwas verfeinert werden, sollte eine erste short TC- Suite fürs MEA- Tool fertig sein, so wie ich sie mir vorgestellt habe

Erste Testresultate werden noch etwas auf sich warten lassen, damit sie dann auch wirklich brauchbar sind und ich nicht mehr an der Suite selbst basteln muss davor und dafür.

Vorläufiges Ende:

http://talkchess.com/forum3/viewtopic.php?p=937334#p937334

888 Stellungen im MEA- Format, Beschreibung und erste Resultate siehe Posting vom Link oben, ein solcher (Link) zum Runterladen der Stellungen ist dort auch enthalten.

Im Anschluss an

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

Weil's ja ums MEA- Tool geht, wie man es am besten verwendet und um die zugehörige Syntax, ist's hier vielleicht sogar passender.

Um gleich mal zu Franks Beispiel der einzelnen STS- Stellung ein paar Gegenbeispiele zu bringen, an denen ich gerade arbeite um eine eigene Endspiel- Suite für MEA zu basteln. Back to the roots: single best move, damit kann man sich bei der Punktevergabe schon mal nur auf die "Schwierigkeit" der Stellungen in Hinblick auf die Hardware- TC beschränken, die ist sowieso das Um und Auf, der Faktor Zeit ist der einzige im Schach, nach dem man außer an ganzen und halben Partiepunkten Leistungen von Menschen und Maschinen beurteilen kann, Zeit für Züge und Zeit für ganze Partien (schon mal außer mir jemand auf die Idee gekommen, den Remistod im eng-eng-match durch Zusatzpunkte für die geringere Restzeit unter den beiden Gegnern auf der Uhr relativ zur TC der Partie zu ergänzen? Das ist es ja auch, was z.B. EloStatTS beim Stellungstest mit jeder einzelnen Stellung und jedem (alt und neu gespeicherten) Engine- Paar vergleicht. Bei allen Stellungen die von 2en gleichermaßen innert der TC gelöst werden, also allen sozusagen Remis in den Minimatches der einzelnen Stellungen, zieht das Programm noch die genauen Lösezeiten heran um das Minimatch zu entscheiden. Es gibt bei EloStatTS also keine Remis, Stellungen, die gar nicht gelöst werden, praktisch den 1:1- Paaren im game playing entsprechend, sind statistisch das größere Problem, eigentlich im eng-eng-match ja auch. Das ist aber was für einen anderen Thread )

Nachdem ich in kurzen Versuchen schon länger staune, wie viele Studien der Harold van der Heijden- Datenbank SF im Sekunden- (und schnelleren) Tempo löst, hier 100 daraus, die Nummerierung in der HHdb ist nicht synchron, weil doch ein paar als zusammenpassende Engine- Teststellungen nicht verwendbar sind, aber die eigene HHdb- Nr. ist auch gespeichert und das alles in MEA-Syntax gebracht:



Dazu die ersten Testruns, in 20er- Schritten, um eventuelle Syntax- Fehler, an denen sich das Tool dann aufhängt, leichter zu finden als in größeren Blöcken.

    EPD  : test.epd
    Time : 100 ms
                                                Max   Total   Time   Hash         
    Engine           Score   Found  Pos   ELO  Score   Rate    ms     Mb  Cpu     
1  SF15              2475     81   100  3375   3300  75.0%    100     8    8
2  SF15              2100     66    80  3501   2700  77.8%    100     8    8
3  SF15              1675     52    60  3771   2000  83.8%    100     8    8
4  SF15               600     19    20  4320    625  96.0%    100     8    8
5  SF15               450     18    20  4050    500  90.0%    100     8    8

                                    Created with MEA
                                          by
                                       Ferdinand
                                         Mosca

Und jetzt nur noch kurz, damit's fürs erste Posting hier nicht gleich wieder unlesbar wird, zur Punktevergabe, insbesondere an Frank und Andere gerichtet wegen der Frage, wie kann man die objektivieren, um nicht nur von der numerischer Höhe (viel besser sowieso von ihrer Relation zueinander zwischen den Kandidatenzügen) einzelner Engines und oder der persönlichen Einschätzung abhängig zu sein.
Dass die Zeit, die die Engines zum Lösen dann als definitive TC bekommen, das entscheidende Kriterium der Auswahl der Stellungen ist, soviel sei gleich noch einmal erwähnt. Das bei einer ersten Sammlung besser abschätzen zu können, vorausgesetzt, es sind so wie hier lauter im Bereich einzelner Sekunden lösbare Stellungen braucht man bei so kurzen ohnehin nur 3 Runs zum Screening der Verhältnisse Zeit zu Zahl an Lösungen, hier war's einer mit 500mscec, einer mit 300 und einer mit 100.
Diejenigen Stellungen, die bei 500msec noch nicht gelöst waren, haben 100 Punkte bekommen, die zwischen 300 und 500 haben 75, die zwischen 300 und 100msec = 50, die bei 100 gelösten = 25. So hat sich das bei diesem ersten Probeballon recht gut verteilt, der jetzt dann erst in die Feineinstellung kommt, wenn man sieht, wieviele Stellungen es insgesamt werden sollen, damit die Ergebnisse mit verschiedenen Engines Diskrimination (Spreizung), aber auch Reproduzierbarkeit und geringe Schwankungsbreite haben, weil dann erst weiß man, wie die Relationen an Punkten zum Schluss wirklich definitiv ausschauen sollen.
Hier erst mal wieder Pause.

Wie auch schon im letzten Posting übers MEA- Tool erwähnt, würde mich ein einfach zu konstruierendes weiteres Tool sehr interessieren, das bei Remispartien zwischen Engines in einem Match die Restzeit der einen und der anderen Engine auf der Uhr beim Partieende des Remis aufrechnen könnte und in Relation zur TC- Vorgabe setzen.

Dazu neuerlich der Vergleich mit dem, was EloStatTS von Frank Schubert zur Auswertung von Stellungstest- Suiten macht. Das bewertet die Minimatches (in der Spalte unter Matches gelistet) die jede Engine gegen jede andere im Feld anhand jeder einzelnen Stellung liefert, zusätzlich zeitlich anhand der genauen Lösungszeiten der beiden Engines bei der einen Stellung.

Alle diese Minimatches, die von je 2 miteinander verglichenen Engines sozusagen Remis ausgehen, weil beide Engines des Vergleichspaares diese eine Stellung in der vorgegebenen Zeit lösen, alle diese Remis- Minimatches bewertet EloStatTS dann anhand der Zeitunterschiede der einzelnen Lösungszeiten zusätzlich.
Praktisch immer, selbst wenn man "nur" centi- seconds (wie sie jetzt z.B. Fritz notiert pro Stellung) und nicht gleich milliseconds  bei der einen Stellung und den beiden Engines des  jeweiligen Minimatches vergleicht, selbst dann kommen exakt gleiche Zeiten nicht soo häufig vor, es gewinnt auf diese Art also fast immer die eine oder die andere Engine diese zunächst Remis- Minimatches. Das Programm rechnet diese Zeitunterschiede zwischen je zwei miteinander "gematchten" Engines bei jedem neuen Run mit jeder schon gespeicherten Engine  in die drei Indizes um, die in der Liste ihre gleichnamigen Spalten haben, der dritte davon, der RIndex als letzter, das wäre der, den ich meine, am Ende jeder Liste wird er immer so kurz erläutert:



Für genauere Erklärung liest man sich am besten das .pdf durch, dass Frank Schubert seinerzeit dazu veröffentlicht hat.

https://glarean-magazin.ch/wp-content/uploads/2017/03/L%C3%B6sung-eines-alten-Problems-Frank-Schubert-1.pdf

Bei mehreren runs einer Engine gibt's jedesmal neue Minimatches gegen alle Engines, die schon gespeichert sind.

Wäre es wirklich völlig von der Hand zu weisen, solche direkten Zeitvergleiche auch bei den Remis von Eng-Eng-Matches zu ziehen?

Natürlich auch relativ zur Gesamtzeit, die für die Partie oder pro Zug vorgegeben war, und nur so wie bei EloStatTS allein für die jeweils 2 Engines und die jeweils eine Remispartie.
Beispiel: Engine A braucht von einer Gesamtzeitvorgabe von 1 Minute/Partie bis zum Remis 30 Sekunden, Engine B braucht für dasselbe Remis 35 Sekunden, Engine A bekommt zusätzlich zu dem halben Punkt fürs Remis eine noch näher zu bestimmte Menge an Zehntel- Punkten, Hunderstelpunkten, was auch immer man da für ein Maß für angemessen hält, je nach Remishäufigkeit und TC des Matches und Breite des Teilnehmerfeldes, um die Remis zwischen je 2 Engines weiter punkemäßig zu unterscheiden.

Python- bzw. Batch- File- Kundige vor!

Sowas als kleines Script, das .pgns dahingehend filtert und in Verhältniszahlen der Restzeiten auf den Uhren der Gegner umrechnet, könnte doch wirklich nicht sehr aufwändig sein (meint der kleine User solcher Scripts, der selber sowas noch nie geschrieben hat).
Aber jedenfalls mal nur so als Idee betrachtet?

Natürlich werden die Ergebnisse, die man so schon nach den Matches hat, dadurch wieder auf eine ganz andere Art ganz andere Ergebnisse für sich allein stehend, aber was die Zusatzinfo betrifft, müsste man mal schauen, inwieweit das so Errechnete dann ohnehin auch ganz gut mit einer entsprechend größeren Zahl an Partien genau in der Art der ersten davon zusätzlich mit Zeitmessungen beurteilten Partien korrellierten. Auf die Art könnte man in einfachen Versuchen schnell herausfinden, für welche Paarung auf welcher Hardware- TC man sich eventuell für ähnliche statisitsche Relevanz wie viele Partien ersparen könnte um dennoch zu sehr ähnlichen Ergebnissen zu kommen.

Just my two cents mal wieder.

Chess-Artist ist ein Python Programm, das Partien in der pgn-Datei analysieren, die epd-Datei kommentieren, die Engine auf Schachrätsel oder Probleme testen und Schachrätsel generieren kann.

https://github.com/fsmosca/chess-artist

Schachcomputerprogramme werden normalerweise mit einer Reihe von spezialisierten Tools und Methoden getestet, um ihre Stärke und Genauigkeit zu bewerten. Hier sind einige Beispiele:

1. **Spieltests**: Schachprogramme spielen oft Tausende von Spielen gegeneinander unter kontrollierten Bedingungen, um ihre relative Stärke zu bewerten. Dafür werden häufig dedizierte Testumgebungen wie der "Cute Chess" verwendet.

2. **Testsuites**: Testsuites wie der "Strategic Test Suite" und der "Tactical Test Suite" enthalten Sammlungen von Schachpositionen, die ein Schachprogramm lösen muss. Diese können helfen, spezifische Stärken und Schwächen in der Programmlogik aufzudecken.

3. **Benutzerdefinierte Schachengines**: Programme wie "Fritz", "Stockfish" und "Leela Chess Zero (LCZero)" werden häufig als Benchmark-Tools für Schachsoftware verwendet. Durch den Vergleich der Ergebnisse, die diese Engines in verschiedenen Positionen erzielen, können Entwickler ihre eigenen Programme verbessern.

4. **Ratingsysteme**: Es gibt verschiedene Ratingsysteme wie das Elo-System, das Glicko-System oder das TrueSkill-System, die dazu dienen, die Leistung eines Schachprogramms in einer Rangliste zu bewerten. Die Ergebnisse dieser Bewertungen können dazu verwendet werden, um die relative Stärke eines Schachprogramms zu bestimmen.

5. **Debugging-Tools**: Um die interne Logik und Entscheidungsfindung eines Schachprogramms zu überprüfen, können Entwickler spezielle Debugging-Tools verwenden. Diese Tools ermöglichen es ihnen, den Code Schritt für Schritt auszuführen und genau zu sehen, wie das Programm Entscheidungen trifft.

Diese Tools und Methoden ermöglichen es den Entwicklern, ihre Schachprogramme zu testen, zu optimieren und zu verbessern, um sie gegen menschliche Spieler und andere Schachprogramme konkurrenzfähiger zu machen.

Hier ein allgemeiner Benchmark mit Ergebnissen der CPUs:

https://openbenchmarking.org/test/pts/stockfish&eval=ce63817a02e99e8cf94a5b04177912d6fb69958b

Hier eine spezifische Veröffentlichung zu den Chess Puzzles von Penrose:

https://www.researchgate.net/publication/332896798_Solving_a_hypothetical_chess_problem_a_comparative_analysis_of_computational_methods_and_human_reasoning