Ich gehe mal in einen neuen Strang, weil es ja nicht auf einen Computer beschränkt ist.

Ich kann seit HGMs Übernahme der Entwicklung nicht sehen, dass XBoard tot sei. Seit den verschiedenen Adaptern kann sich ja auch jeder Programmierer selber entscheiden - Partien gegeneinander sind ja möglich.

Ich habe UCI nie selber in einer Engine unterstützt, ich mag die Philosophie dahinter nicht. XBoard ist relativ leicht zu programmieren, man muss es halt einmal machen und das war es.

Wenn Tester eine Präferenz haben, dann ist das ein Grund für Pragmatismus, aber das ist dann keine Wahl aufgrund technischer Vorzüge oder Nachteile.

Die Spielstärke von Crafty ist kein Argument. Bob Hyatts Argumente betreffen die Entität, d.h. sie sind eher philosophisch. Lernen nach der Partie ist zwar ein Grund gegen UCI, aber meine Engines haben das nie benutzt.
Die propagierte Einfachheit von UCI kann ich nachvollziehen, da Eröffnungen oder Enspiele auf die GUI zurückgreifen können. Aber weniger Arbeit bringt hier auch weniger Kontrolle.

Polling statt Threading ist jetzt nicht so schwer und auch nicht der große Unterschied. Das Schreiben eines Tokenizers bietet sich auch bei XBoard an, das dürfte auch kein Grund für oder gegen ein Protokoll sein. Eher schon die Historie des Programmierers und wann er mit dem Programm begonnen hat.
Leider beschäftigen sich die meisten Leute mit Schachprogrammen am PC in einer Rolle als reine Turnierdirektoren ohne Programmierkönnen oder -Wollen. Damit entscheidet die GUI massiv über die Akzeptanz, so wie Du es ja mit den Testern auch erlebst.

Ich habe nie ein GUI programmiert, aber das meinte ich auch nicht. Ich meinte die Programmierung auf einem Computer mit begrenzten Ressourcen, da UCI deutlich mehr Speicher benötigt. Auf PCs spielt das keine Rolle und selbst ein Raspberry Pi sollte damit kein Problem haben, aber einige Buffer müssen halt für UCI größer sein, damit die Zugliste immer wieder übermittelt werden kann. Zumindest bei seh beschränktem Hauptspeicher sehe ich einen Unterschied (wobei auch XBoard natürlich Overhead hat).

Sehr gut, danke.

Ja, es wird gnadenlos aufgebläht. Besonders, weil Winboard nicht mehr auf Schach ausgelegt ist, sondern auf Schach-Varianten, die sowieso niemand spielt. Jüngstes Beispiel ist das Disaster um die Entsprechung zu "searchmoves". Das will man einfach nicht mehr supporten.

Das ist mit UCI noch viel mehr der Fall. Aber mit Winboard hast Du haufenweise Absurditäten. Beispiele? Naja, es gibt "setboard", mit FEN-String. Schön, nur leider kann die GUI das auch abweisen. Damit bist Du bei dem edit-Drama.

Oder searchmoves. UCI? Machste searchmoves. Winboard? Da hast Du dann searchmoves und das Gegenteil, excludemoves. Nur deswegen, weil die GUI bei Schachvarianten nicht weiß, welche Züge denn legal wären. Ein weiterer Befehl "getlegalmoves", der das gelöst hätte, wäre zu einfach gewesen. Damit hätte die GUI bei reinen Schach-Engines selber wissen können, was legal ist, und bei Varianten nachfragen können.

Undo/Redo? Mit UCI bekommst Du einfach das position-Kommando. Winboard? Da kriegste "remove". Obwohl, nee, mit Arena stattdessen zweimal "undo". Ist die Engine eigentlich selber am Zug, wenn es nur einmal "undo" gibt? Nicht spezifiziert. Und wenn's zweimal "undo" gibt, ist die Engine dann am Zug oder hat man eine race-condition, weil sie nach dem ersten Undo am Zug war, dann gezogen hat, das zweite Undo bekommen hat und nochmal gezogen hat? Man weiß es nicht.

Ich hatte, real-Life, für die WB-Version unter "Chess for Android" die Bugmeldung, daß rausgehen aus der Anwendung und wieder reingehen nicht geht. Ich habe aber kein Smartphone und kann das somit nicht testen. Was auch immer die GUI dann wohl tun mag, wenn man das macht, ich weiß es nicht. UCI? Kein Problem, ist sowieso zustandslos.

Schlimmstenfalls bekommt meine Engine nicht mit, daß der eingegebene Zug zur selben Partie gehört und löscht daher irrtümlich ihre Hashtabellen und verwirft die Hauptvariante, aber das ist lediglich ein Performance-Problem.

Ich sehe da eh nicht, wo das Problem liegen soll. Die Engine weiß ja, daß sie am Gewinnen ist, also kann sie auch lernen. Wenn man in der Partie auf besser als +3.00 steht, dann ist das auf Gewinn. Es ght doch vor allem um Eröffnungsvarianten, und wenn die Engine zwar auf 3.00+ steht, aber ihrem eigenen Urteil nicht vertraut, dann wäre das wohl eher die Baustelle.

Nein, das ist es nicht. Meine Engine hat sowohl Eröffnungen als ganz wesentlichen Teil ihres Stils (geht ja auch mit UCI) als auch implementierte Endspiele. Daß die komplette Zugliste übergeben werden muß - eine sehr stumpfsinnige Arbeit. Computer sind in genau solchen Sachen aber sehr gut, weswegen jede GUI das einfach automatisert, womit es zum non-issue wird.

Gut, man kann das auf Commandline dann nicht mehr einfach nutzen, wenn man ein schlechtes Terminal hat, was mit Pfeil-oben nicht die vorige Zeile wiederholt. Deswegen haben die beiden Nutzer, die Desktoplinux mit Schach-Engines ohne GUI nutzen, aber einfach entsprechende EMACS-Makros.

Auch ein Gesichtspunkt, ja. Bevor ich dem Wahnsinn erlag, einen Schachcomputer bauen zu wollen (also eigentlich wollte ich ja bloß mal Erfahrung mit aktuellen Cortex M4 sammeln..), habe ich die Shredder-GUI verwendet. Wie schlichtweg genial die ist, habe ich nie wirklich bemerkt.

Bis ich Arena verwendete. Alles im Vergleich irgendwie zäh. Und Winboard, was einfach nur der Horror ist. Wenn Linuxer CLIs so mögen, liegt es auch daran, daß man damit einem Horror wie Xboard entkommen kann. Die wissen gar nicht, was richtige GUIs leisten können.

Das gesamte Ökosystem für Winboard ist einfach Steinzeit. Starte mal Winboard selber. Da kriegste einen abstrusen Dialog, der überhaupt nicht existieren sollte. Danach ist man per default im 5-Minuten-Blitzmodus. Zeitdruck also. Das ist mit Sicherheit das Allerletzte, was ein neuer User will. Die Eingabe für Stellungen ist furchtbar. Das Einfügen neuer Engines über diese Liste ist gruselig. Und für Crafty darf man dann auch noch mit einer rc-Datei herumfrickeln. Außerdem sieht Winboard dermaßen häßlich aus, daß mir die totale Abwesenheit jedweden Sinnes für Ästhetik nahezu physisch wehtut.

Kurzum, aus Anwendersicht ist das dermaßen schlecht, daß ich für die Shredder-GUI alleine, ohne Engine, locker 20 Euro bezahlen würde. Nur um diesem Horror zu entkommen. Leider verwendet die Shredder-GUI diesen WB2UCI-Krams, und in der Praxis funktioniert das nicht besonders gut.

Ich sehe nicht, wofür. Die Zugliste muß für Undo sowieso komplett verwaltet werden. Nur auf meinem Cortex-M4 stoße ich an Grenzen, weil das gebufferte Backup-RAM halt nur 4 kB groß ist. Damit gehen nur 40 Halbzüge Undo / Redo mit Zeitverwaltung. Das ist für Raspi und PCs aber doch ein Witz.

OK, ich sehe schon, Du hast den Fokus auf ganz anderen Features als ich. Sowas wie searchmoves hat mich nie interessiert.

Aber des mit setboard verstehe ich nicht. Eine neue Engine würde ich immer mit dem neuen Protokoll arbeiten lassen. Die Benutzung mit einer alten GUI klappt dann halt nicht. Aber deswegen Gnuchess zu emulieren? Käme mir nie in den Sinn.

Ist bei UCI aber kein optionaler Teil, also vergleiche ich auch gleiche Funktionalität bei xboard. Zumal das ja auch nur ein Beispiel für die Redundanz bei xboard ist, und wie gesagt, die läßt Testing und Support explodieren. Kein Wunder, wieso das besonders für kommerzielle Engines inakzeptabel ist.

Auch die Features, die dann in der GUI auftauchen, kamen erst in xboard rein, weil UCI vorgeprescht ist. Vorher hat man die Nutzer auf abstruse ini-Dateien und ebenso obskure Kommandozeilenparameter verwiesen nach dem Motto "friß oder stirb".

Die Protokollversion wird aber von der GUI und nicht von der Engine festgelegt. Die GUI kann auch mit "reject" reagieren. Protover 2 ist kein Ersatz für Version 1, sondern eine Ergänzung.

Übrigens, ein lustiges Detail am Rande: GNUchess, dessen Befehlssatz das xboard-Protokoll emuliert, bietet jetzt auch UCI-Support. Über diese Möglichkeit hatte ich auch nachgedacht, zumal ja schon xboard-Support in der Engine drin war, wenngleich unvollständig und nicht sehr robust. Deswegen kam ich ja erst auf xboard, weil ich das "mal eben schnell" wieder reinbauen konnte.

Die Konsequenz wäre aber noch mehr Redundanz gewesen, noch mehr Testing, noch mehr unklare Bugreports. Zumal Vermeidung redundanter Methoden gerade der Witz bei UCI ist.

Zuguterletzt hat UCI auch den ganz praktischen Vorteil, daß es das besser unterstützte Protokoll ist. Ich glaube nicht, daß man in DGT Pi, Revelation oder Grandmaster auch noch xboard reinbasteln wird. UCI ist drin, weil Stockfish UCI ist. Man könnte mit Adaptern arbeiten - und ist dann wieder in der Misere aus Testaufwand und Support.

Wenn ein Protokoll mehr Aufwand für Test und Support verlangt, dann muß es auch einen entsprechenden Mehrwert liefern. Bei gleichem Nutzwert ist es sonst allein deswegen schon raus. Die Rankinglisten legen auch nicht nahe, daß UCI-Engines an ihrem Protokoll leiden würden.

Sicher, UCI ist aktiv und entspricht dem Design wie es damals von Fritz vorgemacht wurde, mit allen Features von der GUI aus zu bedienen. Wäre es nicht stateless, dann wäre es mir sympathischer als jetzt. So verkommt eine Partie zu einer Abfolge von einzelnen Stellungen.

Nur im Protokoll, nicht in der Engine. Man kann Hauptvariante und Hashtabellen durchaus weiterverwenden - man muß halt nur gucken, ob hier eine Partie weitergeführt wurde oder es eine neue Stellung ist.

Stell Dir vor, die Engine hat ein eigenes Eröffnungsbuch, die GUI aber auch. Jetzt kommen die ersten vier Züge von der GUI, vorerst Buchende, die Engine liefert die nächsten beiden Züge aus dem Buch, durch Transposition findet die GUI den siebten Zug und jetzt erst beginnt die Rechnerei. Als Engine kann man sich davor nicht schützen. Das ist der Käse im Protokoll!

Für die Erfinder des Protokolls spielten diese Überlegungen keine Rolle und SMK hat ja später in einer Diskussion mit Bob Hyatt die Nachteile eingeräumt. Nur war da die Verbreitung schon zu groß um was dagegen zu machen.

Wenn jemand die besonderen Features von UCI nutzen möchte, dann sollte er natürlich auch UCI nehmen, es trifft halt nicht meinen Geschmack...

Dann liegt ein Bug vor. Wenn die GUI das Buch kontrolliert, dann soll die Engine nicht ihr eigenes Buch heranziehen. Entweder ist die GUI fehlerhaft und setzt OwnBook nicht auf false, oder die Engine ignoriert den Parameter. Ansonsten kann diese Situation aber gar nicht auftreten.

Das soll die Engine auch nicht. Klar, wenn man ein GUI-Buch nimmt, das auf die Engine nicht angepaßt ist, dann wird das Ergebnis nicht so toll sein. Etwa den CT800 mit Schwarz einen Holländer spielen zu lassen wird absehbar mit einem Verlust enden, wenn der Gegner nicht wesentlich schwächer ist. Aber die Freiheit liegt hier beim Anwender.

Meine Lösung ist es, OwnBook per default auf true zu setzen, weil das Buch wesentlicher Teil des Spielstils ist. Aber wenn der Anwender das nicht will, dann halt nicht. Vielleicht möchte er ja auch verschiedene Engines mit einem Standardbuch vergleichen, oder ein Turnier mit Eröffnungsthemen fahren.

Was mir beim näheren Nachdenken noch auffällt: das ganze Szenario hat mit UCI/xboard überhaupt nichts zu tun. Die GUI kann auch mit xboard das Eröffnungsbuch selber übernehmen und der Engine im force-Modus nur die gemachten Züge übermitteln, wenn der Anwender das so will.

Ja, aber ich kenne keine solche GUI.

Aber die Diskussion lässt einen einiges überdenken. Dafür schon mal danke!