Frank Quisinsky schrieb:
Hallo Stefan,
1. Ergebnisverzerrend:
Gehe nicht immer nur von Stockfish - Komodo etc. Matches aus. Gehe davon aus, dass Stockfish und Komodo bei Ratinglisten auch gegen deutlich schwächere Engines spielen. Bilden sich zu schnelle Remise durch dreifache ist das definitiv ergebnisverzerrend wenn dies nicht bei der Auswahl der Positionen vermieden wird. Wird auch schön in der Excel von Klaus ersichtlich. Es gibt Stellungen da kommen 9 von 10 Engines zu der gleichen dreifachen im Suchbaum. Mache ich Stichproben zu anderen Büchern, die ich für Vergleiche nutze (ein älteres Junior Buch, Hiarcs Zusatzbuch auf dem Stand vom Hiarcs Release), sehe ich das selbst in sehr guten Büchern viele dieser Positionen enthalten sind.
Das klingt erstmal durchaus vernünftig. Aber ich denke, der Teufel steckt im Detail. Endet eine Partie mit einem Remis, auch einem 3fach ist das ein klar definiertes Ergebnis. Versucht man nun durch ein Buch, diese Remisqoute generell abzusenken, dann hat man ein klar definiertes Ziel, das man dann auch (anhand der Zahl der Remisen overall) klar messen, bestimmen und überprüfen kann. Nämlich die klar definierten Partieergebnisse gezielt in eine Richtung zu verändern (Absenken der Remisqoute). Das Problem ensteht aber, wenn man nun - wie du -von frühen Remisen oder zu schnellen Remisen spricht. Denn dafür gibt es keine klare Definition. Was ist "früh" oder "zu schnell"?
Dann müßte man zunächst festlegen: Mißt man das nach Länge der Zugfolge oder nach Zahl der abgetauschten Figuren? (ich halte ersteres nicht für sinnvoll, wenn überhaupt, müßte man wohl die Zahl der Figuren auf dem Brett zur Beurteilung heranziehen, meine ich). Oder ggf. beide Parameter in der Beurteilung kombinieren.
Darüberhinaus hat man, egal welche Parameter man zur Beurteilung dieser Entscheidung heranzieht, immer das Problem, daß man irgendeinen Grenzwert festlegen muß, vor dem man ein Remis eben als "früh" oder "zu schnell" ansieht und oberhalb dieses Grenzwertes nicht. Und diesen Grenzwert kann man letzlich nur willkürlich wählen. Das ist dann ein menschengemachtes Ordnungsschema, daß man seinem Buch bzw. den Engines überstülpt. Und das ist m.E. fragwürdig, wenn man das innerhalb eines Projektes wie FEOBOS macht, das ja für sich beansprucht, daß die Engines alles analysieren und alles entscheiden, was du ja nicht müde wirst, zu betonen. Denn die Entscheidung "zu frühes" Remis oder nicht, ist eben
keine Entscheidung der Engines, sondern ganz im Gegenteil. Das entbehrt nicht einer gewissen Ironie.
Und ich denke daher, ergebnisverzerrend ist viel mehr, Remisen willkürlich in "zu früh" und "normal" zu unterteilen, als eine Eröffnungsstellung rauszufiltern in der 9 von 10 Engines ein 3fach Remis machen, es sei denn, es wäre ein forciertes Dauerschach. Denn andernfalls könnten zum einen die neun Engines das Remis ja vermeiden, wenn sie es denn für sinnvoll hielten, und zum anderen wird der zehnten Engine, die das Remis vermeidet, hier die Chance auf den Sieg verbaut. Das halte ich für durchaus problematisch.
Aus diesen Gründen verfolge ich eben das Ziel, die Gesamt-Remisqoute in einer beliebigen Zahl von gespielten Partien abzusenken. Das ist ein wohldefiniertes Ziel, was ohne menschliche Willkürentscheidungen / Grenzwertsetzungen meßbar ist. Und meine SALC-Stellungen erreichen dies, durch ein ebenfalls wohldefinertes Auswahlschema (alle Endstellungen: Rochaden auf gegenüberliegen Brettseiten und Damen auf dem Brett). Auch hier ist kein menschliches Auswahlkriterium, kein menschliches Eingreifen nötig, daß über dieses wohldefinierte Auswahlschema hinausgeht. Den einzigen von mir definierten, menschlicherseits festgesetzten Grenzwert gibt es bei der Filterung der Endstellungen nach der Komodobewertung (sie mußte in einem Intervall von [-0.6,+0.6] liegen). Dies ist auch nicht schön, das geb ich zu. Aber da ich die SALC-Stellungen aus Menschpartien herausgefiltert habe, mußte ich zu extreme Endbewertungen herausfiltern. Und den Intervallwert 0.6 habe ich nach einigen Versuchen für gut befunden. Letzlich war auch das eine willkürliche Entscheidung. Leider konnte ich sie nicht vermeiden. Ich nehme allerdings für das SALC-Buch auch nicht in Aspruch, daß nur Engines alles entscheiden. Diese Behauptung wäre auch unhaltbar. Was aber eben auch für FEOBOS gilt (Stichwort "zu schnelle" Remisen vermeiden...).
Daher schaue ich mir jetzt bei den vergleichenden Testruns eben die Zahl der Remisen insgesamt an. Sowohl beim Standard-Stockfish Eröffnungsset, als auch bei SALC, als eben auch bei FEOBOS. Denn ich kann und will mir nicht anmaßen, Remis-Partien in "Schnellremisen" und "Normalremisen" zu unterteilen. Wenn man ein Projekt erstellt, wie FEOBOS, dann kann man intern so eine Unterscheidung machen, wenn man will (nur sollte man dann nicht gebetsmühlenartig wiederholen, nur die Engines würden bei FEOBOS alles entscheiden, weil das dann einfach nicht stimmt) und das für sinnvoll hält (ich tue beides nicht, aber das ist eine Frage der persönlichen Entscheidung). Aber, und das ist ganz wesentlich, wenn ich als Tester arbeite, dann kann und will und werde ich nicht entscheiden, was ein "zu schnelles" Remis ist. Dann messe ich nach dem von mir scherzhaft so genannten "Windelprinzip" - entscheidend ist, was hinten herauskommt. Denn das kann man vernünftig messen und das interessiert auch die potentiellen Nutzer eine Engine bzw. eines Buches/Stellungssets. Und so werden das sicher auch andere Tester und Anwender sehen, da bin ich sehr sicher. Zudem ja der mathematische Fakt hinzukommt, daß die Gesamt-Remisqoute ja auch sinken
muß, wenn FEOBOS es schafft, frühe Remisen (was immer das sein mag) zu vermeiden, wenn durch FEOBOS nicht dafür an späterer Stelle der Partieverläufe die Remisqouten steigen. Das ist ja eine simple Durchschnittberechnung: Bleibt eine Remiswahrscheinlichkeit gleich, bis auf einen einzigen Teilabschnitt einer Partie (bei FEOBOS eben der Partiebeginn) und in diesem Teilabschnitt sinkt die Remiswahrscheinlichkeit ab, dann sinkt logischerweise ja die Gesamt-Remiswahrscheinlichkeit und somit
muß dann bei einer genügend großen Zahl gespielter Partien auch die Remisqoute dieser Partien sinken. Und das kann und würde man dann auch messen. Und deshalb mache ich das auch so. Und nicht anders.
Gruß -Stefan
PS: Lese gerade an anderer Stelle von dir: "Mir ist bei FEOBOS hinsichtlich Senkung der Remisquote nur interessant die Zugtiefe bis 24."
Da frage ich schon: Warum? Zum einen warum 24 Züge? Warum nicht 23, 25, 30 oder 20? Zum anderen gibt es viele Partien, die nach 24 Zügen bereits im Endspiel oder kurz davor sind, und andere, die nach 40 (oder mehr) Zügen noch bei vollem Brett auf Messers Schneide stehen (besonders bei verzahnten, blockierten Bauenrstellungen im Zentrum, war gestern z.B. bei der ersten Stockfish-Partie gegen Chiron im TCEC zu sehen (Partie Nr.2)). Aus diesen Überlegungen heraus ist
a) eine Grenzwertsetzung nach Zugzahl, welche Remisen man als zu früh ausmerzen will und welche nicht, meiner Meinung nach generell völlig untauglich - wenn überhaupt, müßte die Zahl der noch auf dem Brett befindlichen Figuren (gemessen bzw. aufaddiert in Bauerneinheiten) als Schwellwert genutzt werden. Auch da hätte man aber das Problem, einen Grenzwert willkürlich festsetzen zu müssen, aber das wäre allemal der sinnvollere Ansatz. Z.B: man könnte sagen, wenn 26 Bauerneinheiten abgetauscht sind (das wären z.B. Damentausch (2*9), ein Leichtfigurtausch (2*3) und ein Bauertausch (2*1), oder auch ein Turmtausch (2*5), zwei Leichtfigurtäusche (4*3) und zwei Bauerntäusche (2*2)). Wenn weniger abgetauscht wäre, wäre es ein frühes Remis, danach nicht. Das könnte zumindest halbwegs funktionieren. Da müßte man natürlich einige Experimente machen, evt. könnte der Schwellwert auch 30 sein oder so.
b) Die Zugzahl 24 ist vollkommen willkürlich gewählt. Es gibt überhaupt keinen Grund, warum man nicht stattdessen 23, 27, 29 nehmen könnte.
Ich kann also nur raten, daß du die grundlegenden Projekt-Entscheidungen von FEOBOS mal prinzipiell hinterfragst. "Senkung der Remisquote nur interessant die Zugtiefe bis 24" - das kann nicht das letzte Wort, das finale Kriterium sein, aufbauend auf dem soviel Rechner- und Arbeitszeit verbraucht wird. Kann ich nur hoffen.