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

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.

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

Rasmus:

der Übeltäter war "sayuri" (habe mal nachgesehen) bloss nix falsches eingeben
Kannst mir ja mal ne URL oder sonstwas rüberschicken...versuche mal das zu übersetzen.

Die Engine Leute testen die ELO werte mit einem Programm STS13.1 ...zB habe ich gerade mal zum Testen für Hakka3 das laufen lassen => 3028 oder sf7 => 3423 ..allerdings auf meinem Ubuntu Rechner. Die 1 Core Rasp3 Werte schreibe ich in mein Programm - als INFO (bzw. für die PGN).

Na ja, ich bin leider nur in der Windows und iOS Welt unterwegs ... meine Linux Kenntnisse sind noch aus der Steinzeit ... so rund um SUSE Linux 10 ...

Folglich kann ich nur schachlich antworten, welche Engines interessant sind ... und ich kann halt nur die einschätzen, die ich selbst kenne ...

Gruß,
Sascha

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

Die einfachste Methode ist ja, bei http://www.computerchess.org.uk/ccrl..._list_all.html zu gucken und nach dem Namen der Engine zu suchen (mit Strg-F im Browser). Opensource ist orange.

Habe ich schon gemacht (vor Wochen)

Aber das beantwortet mir nicht, warum ich einer besondere Engine aussuchen sollte (also Spielstil zB)..deshalb fragte ich hier auch mal

Jürgen

Hallo zusammen,
seit gestern läuft auf meinem Pi die Version 0.9e ... soweit stabil und ohne (bis jetzt) erkennbare Probleme.

Die gute Nachricht: Das "Forenprogramm" ct800 funktioniert in der (Beta) 1.12 einwandfrei auf dem Pi. Eine echte Bereicherung.

Ich würde die Spielstärke bei ca. 2.200 bis 2.250 Elo ansiedeln. Damit ist es einen Tick stärker, als ich es erwartet hätte. Von drei Partien im Modus 30 Sekunden pro Zug schaffte ich ein Remis ...

Aber auch hier fällt auf, dass eindeutig der Pi entscheidet, wann das Programm zieht und nicht die Engine! Selbst in relativ deutlichen Situationen rechnet das Programm exakt 30 Sekunden ... ebenso in verwickelten Stellungen.

Eine Änderung hier wäre in der Tat ein Schritt nach vorn! Denn wenn die Engine entscheidet, wann sie zieht, kann sie in eindeutigen Situationen "ein Zeitguthaben" aufbauen, das sie dann in einer komplizierten Stellung aufbrauchen kann ... ist ja bei allen herkömmlichen Schachcomputern auch so üblich ... und auch bei PC Programmen.

Was ich mich frage: Derzeit kann man ja, während der Pi rechnet, mit den Tasten "-" und "+" Rechentiefe mit Bewertung sowie den geplanten Zug abrufen ... ich finde es schade, dass die Anzeige jeweils nach einer Sekunde wieder zur Uhr springt ... ich fände, die Anzeige sollte jeweils dort bleiben, bis der Anwender nochmals die jeweilige Taste drückt ... das wäre schon ein Fortschritt ...

Wobei natürlich der gewünschte Rolliermodus noch immer deutlich besser wäre ... dieser könnte ja zum Beispiel während der Rechenphase mit der "<" Taste aktiviert und deaktiviert werden ...

Ansonsten: Ich bleibe dabei: Der Pi ist ein tolles Projekt mit unendlich viel Potential ... und wenn man sieht, was man insgesamt für sein Geld bekommt (DGT Brett mit allen Möglichkeiten zum Anschluss an den PC, Schachuhr und einen Schachcomputer) ist das Paket sein Geld aus meiner Sicht wirklich wert ... vorausgesetzt, dass man die Möglichkeiten nutzt und sich mit dem Projekt aktiv auseinandersetzen will! Dann ist es ein "Must have" ...

Gruß,
Sascha

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

Jein. Möglich ist es, die Engine mit "go infinite" zu starten und nach 30 Sekunden mit "stop" anzuhalten. Ich nehme aber an, daß zwar schon die Engine entscheidet, nur daß die Zugzeit mit "movetime" übergeben wird. Die UCI-Spezifikation sagt, daß in dem Fall die Zugzeit als exakt zu verstehen ist. Dadurch sind etliche Optimierungen nicht verfügbar.

Man könnte das einigermaßen umgehen, indem man als Restzeit immer z.B. die fünffache Zeit übergibt und als verbleibende Züge bis zur Zeitkontrolle fünf Züge. Einen deutlich längeren Raum würde ich nicht empfehlen, weil ansonsten Optimierungen für klassische Turniermodi dazwischenfunken können.

Das ergibt bei "Zeit pro Zug" aber prinzipiell wenig Sinn. Der Zweck wäre nur, daß der Benutzer nicht immer gleich lange warten muß. Ernsthaftes Zeitmanagement kann es nur bei Spielen mit Zeit geben, also entweder Zeit pro Spiel oder die Turniermodi.

So einen richtigen "Zeit pro Zug"-Modus wie klassische Schachcomputer haben PC-Engines nicht. Bei UCI nicht, weil "movetime" exakt ist, und bei Winboard nicht, weil die Engine zwar schneller antworten darf, aber sich kein Guthaben aufaddiert.

viele Grüße, Rasmus

Hi,
ist dann aber ein klassischer ... spiele ich zum Beispiel gegen den Vancouver auf der 30 Sekunden Stufe, kann es gut sein, dass er sich direkt nach dem Buch auch mal bis zu zwei Minuten gönnt, um die Stellung "zu verstehen" ...

Bei den allermeisten Schachcomputern ist das so gelöst, weil es ja Vorteile hat: Das Programm erkennt zum Beispiel nachdem ein HZ durchgerechnet ist, dass ein weiter HZ von der Tiefe eh nicht möglich ist und bricht nach 20 Sekunden ab ... dafür hat es dann später "ein Guthaben", wenn die Stellung mal komplex ist ...

Richtig zu Tragen kommt es natürlich, wenn Pondern (Permanent Brain) funktioniert, da hier oftmals Züge ohne Wartezeit ausgespielt werden und so ein fettes "Zeitguthaben" für komplexe Stellungen entsteht ...

Dies kommt einerseits dem menschlichen Empfinden eines "natürlichen Verhaltens" nahe ... andererseits bietet dieses Verhalten natürlich Potential für eine Erhöhung der Stärke, da komplexe Stellungen tiefer berechnet werden können.

Wie genau dies bei "normalen" Schachcomputern umgesetzt wird, weiß ich auch nicht. Aber bei den Lang Programmen wie auch bei der V11 oder dem Diablo funktioniert das schon recht gut.

Gruß,
Sascha

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