Ich könnte die CT800-Engine anbieten. Die wird derzeit zur anstehenden V1.12 in der PC-Version auf UCI umgestellt. Der Winboard-Support hingegen wird gestrichen, weil zuviel Aufwand im Hinblick auf Testing und Troubleshooting, und für zuwenig Gegenwert.

UCI-Support wird komplett, also incl. go searchmoves/nodes/mate/infinite. Ponder kann die Engine nicht, aber mit go ponder / ponderhit kommt sie trotzdem zurecht. UCI wird als case insensitive behandelt, ausgenommen der FEN-String. Diverse Info-Ausgaben gibt's auch, ohne aber die GUI zuzuspammen. Das Zeitmanagement verdaut alles, was mit go kommt, und hat spezielle Optimierungen für die klassischen Turniermodi.

C-Code unter GPLv3+, Buildscripte (.bat und .sh), CPU-Drosselung zur Spielstärken-Reduktion (getestet bisher unter Windows, Linux und Android). Geht über UCI einzustellen.

Die Engine sollte mit ihrem eigenem Eröffnungsbuch gefahren werden, weil das abgestimmt ist. Spielstärke ist auf CCRL 40/4 mit 2228 CCRL-Elo angegeben, aber mit der Drosselung ist sie auch für Spieler um 1600 FIDE-Elo schlagbar. Man muß aber schon nachdenken, denn es wird nichts absichtlich verschenkt.

Zur Stabilität - es ist ein Freizeitprojekt. Instabilitäten sind mir bislang in den automatisierten Tests u.a. mit Arena nicht aufgefallen, die Codereviews mit entsprechenden Tools zeigen keine Auffälligkeiten. Trotzdem sind meine Ressourcen begrenzt, was das Testing angeht. Insbesondere das Threading, was mit dem UCI-Support nötig wurde, ist zwar ziemlich "hacky", dafür aber portabel implementiert, so daß die Tests der Windows-Version auch für die Linux-Version gut sind.

Und nochmal meine Frage, die ist etwas untergegangen, kannst Du zu gestern, 17:53 etwas sagen bezüglich Binary-Build für DGT Pi?

Das Teil verwendet neuronale Netze, und ich vermute daher, daß es mit Fließkomma-Arithmetik arbeitet. Das wird auf dem Raspi dramatisch langsamer sein als auf PCs.

Crafty ist Winboard und wird es auch immer bleiben, weil Bob kein Freund von UCI ist.

Schade, sehr schade.

Hallo Rasmus!
Das Prinzip der Giraffe ist mir bekannt, ich finde diesen Ansatz sehr interessant. Eines der besten Backgammon Programme (JellyFish) funktioniert auf der gleichen Basis ...

Selbst wenn die Giraffe deutlich langsamer sein sollte und unter 2.000 Elo fällt, bleibt sie eine Engine mit einem sowohl einzigartigen Konzept als auch Spielstil.

@Crafty: Sorry, stimmt ... hatte ich nicht drauf geachtet ... schade!

Gruß,
Sascha

__________________
This post may not be reproduced without prior written permission.
Copyright (c) 1967-2024. All rights reserved to make me feel special. :-)

Hi Rasmus,
Und nochmal meine Frage, die ist etwas untergegangen, kannst Du zu gestern, 17:53 etwas sagen bezüglich Binary-Build für DGT Pi?

=> was bedeutet das? Bitte nochmals erklären.


Wenn du mit UCI durch bis, kannst dich ja nochmals melden.

Ich hatte halt auch schon Engines, die
a) sich nicht sauber beenden ließen (zB wenn der User eine andere Engine will)
b) beim "Return drücken" im uci modus , abschmieren (macht kein guten Eindruck)
c) irgendwas anderes komisches machen, das ich jetzt gerade vergessen habe

u.A. deswegen muss das STABIL sein. Damit meine ich aber natürlich nicht deine Engine!!
Claudia war der letzte Täter...mal abgesehen davon das die Engine keine Ahnung von Zugwiederholung hatte - war sie erfreulich schwach (=gewünscht)

Jürgen

Zudem ist Xboard ziemlich tot, und das aus gutem Grund. Glaub mir, ich hab beides in der Engine implementiert, und Xboard fraß dermaßen Aufwand weg, daß der einfachste Bugfix war, es nicht mehr zu unterstützen.

Du hast zig verschiedene Wege, dasselbe zu erreichen. Das läßt das Testing explodieren. Troubleshooting wird viel aufwendiger, weil man nicht weiß, welcher Codepfad genommen wurde, und reale Nutzer schicken keine Logfiles. Ich bin ja dankbar, daß ich überhaupt weitere Nutzer als Tester habe.

Dann muß man noch grübeln, welche der diversen Möglichkeiten die GUI genommen haben könnte, und ob das Problem dann bei der GUI oder der Engine liegt. Das ganze auch noch mit zustandsbehaftetem Verhalten, und fertig ist der Wartungs-Alptraum. Deswegen ist UCI heute der Standard.

Die propagierten Vorteile von Xboard, auf die besonders Bob Hyatt pocht, sind in der Realität so minimal, daß Crafty sich nur mit aller Mühe unter den Top 30 hält, gegen die ganzen UCI-Engines. Selbst die Erkennung, ob ein neues go-Kommando eine bestehende Partie fortsetzt oder etwas komplett anderes ist, ist auf Engine-Seite mit UCI kein nennenswertes Problem. Nützlich für die Hashtabellen und Treffer in der Hauptvariante.

Für Hobby-Engines aus dem unteren Bereich gibt es zwei Gründe, wieso Winboard noch verbreitet ist:

- man muß das "?"-Kommando in der Suche nicht erkennen, so daß man eine Engine ohne jedes Threading machen kann. Die Top-Engines haben aber alle Multithreading, so daß noch ein Thread für die Eingabe auch schon egal ist.

- die einzelnen Kommandos z.B. für die Zeiten kommen separat, so daß man die Werte trivial mit sscanf auswerten kann. Mit UCI braucht man einen Tokeniser, den zu schreiben und zu testen aber auch nur zwei Tage dauert.

Auf GUI-Seite ist es nicht aufwendiger, weil die GUI die komplette Historie des Spiels sowieso verwalten muß, also Züge und auch Zeiten, weil sonst die Undo-Funktion nicht geht. Die Zugliste dann bei jedem Zug mit auszugeben, ist trivial. Ebenso die Remis-Erkennung.

Namd Jürgen,

Also Zielstellung ist, daß ich außer den Sourcen auch fertige Binaries bei meinen Releases anbiete, für Windows, neuerdings Android und möglichst auch Raspi. Einzige Ausnahme ist PC-Linux, aber wer das als Endnutzer auf dem Desktop hat, der weiß auch, wie man ein Buildscript aufruft.

Man kann sich unter http://gnutoolchains.com/raspberry/ eine GNU Toolchain für Windows runterladen. GCC mit allem drum und dran, muß man nur noch in bestehende Buildscripte einbinden. Jetzt gibt's da allerdings das übliche Linuxproblem mit Binärdateien, was noch nie wirklich gut funktioniert hat.

Der oberste Eintrag in der Liste ist für Raspi Pi 1/2/3/Zero, mit Debian Jessie. Geht das für den DGT Pi? Oder hat der noch ein Debian Wheezy, was der unterste Link wäre? Oder ist das je nach Baujahr unterschiedlich?

Was ist die bevorzugte Linking-Strategie: soll man statisch linken, insbesondere die C-Lib? Macht bei mir mal eben 750k mehr Programmgröße, mache ich für Windows und Android aber auch so (wobei die Mehrgröße längst nicht so arg ist), weil man keinen Config-Ärger hat. Oder dynamisch, was kleiner ist und womöglich anderen Ärger vermeiden könnte?

Alternativ kann ich Dir ja auch eine aktuelle Dev-Version zukommen lassen, dann kannst Du das ausprobieren und eventuelle Änderungswünsche einbringen. UCI ist nämlich soweit durch. Hauptsächlich stehen noch Tests für die Optimierungen in klassischen Turniermodi aus.

Return drücken im UCI-Modus funktioniert natürlich - es wird schon im Input-Thread erkannt, daß es ein leeres Kommando ist, was gar nicht erst weitergeleitet wird. Egal wieviel whitespace natürlich.

Es werden aber einige Anforderungen an die GUI gestellt. Beispielsweise wird erwartet, daß "position" nur legale Positionen und Zugfolgen überträgt. Also nicht zuviele Figuren, zuviele umgewandelte Figuren, schachgebende Seite darf nicht am Zug sein etc. Bei der Eingabe gibt es sonst einen Info-String, wieso die Engine das verweigert, und wenn sie trotzdem ziehen soll, gibt sie einen Nullmove zurück. Damit muß die GUI dann umgehen können. Unsinnige Rochaderechte oder EP-Feld werden hingegen stillschweigend korrigiert.

Ich habe zum Thema UCI und XBoard/Winboard in einem neuen Stang geantwortet um hier den Strang nicht zu sehr aufzublähen.

Hallo Rasmus,

keine Ahnung von win$$dows ...da sind mir zu viele $ drin

Picochess funktioniert historisch auch auf Wheezy allerdings geht dann die BT Autoverbindung nicht mehr => alles ist jetzt auf Jessie abgestellt.

Gibt aber Anwender, die ein Udroid mit Wheezy laufen lassen. Das geht auch - wird aber von uns nicht unterstützt (kennt sich keiner mit aus).
Sogar windows würde gehen.

für Zero (armv6!) linken wir die Engines statisch (weil das in der Vergangenheit immer wieder Probleme mit der libc gemacht hatte), sonst dynamische C-Programme.

Picochess ansich ist ja Python - und die Pi Lib von DGT als SO file (C-Schnittstelle zu Python).
Ich bin mir nicht sicher, das das ist was du mich gefragt hast. Ich kann dir nicht so viel helfen ---denke ich. Ich würde mal statisch machen, da hast du weniger Stress.


Das mit der Leereingabe war nur ein Beispiel .... So ein Käse ...das müsste man doch in den Griff bekommen ... außer mir scheint noch keiner eine Leereingabe versucht zu haben, ha.

Picochess nutzt die Python-chess lib (uci), da sollte eigentlich kein Mist gesendet werden - aber hatte ich mit Arasan auch schon ein Problem mit "kein Zug, weil 5 fache Stellungswiederholung"...gibt immer wieder was, und wenn es nur diese ucinewgame ist. Deswegen steht in meiner Liste auch "aktives Dev" ...dann kann man bei Problemen mal den Dev ansprechen ...Heute zB Rodent3 issues gelöst. Die UCI Schnittstelle lässt immer noch Raum für Diskussionen. Alles Beispiele!

Jürgen

Leider bleibt da nicht viel übrig.

Die meisten scheinen fertige Files zu sein, und sowas komisches wie *.exe
So richtig konnte ich keine C(++) Files finden, außer bei meinen Bekannten wie SF, Rodent usw.

Trotzdem danke.
Jürgen