Brutalsuperkurze Bedenkzeiten

By Werner Schüle Date 2009-05-20 14:02

Hallo Tobias,
unter superkurz verstehe ich was anderes

z.B. Spiel in 1 sek

Mit cutechess-cli.exe habe ich schon so was ausprobiert. Aber nicht viele engines verkraften diese Zeiten. Sloppy natürlich und Rybka verkraften so was.

Oder meintest du auch 1sek +0,1 sek pro Spiel?

Gruß
Werner

By Tobias Lagemann Date 2009-05-20 18:33

Hallo Werner,

yepp, 1sek plus 0,1sek pro Zug.

Bei mir verträgt Rybka die Bedenkzeit nicht

Viele Grüße
Tobias

By Ingo Althöfer Date 2009-05-20 20:20

[quote="Tobias Lagemann (CSS-Forum)"]
yepp, 1sek plus 0,1sek pro Zug.
[/quote]

Das ist wirklich schon kurz - und ich bin mir nicht sicher, ob
es ein guter Weg ist, wenn man Parameter für ein Programm
tunen will, dass dann bei wesentlich längeren Bedenkzeiten
stark spielen soll.

Aber zum Vergleich, es geht noch viel kürzer.
Ich benutze Spielesoftware ja, um neu erfundene Spiele
im Autoplay auf Fairness, Remisquote, Partielänge usw
zu testen. Da arbeite ich durchaus mit Bedenkzeiten,
die auf einem normalen Dualcore-PC hunderte oder auch
schon mal tausende von ganzen Partien pro Sekunde
Rechenzeit erlauben. Wenn die Ergebnisse dabei dann nicht
völlig aus dem Rahmen fallen, wird mit langsameren Partien
(z.B. ca 1 Sekunde pro Partie) weitergetestet.
Dabei geht es aber nicht um Hochleistung, sondern um
die Frage, ob die Spiele für "Normalspieler" geeignet sind.

Ingo Althöfer

By Roland Rösler Date 2009-05-21 05:54

Ist das jetzt 1 Sekunde im Inertialsystem oder 1 Sekunde im schwarzen Loch?

By Ingo Althöfer Date 2009-05-21 10:54

[quote="Roland Rösler"]
Ist das jetzt 1 Sekunde im Inertialsystem oder 1 Sekunde im schwarzen Loch?

[/quote]

Interessante Frage, wenn auch wohl nicht ernst gemeint.

In meiner Gruppe hatten wir jedenfalls "damals" das folgende unerwartete
Phänomen gehabt:

Thomas Rolle hatte Anfang 2003 in seiner Diplomarbeit einen Autoplayer
entwickelt, der Reihen von Testpartien für neu erfundene Spiele ausführte.
Die benutzten Algorithmen waren probabilistisch. Vor jeder neuen Partie der
Testreihe initialisierte das Programm den Pseudo-Zufallsgenerator über die
Systemzeit des PCs, auf dem es lief. Irgendwann fiel mir auf (bei Serien
mit ganz kurzen Bedenkzeiten), dass immer 16 bis 19 Partien in Folge das
gleiche Ergebnis hatte, also z.B. 17 Weiss-Siege in 34 Zügen, dann 16 Remisen
in 39 Zügen, dann 19 Weisssiege in 29 Zügen usw. Das konnte kein normaler
Zufall sein. Nach einigem Nachdenken begriff ich, was passierte: Die Systemzeit wurde
in ganzen Sekunden abgenommen, und in einer Sekunde schaffte das Programm
zwischen 16 und 19 Partien des vorliegenden Spiels. Alle diese 16 bis 19
Partien wurden dann mit derselben Pseudozufalls-Saat durchgeführt - und
verliefen deshalb identisch.

Die Lösung des Problems war einfach: Der Pseudozufallsgenerator wurde nur noch
einmal am Anfang der ganzen Serie initialisiert.

Bei Schachpartien mit 1 Sek + 0,1 Sek Increment ist man ja typischerweise noch
über der Sekundenlänge für eine ganze Partie. Wenn es aber noch schneller geht,
sollte man das Initialisierungsproblem für den Pseudozufallsgenerator im Auge haben.

Ingo Althöfer.

By Kay Schönberger Date 2009-05-21 12:16

[quote="Ingo Althöfer"]
Nach einigem Nachdenken begriff ich, was passierte: Die Systemzeit wurde
in ganzen Sekunden abgenommen, und in einer Sekunde schaffte das Programm
zwischen 16 und 19 Partien des vorliegenden Spiels. Alle diese 16 bis 19
Partien wurden dann mit derselben Pseudozufalls-Saat durchgeführt - und
verliefen deshalb identisch.
[/quote]

Da wurde einfach die falsche Methode zur Abfrage der Systemzeit aufgerufen (vermutlich time() aus time.h). Besser sind Methoden mit einer besseren Zeitauflösung, z.B. clock(), getrusage(), gettimeofday() oder GetProcessTimes() (aus der Win-API).

MfG Kay

By Ingo Althöfer Date 2009-05-21 16:21

[quote="Kay Schönberger"]
[quote="Ingo Althöfer"]
Nach einigem Nachdenken begriff ich, was passierte: Die Systemzeit wurde
in ganzen Sekunden abgenommen, und in einer Sekunde schaffte das Programm
zwischen 16 und 19 Partien des vorliegenden Spiels. Alle diese 16 bis 19
Partien wurden dann mit derselben Pseudozufalls-Saat durchgeführt - und
verliefen deshalb identisch.
[/quote]

Da wurde einfach die falsche Methode zur Abfrage der Systemzeit aufgerufen (vermutlich time() aus time.h). Besser sind Methoden mit einer besseren Zeitauflösung, z.B. clock(), getrusage(), gettimeofday() oder GetProcessTimes() (aus der Win-API).

MfG Kay
[/quote]

Aha, wieder was gelernt. Danke. Ingo.

By Michael Bechmann Date 2009-05-22 01:59

Wenn ich es richtig verstanden habe, hat das Programm während der Partien nie selbst gerechnet sondern der gesamte Partieverlauf aller Partien der Serie war schon durch die von der Systemzeit bestimmte Pseudozufallszahl vorbestimmt?

By Ingo Althöfer Date 2009-05-22 13:50

[quote="Michael Bechmann"]
Wenn ich es richtig verstanden habe, hat das Programm während der Partien nie selbst gerechnet sondern der gesamte Partieverlauf aller Partien der Serie war schon durch die von der Systemzeit bestimmte Pseudozufallszahl vorbestimmt?
[/quote]

Doch, das Programm hat in allen Partien, auch den identischen gerechnet.

By Thomas Cutter Date 2009-05-22 10:16

Die Systemzeit als ständige Initialisierung für Zufallszahlengeneratoren halte ich für sehr leichtsinning.

BTW, würde ich bei der Auswertung der Simulationen über die Ergebnisse einen Run-Test oder ähnliches laufen lassen. Der hätte das beobachtete Problem sofort aufgespürt.

Gruß Thomas

By Ingo Althöfer Date 2009-05-22 13:51

[quote="Thomas Cutter"]
Die Systemzeit als ständige Initialisierung für Zufallszahlengeneratoren halte ich für sehr leichtsinning.

BTW, würde ich bei der Auswertung der Simulationen über die Ergebnisse einen Run-Test oder ähnliches laufen lassen. Der hätte das beobachtete Problem sofort aufgespürt.

Gruß Thomas
[/quote]

Frage: Was genau ist mit "Run-Test oder ähnliches" gemeint?

Gruss, Ingo Althöfer

By Thomas Cutter Date 2009-05-22 18:34

Der Run-Test ist ein Testverfahren der nichtparametrischen Statistik. Diese Verfahren haben den Vorteil, daß sie relativ wenig stringente Voraussetzungen benötigen (was auf der anderen Seite natürlich auch wieder Effizienz kostet).

Der Test wird zB auch auf Wikipedia beschrieben:
http://de.wikipedia.org/wiki/Run-Test

In der Uni-Bibliothek gibt es sicher auch ein ganz gutes Buch von Büning und Trenkler dazu.

Gruß Thomas

By Ingo Althöfer Date 2009-05-22 20:18

[quote="Thomas Cutter"]
Der Run-Test ist ein Testverfahren der nichtparametrischen Statistik. Diese Verfahren haben den Vorteil, daß sie relativ wenig stringente Voraussetzungen benötigen (was auf der anderen Seite natürlich auch wieder Effizienz kostet).

Der Test wird zB auch auf Wikipedia beschrieben:
http://de.wikipedia.org/wiki/Run-Test

In der Uni-Bibliothek gibt es sicher auch ein ganz gutes Buch von Büning und Trenkler dazu.

Gruß Thomas
[/quote]

Danke für den Hinweis auf Wikipedia. Ich kannte den Test, allerdings nur unter
seinem anderen Namen "Wald-Wolfowitz-Test" (Wolfowitz ist sogar einer meiner
mathematischen Großväter.)

Gruss, Ingo.

By Ingo Bauer Date 2009-05-20 15:08

Hallo Tobias

[quote="Tobias Lagemann (CSS-Forum)"]

Bisher stimmen mich die Ergebnisse sehr optimistisch. Vergleichsmatches mit längeren Bedenkzeiten (naja, eigentlich sind die auch noch verdammt kurz) bestätigen bislang weitestgehend die Ergebnisse.

PS: Ach so, ich teste mit 1+0,1

[/quote]

Ich weiß nicht genau was 1+0.1 bedeuten soll, aber wir haben mit 1min+1sec rumprobiert und ich bin überhaupt nicht zufrieden! Die Ergebnisse sind nach 15000-20000 Partien pro Engine SEHR dicht zusammen, teilweise nur 2-3 Elo auseinander wobei dieselbe engine bei mir und 5+3 nach 1000 Partien bis zu 20+ Elo auseinander liegen. Sind Engines so dicht zusammen ist ein vernünftiges auswählen praktisch nicht mehr möglich. Ich bin mehr denn je übereugt das es nach unten für Enginetesten Grenzen gibt unter denen ein Testen völlig unsinning ist!

Gruß
Ingo

By Tobias Lagemann Date 2009-05-20 18:37

Hallo Ingo,

ich habe mich lange gesträubt, zu so kurzen Bedenkzeiten zu greifen (1sek + 0,1), aber die Not, die liebe Not.

Mal schauen, was am Ende bei rauskommt. Und, äh, mit einer Differenz von 20 Elo könnte ich noch leben, da die Unterschiede zwischen den verschiedenen Betas bzw. Settings doch recht groß sind. Und das waren sie auch schon bei seriöseren Tests

Ich mache das jetzt einfach mal, und wenn die neue Version kommt, bin ich gespannt auf die Ergebnisse der Ranglisten.

Viele Grüße
Tobias

By Roland Rösler Date 2009-05-21 05:51

Ich glaube nicht das es unsinning ist.
Was man hier sieht ist die Bewertung und nicht die Suche. Wenn alle gleich zusammenliegen, kann man sich zurücklehen. Sie bewerten alle gleich.
Sollte es aber Unterschiede geben und die Engine ist dann noch erfolgreicher als andere, sollte man schon mal nachdenken!

By Michael Scheidl Date 2009-05-21 12:07

[quote="Roland Rösler"] Was man hier sieht ist die Bewertung und nicht die Suche. [/quote]
Da wäre ich nicht so sicher, bzw. das ist mir zu stark vereinfacht. Man müßte sehen, welche nominellen Suchtiefen das ergibt. Ruhesuche kommt immer dazu, und irgendwelche Extensions spielen sicher auch bei kleinen Tiefen schon eine Rolle. Es könnte also genausogut sein, daß eine besonders effektive Suche hier von noch größerem Vorteil ist.

5 vs. 3 Halbzüge sind beispielsweise ein riesiger Vorteil; so schlecht kann eine Bewertung wohl kaum sein - bei einer der "üblichen" Engines - daß die 5 Halbzüge sich nicht sehr klar durchsetzen. Die Qualität der Bewertung spielt m.E. viel eher eine Rolle, wenn es hieße: 19 vs. 17 Halbzüge, denn so ein Unterschied verschwimmt in einer Grauzone unterschiedlichen Prunings und unterschiedlicher Extensions.

(Damit meine ich jetzt natürlich die tatsächlichen Rechentiefen, nicht wenn etwas anderes angezeigt wird als intern passiert, was ich übrigens für einen Frevel halte.)

P.S. In den 1980ern galten 5 Halbzüge - auf Turnierstufe 40/2h! - nicht als ganz schlecht, und nur die teuren Geräte erreichten 6 oder 7, und denen konnte dann Klubstärke bescheinigt werden.

By Kurt Utzinger Date 2009-05-20 20:04

[quote="Tobias Lagemann (CSS-Forum)"]
PS: Ach so, ich teste mit 1+0,1
[/quote]

... viel Vergnügen ... (oder: auf was für Ideen so manche doch kommen ... )

By Udo Kaiser Date 2009-05-21 09:57

die frage ist, was man abbildet wenn man mit sehr kurzen bedenkzeiten testet.
ich glaube nicht das man die spielstärke der engines damit abbildet. ich glaube man bildet die geschwindigkeit des zuggenerators ab .

By Kai Skibbe (PocketGrandmaster) Date 2009-05-21 10:50

Ganz so einfach ist es sicher nicht, denn nur legale Züge schnell zu generieren ist zwar schön, aber bringt noch lange keine ELO.

Kai

By Udo Kaiser Date 2009-05-21 14:39

meine bemerkung war auch mehr bildlich zu verstehen.

ich denke jedenfalls mit dieser quantitativen art des testens bekommt man
sehr viel datenmaterial das allerdings für die aussortierung der engines
unnütz ist wenn diese später mit längeren bedenkzeiten spielen sollen.

ein test sollte unter den bedingungen stattfinden die hinterher in der praxis umgesetzt werden.

die crashtests unserer autos z.B. finden nach realistischen kriterien statt.
wenn ich fernseher verkaufe zeige ich auf denen kein blueray-bild wenn die kunden zuhause
PAL anschauen, evtl. sogar noch analog im kabelfernsehen.

Man sollte also bei einem TEST immer die Kriterien schaffen die hinterher in der Praxis maßgeblich sind.

By Tobias Lagemann Date 2009-05-27 13:33

Hallo Udo,

ich bin ja auch misstrauisch, was die Nützlichkeit der so erzielten Ergebnis anbelangt, aber bisher sehen die Datenmengen ganz brauchbar aus. Und entsprechend bin ich bereit, in die Tests etwas Zeit zu investieren. Denn wenn am Ende etwas halbwegs brauchbares dabei heraus kommt, habe ich viel gewonnen, nämlich die Möglichkeit Settings, die ich mit meiner bislang benutzten Methode (1min + 1sek) aus Zeitgründen nie hätte testen können, nun doch getestet zu haben.

Und trotz der wirklich kurzen Bedenkzeiten, sind die Suchtiefen gar nicht so übel. Twisted macht 8-9 Halbzüge, im Endspiel teils sogar bis zu 15 Halbzüge.

Und zu den maßgeblichen Tests in der Praxis: Wie sehen die für Engines aus? Ich habe all die Beipackzettel ganz aufmerksam gelesen und nirgends den Hinweis gelesen "Designed for 5+2" oder was sonst auch immer.

Bis ich mit dem Betatesten anfing, haben mich ja nicht mal Enginematches interessiert, sondern nur die Analysemöglichkeiten.

Viele Grüße
Tobias

By Gerhard Sonnabend Date 2009-05-27 19:36

Hi Tobias !

[quote="Tobias Lagemann (CSS-Forum)"]
[...snip...]
Und zu den maßgeblichen Tests in der Praxis: Wie sehen die für Engines aus? Ich habe all die Beipackzettel ganz
aufmerksam gelesen und nirgends den Hinweis gelesen "Designed for 5+2" oder was sonst auch immer.

[...snip...]
[/quote]

Der ist gut

Viele Programmautoren gehen aber noch wesentlich "heftiger" zur Sache.
Z.B.:
Engine OLD vs Engine BETA mit ply=7 (oder auch ply=9, falls der Rechner es hergibt).
Danach wird mit dem Referenzmatch (OLD vs OLD ply=7) verglichen. Bei Steigerungen
jenseits 15-20 Punkten wird das Ganze dann vertieft. Sollen hauptsächlich
(Ver)Änderungen im Bereich Pruning abgetestet werden, dann greift man auch mal
zu "Ply-Matches" ala OLD und ply=8 vs BETA mit lediglich ply=7.
Je nach Rechner(n) kommen dabei pro Nacht tausende von Partien zustande.

Viele Grüsse,
G.S.

By Benno Hartwig Date 2009-05-24 06:39

[quote="Udo Kaiser"]die frage ist, was man abbildet wenn man mit sehr kurzen bedenkzeiten testet.
Ich glaube nicht das man die spielstärke der engines damit abbildet. ich glaube man bildet die geschwindigkeit des zuggenerators ab. [/quote]Viele Programme suchen ja bis zu einer bestimmten Tiefe (einigermaßen) komplett, um dann darauf (Ruhesuche etc.) mehr oder weniger zu vertiefen. Während bei 'normalen' Bedenkzeiten die eine Engine dann vielleicht 16 Halbzuge total rechnet und dann nach Gutdünken vertieft, macht die andere vielleicht nur 15 Halbzüge und vertieft dann vielleicht etwas intensiver.
Mag sein, dass sowas dann zu vergleichbaren Spielstärken führt.

Aber bei ultrakurzen Bedenkzeiten wird die eine Engine vielleicht 3 Halbzüge + Vertiefung machen, während die andere 2 Halbzüge + bessere_Vertiefung macht.
Vielleicht ja auch 5HZ+Vertiefung zu 4HZ+bessere_Vertiefung.
Es ist dann meiner Meinung nach vollkommen offen, ob hier dann nicht eine Engine deutlich Vorteile gewinnt (ich tippe ja auf die 3-Halbzüge-Engine).
Auf jeden Fall erscheinen mir in dieser Art erspielte Ergebnisse überhaupt nicht übertragbar auf längere Zeiten.
Spike, der eigentlich gar nicht schlecht spielt, habe ich häufig schon bei weit längeren Zeiten drastisch einbrechen sehen.

Benno

By Udo Kaiser Date 2009-05-21 14:42

ich finde du bist doch selbst schuld wenn du unter diesen kriterien testest.

wenn ich einen briefbeschwerer habe, teste ich dann ob er in der badewanne schwimmt oder sich als wurfgeschoß gegen einbrecher eignet ?

der test sollte an den realen einsatzbedingungen angelehnt sein.

By Ingo Althöfer Date 2009-05-21 16:25

[quote="Udo Kaiser"]

wenn ich einen briefbeschwerer habe, teste ich dann

* ob er in der badewanne schwimmt

* oder sich als wurfgeschoß gegen einbrecher eignet ?

[/quote]

Sehr schöne Bilder.

Übrigens:
* Als Wurfgeschoss gegen Einbrecher dürften viele Briefbeschwerer taugen.

* Aber kennt hier jemand Briefbeschwerer, die in ruhigem Wasser (normales H_2O,
mit 16er Sauerstoff, also kein schweres Wasser) schwimmen?

Ingo.

By Emilo Reggio Date 2009-05-21 17:53

[quote="Ingo Althöfer"]
Übrigens:
* Als Wurfgeschoss gegen Einbrecher dürften viele Briefbeschwerer taugen.

* Aber kennt hier jemand Briefbeschwerer, die in ruhigem Wasser (normales H_2O,
mit 16er Sauerstoff, also kein schweres Wasser) schwimmen?

Ingo.
[/quote]

als Briefbeschwerer eignen sich nur solche, die über eine stabile flugbahn verfügen der trffsicherheit wegen.

alle briefbeschwerer, die als hohlkörper angefertigt werden eigen sich hierzu, z.b. halbleere verschlossene bierflasche.

By Michael Bechmann Date 2009-05-22 02:05

Das man den Zeitzuschlag pro Zug in Zehntelsekunden festlegen kann, ist mir noch gar nicht aufgefallen - es gelingt zumindest in meiner Fritzversion nicht. Mit der Option "Aufschlag pro Zug" lassen sich nur ganze Sekunden festlegen.

andere neugierige Frage: Macht der Unterschied zwischen 0,1 sek/Zug und gar keinem Zeitaufschlag pro Zug wirklich etwas aus?

By Huseyin Oezoguz Date 2009-05-22 21:35

Die Frage nach der Methode wurde bisher nicht beantwortet und würde mich auch sehr interessieren. Zwar kann man bei Arena +hunderstel ms einstellen, allerdings lädt Arena die Engines so ätzend langsam, dass das laden ewig dauert, Turniere sind damit ausgeschlossen, ab gesehen davon habe ich noch keine Engine unter Arena gesehen, die bei +0,1s keine Zeitüberschreitung produziert. Also: Wie macht man das?

By Andreas Mader Date 2009-05-22 16:12

Ich kann mir gut vorstellen, dass bei brutal kurzen Bedenkzeiten der Effizienz des Zuggenerators ein wesentlich höherer Stellenwert zukommt wird als der Güte der Bewertungsfunktion. Aber vielleicht entspricht das ja auch den realen Bedingungen. Interessant jedenfalls, wie sich im Laufe der Zeit die Kriterien geändert haben: Vom Beobachten langsamer Partien und dem Abwägen, warum einzelne Züge gemacht oder nicht gemacht werden - hin zu Dutzenden Partien pro Minute und dem reinen Bewerten der Ergebnisse, ohne auch nur einen einzigen Zug anzusehen.

By Udo Kaiser Date 2009-05-22 21:37 Edited 2009-05-22 21:41

vollkommen richtig. das sehe ich genauso. quantität ersetzt qualität.

piff paff puff !

das leben schreibt immer wieder die merkwürdigsten geschichten. wer hätte denn damals in den 80er jahren vermutet
das Ossi Weiner, der Gralshüter der Supermacht H+G einmal Schachcomputer herstellt die 8in1 Spiele verkaufen,
keine LEDs mehr haben und schwächer spielen als mephisto II.

wir leben in einer wirren Zeit.
H+G ist pleite. Fidelity sowieso. Saitek an einen Spielekonsolenhersteller verkauft. Und Novag an einen Solarpanel-Hersteller.

Alles ist irgendwie surreal geschmolzen. Wie auf Dalis Bildern.

By Roland Rösler Date 2009-05-24 04:29

>... dass bei brutal kurzen Bedenkzeiten der Effizienz des Zuggenerators ...

Kannst Du das erläutern? Wie soll ein Zuggenerator effizient sein?

By Andreas Mader Date 2009-05-24 10:55

[quote="Roland Rösler"]
Kannst Du das erläutern? Wie soll ein Zuggenerator effizient sein?
[/quote]

Schneller = Effizienter.