Ich dachte wir sprechen von TheKing. TheKing ist eine Winboard-Engine. Unabhängig davon, wo das Programm sonst noch eingebaut wurde.

Und warum soll das für ein nicht WB Konsolenprogramm weniger Aufwand sein? Jedes Konsolen-Schachprogramm funktioniert im Programmablauf wie eine WB-Engine. Die Probleme mit Pondern und fehlendem Spielstand ist ein reines UCI Problem das je nach Programm bei der Implementierung von UCI mehr oder weniger Aufwand bedeutet.

Ich denke, man sollte hier zwischen Schwierigkeit und Aufwand unterscheiden. Natürlich ist es keine Raketenwissenschaft, eine WB-Engine auf UCI umzuschreiben. Habe ich schon gemacht.

Auch den Spielstand kann man bei UCI beibehalten, weil zwar das Protokoll zustandslos ist, aber die Engine muß es nicht sein. Man kann sich den Hash der aktuellen Position merken, falls sie nochmal übertragen wird, sowie die Hashes aller legalen Folgezüge. Damit kann man z.B. erkennen, wenn der Gegner mit der erwarteten Hauptvariante fortsetzt, so daß man den eigenen Zug in der HV bevorzugt untersucht. Funktioniert auch, wenn statt startpos plus moves das Idiom mit der FEN-Position genutzt wird.

Es wären aber aus dem Bauch geschätzt drei Wochen Aufwand in Vollzeit plus nochmal eine Woche für Tests und Debugging. Wenn Johan auch noch einen regulären Vollzeitjob hat sowie andere Prioritäten im Leben, ist das schon verständlich, wieso er da nicht so motiviert sein mag. Zumal Protokoll-Implementierung für die meisten Schachprogrammierer der eher lästige Teil ist, was die Motivation nochmal senkt.

Also ich wollte KEIN Krieg zw. WB und UCI anfangen. Was ich mag, ist wohl deutlich geworden - das spielt aber keine Rolle! Ich habe das geschrieben, weil eben Johan sagte, das es ein Riesenaufwand sei.
Ich finde das gehörte in den Phoenix Thread (es ging um Johan, WB, UCI und eben die Integration von TheKing in PHOENIX - nix allgemeines, aber OK...nur bin ich jetzt nicht mehr so motiviert zu schreiben ;-)

Und JA, ich glaube der wirkliche Grund liegt daran, das das eben super langweilig ist...ich wollte das auch nicht unbedingt machen, sondern lieber ein tolles Schachprogramm schreiben...das ist irgendwie erbaulicher.

Und JA, ich habe ewig mit den (div) Entwicklern herum gekämpft, damit sie mal das UCI Protokoll richtig (bzw vollständig - bei picochess war daher nur zum Teil "Alternativer Zug" möglich) einbauen...deswegen habe ich geschrieben "Man kann auch erstmal klein anfangen" was aber nicht heißen sollte, das jetzt irgendwelche Features erstmal weg geworfen werden, aehmm.
Denn:
Der Aufwand bei Phoenix ist wohl eher in der GUI zu sehen, jedenfalls meiner Meinung nach - obwohl 3W Entwicklungszeit das halte ich für zu viel, aber ich habe auch WB immer ignoriert ha.

So long, Jürgen

Hallo Jürgen,

nein, denke ich nicht.

Für den Normalsterblichen User ist aus meiner Sicht nur die Info interessant, welche Programme im Gerät momentan vorhanden sind.

Fakt ist, das Programm „The King“ ist nicht mit dabei. Die Hintergründe, warum das Programm nicht dabei ist, hatte Sascha sogar kurz angesprochen. Sehr schade, wie ich finde, aber so ist es nun mal und Ende der Info.

Das Aufdröseln der möglichen technischen Hintergründe bzw. die Sichtweise verschiedener Programmierer führt einfach viel zu weit in dem Thread, weil etliche User wohl nicht einmal wissen, was sich hinter UCI oder WinBoard verbirgt.

Somit habe ich die Aussagen nicht gelöscht, sondern in einen eigenen Thread ausgelagert. Hier kann man trefflich darüber diskutieren, streiten... wie auch immer.

Gruß
Micha

Ich denke man kann es einfach zusammenfassen:

UCI ist das Protokoll, das die GUI-Entwickler bevorzugen, da es die Kontrolle der GUI gibt. WB ist das Protokoll, das die Engine-Entwickler bevorzugen, da die Engine für das Spielen von Schachpartien programmiert ist, und nicht für das berechnen von einzelnen Stellungen.

Genausowenig wie der Engineprogrammierer vom GUI Entwickler verlangen kann, dass die GUI WB unterstützt kann der GUI Entwickler verlangen, dass eine Engine UCI unterstützt. Klar kann man fragen, aber wenn jemand sich für nur eine Variante entscheidet sollte das respektiert werden.

Die Anwender bevorzugen auch UCI, was natürlich nicht direkt am Protokoll liegt, sondern daran, wie die jeweiligen Ökosysteme sich entwickelt haben. WB-Engines haben immer irgendwelche Probleme (alleine schon, eine Analyse zu unterbrechen), und der ganze Zirkus mit den Commandline-Optionen war auch mies, zumal die für jede Engine wieder anders waren. Das UCI-Ökosystem bot Engines, die einfach funktionierten.

Zudem kann die GUI natürlich auch WB-Engines so ansprechen, wie sie das bei UCI tut: mit Übertragung einer Startposition nebst Zugliste. Dadurch liegt z.B. das Eröffnungsbuch bei der GUI, auch mit WB.

Nein. WB ist heute kaum noch von Bedeutung und eigentlich Legacy. Aus Entwicklersicht hat WB nur einen "Vorteil": man muß während der Berechnung keinerlei Eingaben verarbeiten. Gut, man kann dadurch auch keine Analyse bis Nutzerabbruch machen, wenn man das nicht einbaut.

Die Rangfolge der Engines legt nicht nahe, daß UCI-Engines da einen Nachteil hätten. Bei den Top-Engines ist keine einzige mit WB. Zudem, wie ich schon schrieb, kann man auch UCI so implementieren, daß man nicht nur einzelne Stellungen abarbeitet, sondern eine Spielfortsetzung erkennt, etwa um HV-Treffer auszuwerten.

Für den Anwender macht WInboard 2 oder UCI keinen Unterschied.

Führt aber zu noch größeren Problemen. Ich erinnere an die Zeit wo Chessbase genau das mit dem WB-Adapter gemacht hat. DIe Engines hatten Probleme durch die iniziierung der Hashtabellen nach jedem Zug, und durch nicht definierte Zeitkontrollen mit aufgezwungenem externen Buch.


Die Diskussion drehte sich ja um die alten Programme und um die Probleme beim nachträglichen implementieren von UCI. Wer eine neue UCI-Engine schreibt hat diese Probleme logischerweise nicht.

WB2 kam als Reaktion auf UCI, und viele WB-Engines haben auch heute noch irgendwelche CLI-Optionen beim Aufruf der Exe. Plus daß es für den Anwender sehr wohl einen Unterschied macht, ob z.B. Analyse geht oder nicht, abhängig davon, ob der Programmierer die Eingabe während der Suche abfragt oder nicht - ist ja optional im Protokoll. Was wieder bei jeder WB-Engine individuell ist.

Mit WB-Engines hat man praktisch immer Probleme, weil das Protokoll zu komplex ist und jeder was anderes implementiert. Das ist auch ein Grund, wieso ich WB-Engines gar nicht mehr in meinem Testparcours habe.

NG-Play, von dem ich die CT800-Engine geforkt habe, ist ja WB - und ich habe das auf UCI umgeschrieben, weil ich dann den Aufwand nur einmal hatte und nicht als Dauerbaustelle. D.h. ich habe genau sowas schon gemacht.