Vielleicht hat Michael ja recht, und man kann mit mir da wirklich nicht darüber reden.
Du machst dir völlig unnötige Sorgen, was
ich oder
wer auch immer zusätzlich zu dem, was du eine komplette Analyse nennst, veranstalten müsste.
Nichts von Alledem, ich will einfach den minimalen Aufwand, den der user selbst mindestens treiben müsste, um Neues in die Datenbank zu bekommen, anhand des eval- outputs seiner eigenen engine, mit der er eingeloggt ist, durch ihn selbst und seine engine kontrollieren lassen.
Dass man zum Vergleich dazu noch gleichzeitig mitrechnend eine weitere server- engine zum Vergleich heranziehen könnte, einfach wie bei einer Analyse mit mehreren engines unter einem gemeinsamen GUI, ist nur eine weitere Möglichkeit.
Brauchen wir aber gar nicht, wenn das server- GUI ein feature eingebaut hat, das die evals der user- engine auswertet, ohne jedes zusätzliche schachspielende Programm, ein reines Statistik-Modul sozusagen.
Ich will keine zusätzliche Kontrollinstanz installieren, weder um betrügerische Absicht noch einfach Blödsinn, den irgendjemand mit engine- Unterstützung in die Datenbank einzutragen versucht, zu verhindern.
Ich will einfach die zu einer irgendwie als komplett zu betrachtenden Analyse gehörende backward analysis, die auch jedes GUI als automatisches feature anbietet, zwingend vorschreiben, um so anhand der durch den hash- Eintrag der vor- und rückwärts gespielten Züge geänderten eval vor und nach dem Ausspielen und Rückwärtsspielen der Züge, die ich als Variante für speichernswert halte, zu beweisen, dass sich die Züge und deren Bewertungen gegenüber der Ausgangsstellung positiv für die jeweilige Seite auswirken.
Nehmen wir als konkrete Stellung die Grundstellung.
Um da 1.e4 neu einzutragen, nehmen wir mal an, das wär noch nicht drin, müsste ich eine bestimmte Zahl von Zügen als Variante spielen, die nicht nur am Ende von irgendeiner engine eine für Weiß bessere Bewertung bekäme als in der Grundstellung, ich müsste in einer vernünftigen Zeit und oder Rechentiefe der Rückwärtsanalyse dieser Variante mit dieser engine diese Bewertung im hash mit zurück nehmen können, sodass die dann, egal wie sie die Grundstellung vor dem Aus- und Zurückspielen bewertet hätte, mit von der Variante oder den Varianten vollen hash eine andere Bewertung hätte, als zuvor.
Z.B. Ich spiele ein paar Züge Spanier, dann zurück, und die engine sieht sich als Weißer in der Grundstellung danach statt um +0.19 um +0.21 im Vorteil, dann hat 1.e4 durch eine Variante wie 1.e4 e5 2.Sf3 Sc6 3.Lb5 Sf6 4.0-0 Sxe4 5.d4 Le7, was Houdini 2, die Grundstellung mit +0.19 nach einer Minute bewertend, im ca. 23Hz-Rechentakt (so ca. 10 sec./Zug bei lauter Pondertreffern) ausspielt, dann lasse ich automatisch im Minutentakt zurück rechnen. Danach wieder, diesmal mit vollem hash, 1 Minute Daueranalyse, die HV hat sich geändert, Houdini hat jetzt 3...a6 statt Sf6, die Bewertung ist +0.18 für Weiß am Zug in der Grundstellung, ich hätte keinen Grund, mir 1.e4 in der Datenbank als neuen Eintrag zu speichern, zum Glück gibt's ihn schon.
Man könnte hingegen überlegen, ob die Antwort 1...e5 von Schwarz nicht eigentlich gereicht hat, als neu durchzugehen, hat es aber auch nicht, wenn die Schwelle für eval- Hebung wenigstens 2% ist, dann ist der eine cp von 0,19 auf 0,18 um die Hälfte zu wenig, man sieht schon, die Ansprüche an die Schwellenwerte sollten nicht zu klein sein, immerhin gibt es ja außer 1...e5 auch noch Anderes, was wahrscheinlich doch nicht leicht als schlechter beweisbar ist.
Jetzt hätte ich mir eine eigene Variante einfallen lassen können und wahrscheinlich hätte ich es auch mit entsprechend großem Zeitaufwand vor- und rückwärts nicht geschafft, 5 Züge zu finden, die die Grundstellungsbewertung meiner engine wesentlich gehoben hätten durch vollen hash, die nicht auch schon in der Datenbank wären, wenn ihr ein halbwegs komplettes Buch als Grundlage diente.
Ich hätte nicht gerade mit der Grundstellung anfangen müssen, aber irgendwie bíetet sie sich an, oder werden wir da wirklich mit noch so raffinierter engine- Manipulation leicht die Theorie widerlegen oder neu schreiben müssen?
Sicherheitshalber hab ich einen ganz wilden Gambit- Junior 11.2 genommen, dem ich die Figurenwerte alle halbiert und die positionellen Parameter um die Hälfte hinaufgesetzt hab, spielt lustig, das Ding, verliert natürlich immer, wenn man es von frühen Eröffnungsstellung loshetzen lässt, bringt aber taktische Finessen immer wieder in Rechenzeiten zum Vorschein, wenn die Stellung danach ist, dass man mit den Ohren schlackert.
Der eröffnet, nachdem er die Grundstellung zunächst 0.14 bewertet, so im 10- Sek./Zug- Takt:
1. Nf3 d5 2. d4 Bf5 3. Bf4 e6 4. e3 Bd6 5. Bxd6 cxd6
Nach einer Rückwärts- Fehlersuche mit 1Min./Zug, bei der er jedem einzelnen Halbzug bis zum 3. Weißzug einen anderen besser findet als den zunächst gespielten (na gut, ist ja auch mehr Bedenkzeit, besser als umgekehrt), bewertet er mit vollem hash die Grundstellung wieder mit 0.14.
(Ich verschweige verschämt, dass sich unmittelbar nach der Minute ein kurzer Ausreisser von 0.22 erreignet, das nivelliert sich aber bald wieder auf 0.16, außerdem war er in der Grundstellung mit leerem hash bald nach der Minutengrenze eine Weile auf 0.17, dann sogar auch auf 0.21, die Bedenkzeiten waren natürlich alle einfach zu kurz
)
Man sieht aber schon, manipulierte engines können das System an die Grenzen bringen, 10% Schwellenwert hätten es aber ausgehalten.
Auch wollen wir ja Neuerungen, wenn sie irgendwie neu sind, nicht sofort wieder wegprunen, tatsächlich wäre auch die etwas exotische Gambit- Junior- Eröffnung noch im Rybka- Buch vorgekommen, so gesehen wäre ja auch wieder schade um sie.
Wo sind die Schwachpunkte?
Ich will jetzt wirklich nicht die Techniker reizen, mir zu schildern, wie sie eine server- Funktion, die nichts anderes machte, als die evals der eingeloggten engine abzuspeichern und miteinander zu vergleichen, überlisten würden. Natürlich kein Problem, aber doch auch keines, dass sich nicht lösen ließe, wenn man sich vor sowas überhaupt schützen müsste.
Nur in den Bewertungszeiten, Rechentiefen und Schwellenwerten, ab wo etwas als Eintrag gilt, sehe ich Diskussionsstoff, wenn man sich aber an dem, was man von der jeweiligen Stellung an evals und Möglichkeiten, sie zu verändern, kennt, orientiert, kann man eigentlich nicht viel falsch machen, es kommt ja wie schon mehrmals gesagt nicht auf die Absolutwerte, sondern nur auf die prozentuellen Änderungen an.
Für grundstellungsnahe Eröffnungsstellungen (so die ersten 10 Züge) sollten es wohl wenigstens 10 Prozent sein, schüttle ich mal aus dem Ärmel, nach 20 Zügen wäre wohl eher mehr gefragt? (Ich meine nur der Logik folgend, dass je weiter die Partie fortschreitet, desto näher man einer Entscheidung kommen sollte, und sei sie Remis, dieses würde sich in Eröffnungen dadurch ankündigen, dass die eval- Änderungen immer kleiner würden, das müsste aber wieder in Relation zu scharfen Varianten gesehen werden, bei denen die meisten engines schon deutliche + oder - Bewertungen abgäben, die müssten dafür wieder leichter zum Umschlagen oder Weitersteigen zu bringen sein.)
Ist das Alles eigentlich wirklich so abwegig?
Machen das nicht, wie auch schon gesagt, eigentlich ohnehin alle irgendwie so ähnlich, wenn sie mit einer oder mehreren engines analysieren oder Buchzüge editieren oder neue Varianten zu Büchern hinzufügen?
Übernehmen wirklich alle ständig nur völlig unkritisch irgendwelche Partien nur nach dem Ausgang derselben in bestimmten Zugtiefen in ihre Bücher, und wonach, wenn nicht nach den evals der engines und ihren Änderungen während einer Partie, einer Variante, gehen die Anderen alle vor, wenn das Ergebnis noch nicht eindeutig gewonnen, verloren oder remis ist?
nachrechnet. Also wie willst du kontrollieren? OK, wenn die Prüfengine die Bewertung und die Hauptvariante bekommt, kann sie deutlich schneller sein als die eigentliche Analyse. Aber ich denke, dass ist immer noch um ein Vielfaches zu langsam!
)
CSS-Shop