Hallo,

in Arena geht das.
Da gibt es im Modus blitz die option bonus pro zug und dort lässt sich millisek angeben.

gruß thomas

[quote="Ingo Althöfer"]
Eine Frage an die Testexperten:
Bei welchen Programmen kann man als Spielstufe
eine Basiszeit von 5 Sekunden und 0,1 Sekunden Bonus
pro gespieltem Zug einstellen?

Hintergrund der Frage:
Mich würde für gewisse Paarungen (z.B. Houdini vs Komodo) interessieren,
wie sich die Spielstärken verschieben, wenn man von schnell zu langsam
übergeht. Drei mögliche Testlevels dafür wären
(a) 5 Sek + 0,1 Sek Bonus
(b) 50 Sek + 1 Sek Bonus
(c) 500 Sek + 10 Sek Bonus,
wenn denn (a) wirklich machbar ist.
Die drei Levels liegen also jeweils um den Zeitfaktor 10 auseinander.

Ingo Althöfer.
[/quote]

Hallo,

Also ich nutze die LittleBlitzerGUI, mit der muß man alle Zeitkontrollen in Millisekunden angeben. Und sie läuft auch sehr stabil, bisher bei mir über 11000 Partien ohne Hänger(!!!). Allerdings würde ich von so kleinen Inkrements abraten. Unter 200ms Fischerbonus fangen div. Engines an Zeitüberschreitungen en masse zu produzieren (auch Houdini!). 250ms sollte die Untergrenze sein, da müßte alles glatt laufen. Aber es kann bei eingeschaltetem Hyperthreading auch durchaus sein, daß auch kürzere Inkrements funktionieren - das weiß ich allerdings nur vom Hörensagen, da mein alter Quad noch keins hat...

Am besten mal austesten. Die LittleBlitzerGUI zeigt Zeitverluste immer im laufenden Betrieb an, sodaß man das sofort sehen kann - vorbildlich. Auch kann man pro Core eine Partie laufen lassen, also 4 oder 6 oder 8 (je nach CPU) parallel, ohne, daß man das Programm mehrfach starten muß. Sehr komfortabel ist die Bedienung allerdings nicht, die Engineeinbindung inklusiver der UCI-Parametersettings läuft über ein Textfile. Aber daran gewöhnt man sich schnell.
Hier mal eine Funktionsbeschreibung von der Homepage:

Some of the major features:
Can allocate per-engine time with sub-millisecond accuracy.
Very low tournament overheads so you can allocate every available CPU to the chess engines. Utilises LittleThought's efficient move generation code to maximise performance.
Can run multiple engine vs engine games in parallel - for example, on a 4-core machine you can run 4 single-cpu matches, or on a 8-core machine you can run 4 dual-cpu matches.
Displays real time statistics on each engine's performance, and distinguishes between different types of game results such as loss by timeout or loss by illegal move.
Outputs PGN file for direct import into Bayeselo.
Supports Gauntlet or Round-Robin tournaments.
Supports Standard or Chess960 variants.
All engines can be configured separately.
Can set tournament level settings such as hash table size and time controls.
Can adjudicate games early based on specified criteria, to further speed up the tournament.
Supports starting positions loaded from FEN, EPD or PGN files.

Hier der Link zu dieser tollen und ungewöhnlichen GUI:
http://www.kimiensoftware.com/software/chess/littleblitzer

Gruß - Stefan

P.S: Wichtig ist, daß man jeder Engine im Engines-Textfile die richtige Anzahl von CPUs/Threads zuweist, da die GUI automatisch immer das UCI-Kommando Threads benutzt, was aber nicht alle Engines kennen (u.a. Rybka!). Daher jede Engine erst mal im Konsolenmodus starten und UCI als Kommando eingeben und nachsehen, wie das Kommando für die Thread-Anzahl ist!!!

Superinteressant.
Aber ob GUI und Engine sich in 1/10 Sekunde ausreichend verständigen können, und ob die Engine dazwischen auch zu einem einigermaßen plausiblen Zug kommen kann?
Und ob das so stabil läuft, dass es nicht doch zu Zeitüberschreitungen kommt? Auch das ist interessant.

Benno

[quote="Ingo Althöfer"]
Eine Frage an die Testexperten:
Bei welchen Programmen kann man als Spielstufe
eine Basiszeit von 5 Sekunden und 0,1 Sekunden Bonus
pro gespieltem Zug einstellen?[/quote]
Houdini works fine up to 1"+0.05" in cutechess-cli, but make sure that your computer does nothing else than chess - the slightest disturbance will generate time losses.

Robert

Hallo allerseits,

wie schon in einem früheren Posting angedeutet, hat mich
der von Clemens Keck durchgeführte Wettkampf zwischen
Junior und Houdini zu der Frage geführt, ob es Paare (A,B)
von Schachprogrammen gibt, die statistisch signifikant
verschieden stark von längeren Bedenkzeiten profitieren.

Klar ist, dass der praktische Nachweis sehr schwer sein
dürfte, weil es wirklich viele tausend Partien (zwischen
A und B) braucht, um so etwas zu belegen. Um das Jahr 2000
herum gab es intensive Experimente von Ernst A. Heinz
(zuerst in seiner Doktorarbeit, dann in weiteren Untersuchungen
während seiner Postdoc-Zeit am MIT), wo es um die Frage ging,
ob die Siegquoten von Tiefe(t+1) gegen Tiefe(t) bei einem identischen
Programm A (=Fritz) im Spiel gegen sich selbst für grosse t irgendwann
abnehmen ("diminishing returns").

Insbesondere macht es das komplexe Verhalten von GUIs fast
unmöglich, Settings mit ganz wenig Rechenzeit seriös zu benutzen.
(Für Ernst Heinz war das damals kein Problem, weil er sich ja speziell
für das Verhalten bei ganz langen Bedenkzeiten interessierte.)

Wenn Schach zu kompliziert ist, kann man erst mal versuchen, das
Phänomen bei einfacheren Spielen zu erkennen, für die man mindestens
zwei verschiedene Computerprogramme hat.
Über das Wochenende (incl. "Superbowl-Night") habe ich genug
Daten gesammelt, um die Existenz des Phänomens belegen zu können.
Entschieden hatte ich mich für das Spiel "EinStein würfelt nicht".

Ich stelle zuerst die beiden Programme vor:
(i) "Reines Monte-Carlo" mit Parameter t generiert in der Stellung,
für die es einen Zug machen soll, zuerst alle legalen Züge. Für
jeden davon spielt es t Zufallspartien bis zum Ende und zählt,
wieviel Siege dabei herausgesprungen sind. Der Zug mit den meisten
Siegen wird gemacht. Bei Gleichstand wird zufällig einer der Top-Scorer
gezogen.
(ii) "Monte-Carlo mit Ruhesuche" mit Parameter t unterscheidet sich
nur ein kleines bisschen vom reinen Monte-Carlo. Hier werden nämlich
keine reinen Zufallspartien gespielt, sondern in jeder Stellung einer
Pseudo-Zufallspartie wird geschaut, ob es einen direkten Gewinnzug
gibt. Falls ja, wird solch einer gemacht. Falls nicht, wird zufällig
einer der legalen Züge gemacht.
(Für Programmierer ist klar, dass Zufallspartien mit Ruhesuche deutlich
mehr Rechenzeit brauchen als reine Zufallspartien.)

Als Namenskürzel benutze ich für die Programme MC(t) und MC-Ruhe(t).
In jedem der folgenden Wettkämpfe wurden 200.000 Partien gespielt.
Es spielten die beiden Programme MC-Ruhe(t) und MC(3t) gegeneinander,
für verschiedene Werte von t. Jedes der Programme hatte in der Hälfte
der Partien den Anzug.
Hier sind die Ergebnisse (Punkte für MC-Ruhe(t) in ganzen Tausend,
gerundet auf Vielfache von hundert):

MC-Ruhe(1) vs MC(3)    111,7
MC-Ruhe(2) vs MC(6)    106,6

MC-Ruhe(4) vs MC(12)   102,5
MC-Ruhe(8) vs MC(24)   100,2

MC-Ruhe(14) vs MC(42)   99,8
MC-Ruhe(16) vs MC(48)   99,8

MC-Ruhe(32) vs MC(96)   101,2
MC-Ruhe(64) vs MC(192)  103,7

Auswertung: Der Erfolgsrate von MC-Ruhe(t) gegen MC(3t)
ist für kleine t deutlich über 50 Prozent. Sie fällt bei
mittleren t-Werten bis unter die 50-Prozent-Marke und
steigt dann wieder an. Für ganz grosse t (nicht getestet)
dürfte die 50-Prozentmarke angenähert werden.
Zu beobachten ist also ein besonders kurios anmutendes
Verhalten: Bei kleinen und grossen Parametern ist
MC-Ruhe(t) stärker, bei mittleren Parametern MC(3t).
Ob es so etwas wohl auch bei Schachprogrammen geben kann?

Zeitüberschreitungen konnten nicht vorkommen, da
ja nicht mit vorgegebener Bedenkzeit gespielt wurde,
sondern mit festen Monte-Carlo-Parametern.

Die gesamten Experimente wurden innerhalb von 40 Stunden
auf zwei Dual-PCs durchgeführt und halfen nebenbei auch mit,
die Wohnung zu heizen.  Mein Dank gilt Dr. Jörg Sameith, der
die Programme für das Experiment zur Verfügung stellte und
unter einer Oberfläche vereinigt hatte.

Ingo Althöfer.

Randbemerkung: Reines Monte-Carlo mit Parameter 192 spielt
"EinStein würfelt nicht" besser als die meisten Menschen.