Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / Verbesserungspotenzial bei aktuellen Top-Engines
- - By Ulrich Haug Date 2009-07-10 10:19
Hallo liebe Schachfreunde,

Joachim Rang hat am hier 05.07.2009 eine interessante Partie des Dortmunder Turniers (Bacrot - Carlsen) vorgestellt und dabei auch eindrucksvoll aufgezeigt, dass alle aktuellen Programm die Schlusstellung falsch bewerten. Weiß konnte eine Festung aufbauen und dadurch ein Remis erzielen.
Daraus folgt aber - und das ist weit gravierender als die falsche Einschätzung der Schlussstellung! - dass die Programme höchstwahrscheinlich zuvor auch nicht optimal spielen. Denn wenn sie eine Remisstellung (Festung) mit +3 bewerten, werden sie diese "fröhlich" anstreben, obwohl vielleicht zwischendurch eine andere Fortsetzung, die mit +2 bewertet wurde, sehr gute Siegchancen geboten hätte.
Festungssituationen sind keine "exotischen" Ausnahmen, sondern kommen im Spitzenschach am Brett und auch im Fernschach immer wieder mal vor. Wenn ein Programm in der Lage wäre, Festungen korrekt zu bewerten, würde sich seine Spielstärke erhöhen.

Meine Frage:
Seht ihr noch andere Punkte, in denen auch heutige Spitzenengines ganz eindeutiges Verbesserungspotenzial haben? Welche?
Beispiele wären schön.

Tja, und dann könnten wir ja eine Email an die Spitzenprogrammierer schreiben... 

Nette Grüße,

Ulrich
Parent - By Clemens Keck Date 2009-07-10 13:37
Hallo Ulrich

Verbesserungen sind noch viele möglich. Spontan fällt mir dazu ein:

-Die Behandlung/Bewertung ungleicher Figurenkonstellationen z.B.
-Das Halten einer Remisstellung
-Eine bessere Erkennung von Freibauern und deren Gefahren
-Die Königssicherheit
- .....

Die meisten Punkte sind sehr schwierig zu programmieren fürchte ich.
Team-Rybka hat das frühzeitig erkannt, und ich vermute das Tabellen (in einer nicht bekannten Form)oder ähnliches in die engine eingebaut wurden. Larry Kaufmann hat daran sicherlich einen bedeutenden Teil beigesteuert. Diese Tabellen erlauben es zum einen in meist vorteilhafte unsymetrische Figurenspiele abzuwickeln, und zum anderen werden Bauernstrukturen wesentlich früher besser eingeschätzt.

MfG Clemens Keck
Parent - - By Karl-Heinz Milaster Date 2009-07-12 16:22
[quote="Ulrich Haug"]Denn wenn sie eine Remisstellung (Festung) mit +3 bewerten, werden sie diese "fröhlich" anstreben, obwohl vielleicht zwischendurch eine andere Fortsetzung, die mit +2 bewertet wurde, sehr gute Siegchancen geboten hätte.[/quote]

Hallo Ulrich,

so einfach ist das leider nicht. In jedem Schachprogramm gibts zwei gleichwertige "Seelen", eine für Weiss und eine für Schwarz. Wenn eine Remistellung - beispielsweise für Weiss - mit +3 bewertet wird, würde Schwarz das im Suchbaum mit allen Mitteln zu verhindern versuchen. Die Wahrscheinlichkeit, dass eine solche Stellung in einer Partie Engine gegen Enigne aufs Brett kommt, tendiert gegen Null.
An diesem Beispiel wird die ganze Malaise von Stellungstests offenbar: Die Engines müssen sich mit Stellungen "befassen", die sie entweder als Weiss-Spieler oder als Schwarz-Spieler im Suchbaum zu verhindern versuchen würden.
Wenn man einer Engine eine solche Stellung mit einer solchen Bewertung vorsetzt, ist für das Programm gewissermassen "das Kind schon in den Brunnen gefallen".

Gruss,
khm
Parent - - By Ulrich Haug Date 2009-07-13 00:08
Hallo Karl-Heinz,

[quote="Karl-Heinz Milaster"]
[quote="Ulrich Haug"]Denn wenn sie eine Remisstellung (Festung) mit +3 bewerten, werden sie diese "fröhlich" anstreben, obwohl vielleicht zwischendurch eine andere Fortsetzung, die mit +2 bewertet wurde, sehr gute Siegchancen geboten hätte.[/quote]

Hallo Ulrich,

so einfach ist das leider nicht. In jedem Schachprogramm gibts zwei gleichwertige "Seelen", eine für Weiss und eine für Schwarz. Wenn eine Remistellung - beispielsweise für Weiss - mit +3 bewertet wird, würde Schwarz das im Suchbaum mit allen Mitteln zu verhindern versuchen. Die Wahrscheinlichkeit, dass eine solche Stellung in einer Partie Engine gegen Enigne aufs Brett kommt, tendiert gegen Null.
(...)
Gruss,
khm
[/quote]

deine Überlegung ist nicht verkehrt: In einer Partie gegen eine andere Engine, die die gleich falsche Bewertung vornimmt, käme die Stellung wahrscheinlich nicht aufs Brett.

Allerdings interessieren mich persönlich Engine-Engine-Wettkämpfe wenig, ich nutze die Engines hauptsächlich für Analysen (und finde auch Partien Engine-Mensch noch immer reizvoll). Für Analysen ist die Fehlbewertung schlecht und folgenreich!

Freundliche Grüße,

Ulrich
Parent - By Karl-Heinz Milaster Date 2009-07-14 19:52
[quote="Ulrich Haug"]deine Überlegung ist nicht verkehrt: In einer Partie gegen eine andere Engine, die die gleich falsche Bewertung vornimmt, käme die Stellung wahrscheinlich nicht aufs Brett.[/quote]

Hallo Ulrich,

das ist nur die halbe Wahrheit. Es wird Dir auch nicht gelingen, gegen eine Engine eine solche oder ähnliche Stellung (Bewertung +3 für Dich durch die Engine) zu erreichen, weil die Engine das verhindern wird - und sei es durch ein Figurenopfer.

Gruss
khm
Parent - - By Thomas Lagershausen Date 2009-07-13 11:50
Nach 30 Jahren Schachprogrammierung habe ich, mit den Ausnahme Rybka und Junior, die Hoffnung aufgegeben, Programmierer würden auf die Ratschläge von guten Schachspielern hören.

Man braucht sich nur die gestrige Partei Svidler-Karpov vom Donostia Chess Festival 2009 mit einem Programm ansehen.

Ständig wollen die Programme ihre stärkste Figur auf den Damenflügel stellen, obwohl gerade ein Königsangriff mit 12.g2-g4  und 17. f4 eingeleitet worden ist.

Also strategisch immernoch unter dem Niveau von Kreisklassenspielern.

Aber was rede ich da noch. Genauso gut könnte ich heutzutage von einer deutschen Tages- oder Wochenzeitung den Satz erwarten:"Mein Gott haben wir uns aber die letzten Jahren moralisch daneben benommen in diesem Land."

Hoffnungslos.
Parent - - By Benno Hartwig Date 2009-07-13 12:03
[quote="Thomas Lagershausen"]Nach 30 Jahren Schachprogrammierung habe ich, mit den Ausnahme Rybka und Junior, die Hoffnung aufgegeben, Programmierer würden auf die Ratschläge von guten Schachspielern hören. [/quote]Unabhängig davon, dass du vielleicht die Verwirklichung bestimmter Dinge seit langem vermisst: Woher nimmst du denn die Gewissheit, dass die Dinge, die die Entwickler in den letzten Jahren zur Spielstärkesteigerung in Ihren Engines eingebaut haben, tatsächlich nicht auch auf dem Rat von 'guten Schachspielern' beruht?

Benno
Parent - - By Thomas Lagershausen Date 2009-07-13 12:08
Weil ich von der Ehrlichkeit der Programmierer ausgehen, wenn ich deren Interviews lese, die sie gegeben haben.

Da steht nie etwas von einem guten Schachspieler, dem sie etwas zu verdanken haben.

Da steht immer nur, ich habe die Suche verbessert.
Parent - - By Georg Hutschenreuter Date 2009-07-13 12:25
Hallo Thomas,
SMK hat in einem Interview durchaus verlauten lassen, dass er durch die gemeinsame Vorbereitung mit Kramnik enorm profitierte. Das muss aber schon etwas her sein. Mir ist jedoch nicht bekannt, dass er auch heute noch mit IM's oder GM's zusammen arbeitet.
Parent - - By Thomas Lagershausen Date 2009-07-13 13:14
Hallo Georg,

Für Kramnik ging es damals aber ausschießlich darum seinen WM-Titel gegen Peter Leko zu verteidigen.

Eine echte Zusammenarbeit, zum Zwecke der Verbesserung von Shredder, hat es da nie gegeben.

Natürlich kann man dann, mit dem Namen Kramnik, etwas Werbung für sein Produkt machen. Das gehört, bei den junge Unternehmern von heute, einfach so zum guten Ton mit dazu.

Kramnik als Schachlehrer für SMK wäre gar nicht nötig und nebenbei auch viel zu teuer.

Ein einfacher Oberligaspieler würde schon ausreichen einem Binärcodeautomaten etwas von Strategie beim Schach beizubringen.

So einfache Dinge wie z.B. die höhere Gewichtung des Fianchettoläufer g7 für Schwarz im Drachen sind bereits in guten Anfängerbüchern dokumentiert.
Parent - - By Benno Hartwig Date 2009-07-13 13:32
[quote="Thomas Lagershausen"]So einfache Dinge wie z.B. die höhere Gewichtung des Fianchettoläufer g7 für Schwarz im Drachen sind bereits in guten Anfängerbüchern dokumentiert.[/quote]Allerdings braucht es dann auch keinen 'guten Schachspieler' sondern ein solches Anfängerbuch.

Aus deinen Worten höre ich sowas wie die Unterstellung heraus, Entwickler würden sich nicht mir Schachspielern unterhalten wollen, oder würden ihnen nicht glauben wollen, oder jetzt eben: würden nicht mal die Inhalte von Anfänderbücher beachten wollen. (richtig rausgehört?)
Ich denke, hier bringst du dann einen falschen Tenor hinein.

Ich denke schon, dass sie versuchen Ideen herzubekommen, wo es geht, wenn sie die Aussicht sehen, dass damit das Spiel ihres geistigen Kindes verbessert wird.
'Will nicht zuhören' oder 'dem glaube ich nicht' spielt hier wohl eher keine Rolle.
Und wohl auch nicht "Das ist mir zu schwierig, was mir der Schachspieler erklärt!"
Manches ist ggf. gar nicht so schwer zu implementieren, wurde vielleicht probiert, und wirkte sich nicht vorteilhaft aus.
Anderes ist vielleicht doch nur recht schwierig so zu implementieren, dass das Spiel in anderen Stellungstypen dadurch nicht gestört wird.

Benno
Parent - - By Thomas Lagershausen Date 2009-07-13 13:41
Ich sehe Du bist bemüht dich dem Thema ernsthaft zu stellen. Das ehrt Dich.

Meine Erfahrung in meiner Zeit als Betatester mit Schachprogrammierern hat mich aber ernüchtert.

Wenn ich damals z.B. darauf hingewiesen habe, daß das Programm unvorteilhaft seine Springer entwickelt, also zum Rand hin, so wurde mir lediglich mitgeteilt, daß dies eben sehr, sehr schwierig zu programieren sei und zu vernachlässigen sei.

Heutzutage seh ich bei vielen Programmen, daß sie sehr wohl sich diesem Thema gestellt haben.

Aber grundsätzlich steckt das ganze Thema Strategie wirklich noch in den Kinderschuhen.
Parent - By Michael Scheidl Date 2009-07-13 19:26
Wieso es "schwierig zu programmieren" sein soll, Springern am Rande einen Bewertungspenalty zuzuordnen, ist mir schleierhaft. Bewertungen abhänging vom Standort eines Steines werden doch ständig gemacht. Ich glaube also, das muß wohl eher eine Verlegenheitsbemerkung des Programmierers gewesen sein, der vielleicht gerade andere Prioritäten hatte.

Einige Programmierer sind ja selber relativ starke (Klub-)Schachspieler. Vas Rajlich ist bekanntlich sogar IM und beschäftigt mit L.Kaufman den derzeitigen Senioren-Weltmeister mit Jahrzehnten an Schacherfahrung auf IM-Niveau, zum Bewertungstuning.

Daß bei der Entwicklung einer (neuen) Engine Strategie - sofern unterschieden vom "einfachen" Positionsspiel - nicht an erster Stelle kommt, ist allerdings einleuchtend. Zuerst muß er die Grundlagen im Griff haben (Suche, Taktik, elementare Mattführungen, einfache positionelle Elemente...). So etwas wie Randspringer würde ich allerdings nicht unter Strategie einreihen; das ist zu einfach.

Es hängt wie immer auch von den Definitionen einschlägiger Begriffe ab, die durchwegs nicht standardisiert sind. Mein Lieblingsbeispiel ist immer: Man sieht z.B. ein typisches Vorpostenfeld für einen Springer, und ein mögliches Manöver dorthin über ein paar Züge hinweg. Würde ich als das Wahrnehmen eines gewöhnlichen positionellen Faktors bezeichnen. Jemand anderer spricht dabei vielleicht von einem "stragischen Plan." Ich sage hingegen, das ist kein Plan, das ist ein Scherz. Also, eine Engine die nicht selten 16+ Halbzüge tief rechnet, kann man mir dann nicht als strategisch planende Engine verkaufen, nur weil sie den Springer infolge günstiger Vorpostenerkennung und -bewertung innnerhalb 5 oder 7 Halbzügen dorthin bringt.

D.h. man muß bei sowas immer darauf achten was wirklich konkret gemeint ist. Wirklich komplexe (ideenmäßg, nicht nur rechnerisch), langzügige und quasi abstrakte Konzepte kommen sicherlich bei Engines derzeit nur ganz selten oder gar nicht vor.

Nicht alles was technisch möglich ist, wird umgesetzt. Beispielsweise habe ich hinsichtlich Festungen bzw. einer Fortschrittsregel (welche das im Partieverlauf nach ganz einfacher Logik diagnostizieren könnte) schon öfter die Reaktion gesehen: Das nützt nichts wenn ich erkenne daß eine Festung besteht, wenn ich sie damit nicht schon vorher vermeiden kann. Ich sehe das anders: Wenn es schon mitunter "unweigerlich" passiert, so ist doch das zweitbeste, wenigstens dann zu wissen was los ist und richtig zu bewerten. Außerdem kann es ja in der Analyse auch auftreten, nicht nur in Enginepartien. Einigen offenbar sehr konkurrenzorientieren Schachprogrammieren ist das richtige Bewerten von Festungen - ohne Elo-Zuwachs - aber offenbar nicht wichtig genug oder wird als "Kosmetik" betrachtet, welche keine Priorität genießt.
Parent - - By Kurt Utzinger Date 2009-07-13 18:57
[quote="Ulrich Haug"]
[...]
Seht ihr noch andere Punkte, in denen auch heutige Spitzenengines ganz
eindeutiges Verbesserungspotenzial haben? Welche?
Beispiele wären schön.
[...]
Nette Grüße,

Ulrich
[/quote]

Hallo Ulrich
Da gäbe es X-Dutzend Beispiele, die rauszusuchen ich allerdings keine Lust habe.
Ganz zu schweigen von Endspielstellungen, die nur wegen der EGTBs (richtig)
gelöst werden. Nimmt man den Programmen die riesen Eröffnungsbibliotheken
weg, dann spielen sie auf knapp 1800 ELO, nimmt man ihnen noch die TBs
weg, dann agieren sie wie hilflose 1600 ELO Spieler. Richtig gut Schachspielen
können die Dinger nur im (taktischen) Mittelspiel mit wahrscheinlich auf einen
Menschen bezogen 3200 ELO, so dass die Spitzenengines ohne ihre Hilfsmittel
rein schachlich betrachtet eigentlich nicht mehr Wert sind als maximal 2300 ELO
Mfg
Kurt  
Parent - - By Benno Hartwig Date 2009-07-13 20:52
[quote="Kurt Utzinger"] Nimmt man den Programmen die riesen Eröffnungsbibliotheken
weg, dann spielen sie auf knapp 1800 ELO, nimmt man ihnen noch die TBs
weg, dann agieren sie wie hilflose 1600 ELO Spieler.[/quote]Kannst du diese deine IMO sehr gewagte These untermauern?
"heutige Spitzenengines ohne Eröffnungsbücher und Endspiel-DBs holen gegen ein Feld von 1600ELO-Gegnern man gerade mal ein ausgeglicheses Ergebnis"?
Nein, ich denke, die 1600ELO-Leute würden trotzdem platt-gespielt werden.

Allerdings ist die Frage schon interessant, und sie könnte auch im Spiel gegen Buch-Engines-Tablebases-Kombinationen abgeschätzt werden:
Welche Spielstärke hätte Rybka3 (z.B. 32bit auf 4 Kernen) ohne Bücher und Endspieldatenbanken?
So gut über 2500 traue ich ihr (allerdings so rein aus dem Bauch) immer noch zu.
Widerspruch?

Benno
Parent - - By Kurt Utzinger Date 2009-07-13 21:14
[quote="Benno Hartwig"]
[quote="Kurt Utzinger"] Nimmt man den Programmen die riesen Eröffnungsbibliotheken
weg, dann spielen sie auf knapp 1800 ELO, nimmt man ihnen noch die TBs
weg, dann agieren sie wie hilflose 1600 ELO Spieler.[/quote]Kannst du diese deine IMO sehr gewagte These untermauern?
"heutige Spitzenengines ohne Eröffnungsbücher und Endspiel-DBs holen gegen ein Feld von 1600ELO-Gegnern man gerade mal ein ausgeglicheses Ergebnis"?
Nein, ich denke, die 1600ELO-Leute würden trotzdem platt-gespielt werden.

Allerdings ist die Frage schon interessant, und sie könnte auch im Spiel gegen Buch-Engines-Tablebases-Kombinationen abgeschätzt werden:
Welche Spielstärke hätte Rybka3 (z.B. 32bit auf 4 Kernen) ohne Bücher und Endspieldatenbanken?
So gut über 2500 traue ich ihr (allerdings so rein aus dem Bauch) immer noch zu.
Widerspruch?

Benno
[/quote]

Hallo Benno
Vielleicht hast Du übersehen, dass ich trotz ELO-Leistung von 1800 in der
Eröffnungsphase ohne Bücher und 1600 ELO ohne TBs im Endspiel den Engines
noch immer eine Gesamtleistung von 2300 ELO attestiert habe, so dass ein
1600 ELO-Spieler noch immer absolut chancenlos wäre, wenn man die Engines
im mir beschriebenen Sinn schwächen würde. Sollte ich in meinen kommenden
Sommerferien mal Lust/Zeit haben, wieder mal einige Partien gegen die Tops
zu spielen, so bin ich nach wie vor überzeugt, mit der bekannt langweiligen
"do-nothing-but-do-it-well" Strategie ab und zu ein Remis zu holen unter ganz
normalen Bedingungen.
allerdings die Engines schwächen
Mfg
Kurt
Parent - By Benno Hartwig Date 2009-07-14 09:35 Edited 2009-07-14 09:38
[quote="Kurt Utzinger"]Vielleicht hast Du übersehen, dass ich trotz ELO-Leistung von 1800 in der
Eröffnungsphase ohne Bücher und 1600 ELO ohne TBs im Endspiel den Engines
noch immer eine Gesamtleistung von 2300 ELO attestiert habe[/quote]Sorry, stimmt.
Um den Vergleich Fair hinzukriegen, müsste man aber auch überlegen, mit welcher Spielstärke ein GM eigentlich auftreten könnte, wenn er z.B. zwar die Eröffnungsprinzipien im Kopf hätte, sein gesamtes Wissen über Eröffnungsvarianten und auch seine Erinnerung an sämtliche von anderen GMs gespielten Partien verloren hätte.
Auch er sitzt dann vor der Ausgangsstellung und beginnt zu überlegen und konkret durchzurechen "mit welchem Zug, welcher Kombination, welcher Gegenwehr kann ich denn jetzt Kontrolle über das Brett gewinnen?" und "Eine sehr schwierige Stellung!"
Würde ihn das nicht vermutlich auch etliche oder auch ähnlich viele 100 ELO kosten?

Benno
Parent - - By Udo Kaiser Date 2009-07-13 21:04
ich glaube das ist so nicht richtig.

die spielstärke heutiger engines hat wenig mit tablebases oder büchern zu tun.
Parent - By Kurt Utzinger Date 2009-07-13 21:15
[quote="Udo Kaiser"]
ich glaube das ist so nicht richtig.

die spielstärke heutiger engines hat wenig mit tablebases oder büchern zu tun.
[/quote]

Hallo Udo
Eine interessante These.
Mfg
Kurt
Parent - - By Ulrich Haug Date 2009-07-13 21:15
Hallo Kurt,

[quote="Kurt Utzinger"]
Hallo Ulrich
Da gäbe es X-Dutzend Beispiele, die rauszusuchen ich allerdings keine Lust habe.
[/quote]

Schade

[quote="Kurt Utzinger"]
Ganz zu schweigen von Endspielstellungen, die nur wegen der EGTBs (richtig)
gelöst werden. Nimmt man den Programmen die riesen Eröffnungsbibliotheken
weg, dann spielen sie auf knapp 1800 ELO, nimmt man ihnen noch die TBs
weg, dann agieren sie wie hilflose 1600 ELO Spieler.
(..)
Mfg
Kurt  

[/quote]

Ob deine geschätzten Ratingzahlen zutreffen oder nicht, sei dahingestellt.
Für mich gehören Engine+Eröffnungsbuch+Tablebases als Einheit zusammen, so dass ich eine Engine nicht für schwächer einschätze, weil sie z.B. das Springer-Läufer-Matt mit Hilfe der Tablebases bewerkstelligt.
Ansichtssache, dieses Thema wurde hier ja schon mehrmals diskutiert.

Freundliche Grüße,

Ulrich
Parent - By Michael Scheidl Date 2009-07-14 03:57
Konkret in KLS-K ist so eine Engine "an sich" natürlich schwächer als eine andere, die das selbständig kann. Bei uns wirkt sich das nicht aus, bei anderen Usern u.U. schon.

Das Problem würde beträchtlich entschärft, wenn Engines und/oder Schach-GUIs standardmäßig (natürlich auch abwählbar) die 3- und 4-Steiner mitinstallieren würden. Diese ca. 30 MB sind ja heute platzmäßig überhaupt kein Problem mehr. Dann, aber nur dann braucht sich kein Schachprogrammierer mehr um solche Mattführungen kümmern sobald seine Software (Engine oder GUI) Nalimovs benutzt.

Was macht z.B. Fritz 11 mittlerweile (bei den CB.-Programmen sind ja üblicherweise die 3/4-Steiner immerhin auf den CDs und DVDs drauf)? Werden diese inzwischen mitinstalliert, oder wenigstens optional zur Installation angeboten? Werden sie dann innerhalb der GUI automatisch dementsprechend konfiguriert?

Das wäre alles notwendig, und ein guter Schritt vorwärts. - Gute aussagkräftige Dokumentation täte ein übriges.

Mir sind die neuen User, Schachanfänger, Neulinge in Sachen Computerschach usw. nämlich nicht wurscht, von denen die meisten Tablebases noch gar nicht kennen werden, und die sich dann zurecht(!) u.U. wundern und enttäuscht sind. Man kann nicht von Einsteigern erwarten, daß sie solche fortgeschrittenen Konfigurationserfordernisse vorhersehen. Das wäre Hellseherei. Es ist ganz normal, daß sie damit rechnen daß Engines, welche insgesamt stärker als GMs spielen, selbstverständlich auch das übliche elementare Endspielwissen haben bzw. können.

Im Rybkaforum sehe ich eigentlich "laufend" Postings von Neueinsteigern, die ALLE beim Thema Tablebases Erklärungen benötigen. Sie wissen NICHTS darüber - weil sie von ihrer neuen Software nicht "proaktiv" wie man heute so schön sagt, darüber instruiert wurden. Daß beim ersten Programmstart ein kleines Tutorial - meinetwegen á la F1-Hilfe - aufpoppt und kurz die üblichen Grundsatzthemen (Engine, UCI, Buch, Nalimovs, PGN, FEN) erklärt, wäre doch sicherlich möglich. Das ist ja an sich alles nicht so schwierig.
Parent - - By Michael Scheidl Date 2009-07-13 23:21
Das ist aber sehr stark übertrieben.

Außerdem kommt es auf Einzelheiten an. Wogegen spielt eine Engine ohne Buch die Eröffnung angeblich auf 1800-Niveau? Da macht es sicher einen Unterschied ob der Gegner ein 1800er-Klubspieler, ein GM oder eine riesige, breite und tiefe Eröffnungsbibliothek ist. Und welche Endspiele werden ohne Tablebases auf 1600er-Niveau behandelt? Viele Endspiele sind ja noch gar nicht in so einer Tablebase-Nähe daß das überhaupt einen Unterschied ausmacht. Weiters löst beispielsweise Stockfish 1.3/1.4 ohne jedwede EGTBs im PET mehr Aufgaben als Rybka 2.x samt 3/4- und in diesem Test wichtigen 5er-Tables für Turm gegen Turm.

(Der Vergleich mit Rybka ist sehr angebracht, hat doch Version 2.3.2a 2007 das beste Resultat im E-E-T abgeliefert!)

Einige - sicherlich nicht alle - Engines behandeln Eröffnungen von sich aus sehr gut; Da warst ja selbst Fan von The King dem ich das attestieren würde, und z.B. auch Shredder (daher auch im Chess960 gut) versteht Eröffnungsgrundsätze. Die Hauptschwäche von Engines in der Eröffnung ist meines Erachtens, daß sie von sich aus unter denselben Bedingungen kaum variieren. (Es kann natürlich sein, daß bei anderer Bedenkzeit, anderem Computer oder geänderten Settings 1.d4 gewählt wird, wenn unter bestimmten Bedingungen stets 1.e4 gewählt wird.)

Zufallsfaktoren sind ungebräuchlich geworden; zu experimentellen Zwecken könnte man dafür aber Rybka 2s "Randomizer"-Feature heranziehen.

Einige typische Endspielschwächen betreffen m.E. vor allem fehlendes Wissen(*) im (sehr) späten Endspiel, und wenn sich der Programmierer "tragischerweise" felsenfest darauf verläßt, daß seine Engine nur von Computerschachexperten benutzt wird. Das sieht allerdings manchmal entsetzlich aus; so erlebte ich kürzlich im Maschinenraum von Schach.de, daß Rybka 3 ohne Tablebases offensichtlich eine elementare Remisstellung in KB-K nicht erkennt und über +3 bewertete. Aber das sind eigentlich untypische Ausnahmen und ich würde sagen, Engines sind heutzutage im Endspiel im allgemeinen 2600 näher als 1600.

*) Es ist in der Tat frustrierend, im Jahre 2009 derartige Lücken in einer "Ubermensch"-Engine hinnehmen zu sollen, derentwegen man Schachcomputer vor 15 Jahren in Bausch und Bogen verdammt hätte...

Event:
Ort:
Datum:

Weiss:
Schwarz:

Ergebnis
Board

Alle schwarzen Züge stammten hier aus den Nalimovs, und Weiß benutzte offenbar keine.
Parent - By Benno Hartwig Date 2009-07-14 14:35
[quote="Michael Scheidl"]...Einige typische Endspielschwächen betreffen m.E. vor allem fehlendes Wissen(*) im (sehr) späten Endspiel...
*) Es ist in der Tat frustrierend, im Jahre 2009 derartige Lücken in einer "Ubermensch"-Engine hinnehmen zu sollen, derentwegen man Schachcomputer vor 15 Jahren in Bausch und Bogen verdammt hätte...[/quote]
Zustimmung!
Auch wenn dies in praktischen Spielen nur wenig Auswirkung bringt:
Es kommt mir so vor, als hätte ein nagelneuer TFT-Monitor mit tollster Auflösung, Geschwindigkeit und Kontrast (Wow!) irgendwo in Eckennähe einen leuchtend roten Pixelfehler 

"Ja, aber es kommt echt nur gaanz selten vor, dass gerade da was ist, was man unbedingt sehen möchte!"

Benno
Parent - - By Urs Maier Date 2009-07-14 02:25
tablebases haben erwiesenermaßen keinerlei einfluß auf die spielstärke der programme. wieso dies immer und immer wieder angeführt wird, ist mir ein rätsel.
mit keinerlei einfluß meine ich weit unter 20 elo. zu dieser feststellung bedürfte es nichtmal einer testreihe, das läßt sich auch einfach abschätzen.
selbst wenn theoretisch komplette 8-steiner z.B. auf einer solid state disk vorhanden wären, macht das nie und nimmer 50 elo aus.
endspieldatenbanken haben für menschen eine weit größere (wissenschaftliche) bedeutung als für engines.
Parent - - By Michael Scheidl Date 2009-07-14 03:27
Der Einfluß wird möglicherweise unterschätzt, weil bzw. wenn man "in Computerschachkreisen" üblicherweise

1. mit Tablebases spielen läßt - man also gar nicht weiß welchen Murks eine Engine u.U. ohne Tbs. machen würde, und

2. selbst ohne (oder mit weniger) Tablebases Matts oft gar nicht ausgespielt werden müssen, weil mit Aufgeben gespielt wird.

Es hängt auch sehr von der jeweiligen Engine ab, d.h. welche wieviel "internes" Wissen und möglicherweise ein paar interne Endspieltables hat. Ich würde da Hiarcs und Rybka 3 als Gegensatzpaare bezeichnen.
Parent - - By Urs Maier Date 2009-07-14 12:52
ach was, es gab doch umfangreiche tests und einen artikel, der auch hier im forum genannt wurde. in diesem wurde z.B. der nutzen von 5 steinern auf einem stick mit dem von 5 steinern auf einer festplatte verglichen.

im rybkaforum findest du sicher auch verweise auf tests, in denen immer wieder herauskommt, daß kein! nutzen der TBs nachweisbar ist.

da wird dann schon nicht "mit aufgeben" getested worden sein .
Parent - By Urs Maier Date 2009-07-14 13:12
folgender test ergab einen viel höheren wert der EGTBs, als andere tests. allerdings dürfte das hauptsächlich auf die feste tiefe von 8 ply zurückzuführen sein.
bei 15 ply sinds dann vielleicht statt +13 auch mal -5 elo, die die TBs "bringen".
vielleicht hat von euch ja jemand lust diesen test mit 9 ply zu wiederholen!? ich selber hab nicht so viele TBs (und brauche meinen PC).

Final Report (von bnc im rybkaforum)
----------------

I have finished the EGTB test of 10,000 games . Rybka 3 with EGTB's 3-4-5 and 180gb 6man has defeated Rybka 3 without EGTB's in a single CPU fixed depth 8ply match:               
                
   Rybka 3  EGTB       +2064/=6237/-1699   51.83%   5182.5/10000
   Rybka 3  no EGTB  +1699/=6237/-2064   48.18%   4817.5/10000

This match favored the EGTB engine by 13 ELO

For the next 10,000 game test , the setup will be the same except that the GUI tablebases option will be enabled.

Setup
--------
Time control - fixed depth 8 ply
System - Intel i7-920 @2.67ghz , hyperthreading disabled
RAM - 6gb
CPUs - 1 thread per engine
Engine - Rybka 3
Engine hash - 512mb
EGTB hash - 32mb
Engine tablebases - 3-4-5-6 man (180gb 6man)
GUI tablebases - none
Nalimov usage - "Never" for one engine and "Normal" for the other
Opening book - large private book, learning functions disabled, variety at 75%
Engine match options - alternating colors
Game options - Resign : never and Draw : never
OS - Vista x64
GUI - Chessbase Rybka 3 (version May 4 2009)
Parent - By Michael Scheidl Date 2009-07-14 20:52
Du definierst Nutzen nur über Elo? Meistens behandelst Du doch sozusagen schachlich-inhaltliche Aspekte.

Wie gesagt, es gibt verschiedene Arten von Anwendern und mich ärgert, wenn Computerschach etwa gegenüber Anfängern und Einsteigern ein "seltsames" Bild abgibt, wie oben in der Antwort an Kurt geschildert. Statt eines Nutzens durch mehr Elo finde ich wesentlich wichtiger, daß ein Schachprogramm - in der Default-Installation ohne erst Insiderzeugs studieren zu müssen - beispielsweise in der Schulschachgruppe als verläßlicher Übungsgegner für solche elementaren Sachen dienen kann. Daß etwas keine Elo bringt, ist dann kein Trost wenn die Engine das nicht kann.

Das war auch bis vor kurzem praktisch selbstverständlich (zumindest für kommerzielle Schachsoftware), bis aus mir unverständlichen Gründen bei einigen Fans(?) niedrige Qualitätsstandards "Einzug gehalten" haben, wo man plötzlich bereit ist Dinge zu tolerieren, die aus meiner Sicht grotesk sind. Wie gesagt, wäre sichergestellt daß per default mindestens die 3+4-Steiner mitinstalliert werden, läge der Fall wiederum anders. Aber das ist ja nicht der Fall.

Was die diversen Tests betrifft, so hat mich bisher methodisch keiner davon überzeugt, weil soweit ich weiß keiner alle relevanten Parameter variiert bzw. verglichen hat. Auch die Hashgröße spielt beispielsweise mit, die Art des Datenträgers, usw. usf., alles mögliche. Auch halte ich nichts davon, das mit kompletten Partien zu testen. Das eigentlich ein methodischer Wahnsinn, weil ja dann geschätzte 80% oder 90% der Resultate und der aufgewendeten Testzeit überhaupt nichts mit Stellungen zu tun haben, die mit Tablebases zu tun haben. Das ganze ist noch nicht wirklich umfassend und methodisch überzeugend gemacht worden.

Daß Rybka 3 hingegen eine Stellung KB-K welche aufgrund der Opposition in ihrer elementarsten Form remis ist, mit über +3 bewertet, ist eine klare und einfache Diagnose. Soll man das hinnehmen, weil die Kur dieser "Krankheit" möglicherweise keine Elo bringt? Oder - oh Schreck oh Schreck - vielleicht 10 Elo kostet, von einem Elovorsprung auf die Konkurrenz der ein Mehrfaches davon ausmacht. Was sind das für Prioritäten?! Bugs tun ein übriges; ich habe Rybka 3 immer noch nicht.

Ich warte bei Software gerne auf den ersten Patch, bevor ich kaufe.
Parent - - By Urs Maier Date 2009-07-14 13:38
ich wollte jetzt doch selber noch einen test mit ply 6 machen, mußte aber feststellen, daß es in aquarium keine option gibt, die anzeige der partien auf dem schachbrett auszuschalten. damit wird das match massiv ausgebremst, weil die partien graphisch angezeigt werden müssen. mit welcher GUI ist das anders möglich?
Parent - - By Ingo Bauer Date 2009-07-14 21:33
Hallo

Ich habe das gerade mal durchprobiert und es scheint in der Classic zu gehen indem man einfach das Boardfenster abschaltet. Vielleicht hilft der Hinweis ja.

Ansonsten ist Rybka (meines Wissens alle Versionen) ein denkbar ungeeigneter Kanditat für diesen Test, da er sich nicht an die Vorgaben der Plytiefe hält.

Bsp:

Plytiefe auf 3 (bei 5 passiert das selbe) gesetzt.

Hier das Spiel als Shootout, also Rybka 3 gegen Rybka 3:

[Event "?"]
[Site "?"]
[Date "2009.07.14"]
[Round "?"]
[White "?"]
[Black "?"]
[Result "*"]

1. Nf3 {+0.09/3 0s} Nf6 {+0.13/3 0s} 2. Nc3 {+0.09/3 0s}
Nc6 {+0.07/3 0s} 3. d3 {+0.07/3 0s} d6 {+0.07/3 0s} 4. h3
{+0.09/3 0s} h6 {+0.03/3 0s} 5. Be3 {+0.09/3 0s} e5 {0.00/3
0s} 6. g4 {-0.06/3 0s} Be7 {-0.13/3 0s} 7. Qd2 {+0.06/3 0s}
O-O {-0.05/3 0s} 8. O-O-O {-0.05/3 0s} Nb4 {+0.05/3 0s}
9. Kb1 {+0.06/3 0s} a5 {+0.03/3 0s} 10. a3 {+0.06/3 0s}
Nbd5 {-0.14/3 0s} 11. Rg1 {-0.14/3 0s} Nxc3+ {-0.20/3 0s}
12. Qxc3 {-0.06/3 0s} Be6 {-0.20/3 0s} 13. g5 {+0.02/3 0s}
Nd5 {+0.05/3 0s} 14. Qd2 {+0.22/3 0s} Nxe3 {+0.22/3 0s}
15. Qxe3 {+0.21/3 0s} hxg5 {+0.23/3 0s} 16. Nxg5 {+0.23/3
0s} Bxg5 {+0.23/3 0s} 17. Rxg5 {+0.23/3 0s} Ra6 {+0.23/3
0s} 18. Bg2 {+0.23/3 0s} Rb6 {+0.43/3 0s} 19. Be4 {+0.43/3
0s} f5 {+0.43/3 0s} 20. Rdg1 {+0.43/3 0s} Rf7 {+0.63/3 0s}
21. Rh5 {+0.62/3 0s} Qf6 {+0.64/3 0s} 22. Rh6 {+0.81/3 0s}
Qe7 {+0.81/3 0s} 23. Bh1 {+0.81/3 0s} a4 {+0.75/3 0s}
24. Qg3 {+1.49/3 0s} d5 {+1.77/3 0s} 25. Qxe5 {+1.77/3 0s}
d4 {+2.01/3 0s} 26. Ka1 {+1.96/3 0s} Qd6 {+1.96/3 0s}
27. Qxd6 {+1.98/3 0s} Rxd6 {+1.98/3 0s} 28. Bxb7 {+1.94/3
0s} Re7 {+1.94/3 0s} 29. Bf3 {+1.97/3 0s} Kf8 {+1.97/3 0s}
30. Rhg6 {+2.09/3 0s} f4 {+2.13/3 0s} 31. h4 {+2.20/3 0s}
Rd8 {+2.09/3 0s} 32. h5 {+2.30/3 0s} Bd5 {+2.44/3 0s}
33. h6 {+2.29/3 0s} gxh6 {+2.56/3 0s} 34. Rxh6 {+2.56/3 0s}
Rg7 {+2.72/3 0s} 35. Rh8+ {+2.72/3 0s} Bg8 {+2.72/3 0s}
36. Rxg7 {+2.75/3 0s} Kxg7 {+2.75/3 0s} 37. Rh4 {+2.75/3
0s} Rf8 {+2.75/3 0s} 38. Be4 {+2.75/3 0s} Be6 {+2.75/3 0s}
39. Rh7+ {+2.75/3 0s} Kf6 {+2.75/3 0s} 40. Rxc7 {+2.75/3
0s} Rg8 {+2.39/3 0s} 41. c4 {+2.39/3 0s} dxc3 {+2.39/3 0s}
42. bxc3 {+2.39/3 0s} Rg1+ {+2.39/3 0s} 43. Kb2 {+2.39/3
0s} Rf1 {+2.39/3 0s} 44. f3 {+2.39/3 0s} Re1 {+2.74/3 0s}
45. c4 {+2.74/3 0s} Rxe2+ {+2.84/3 0s} 46. Kc3 {+2.84/3 0s}
Re3 {+2.74/3 0s} 47. Ra7 {+3.02/3 0s} Bf7 {+3.03/3 0s}
48. Rxa4 {+3.40/3 0s} Bg8 {+3.63/3 0s} 49. Ra6+ {+3.80/3
0s} Ke5 {+3.96/3 0s} 50. a4 {+3.94/3 0s} Be6 {+3.94/3 0s}
51. Rb6 {+3.94/3 0s} Bh3 {+3.94/3 0s} 52. Rb5+ {+3.99/3 0s}
Kd6 {+3.99/3 0s} 53. a5 {+4.56/3 0s} Bc8 {+4.72/3 0s}
54. a6 {+4.89/3 0s} Bxa6 {+5.07/3 0s} 55. Rb6+ {+5.07/3 0s}
Ke5 {+5.07/3 0s} 56. Rxa6 {+5.07/3 0s} *

(Wie man sehen kann alles 3 Ply als Enigneausgabe. Bei +5 Bewertung abgebrochen, ist aber egal)

So und jetzt mal ein paar Züge der Enineausgabe:

Engine:
  3.00   0:00   +5.07   54...Bxa6 55.Rb6+ Ke5 56.Rxa6 Rxd3+ 57.Kb4 Rd7 58.c5 Rd4+ 59.Kb5 (4) 4
best move: Bc8xa6 time: 0:00.015 min  n/s: 6.144  nodes: 6


Bitte nachzählen ...

Okok, da sind Schlagzüge und Schachgebote drin, ein Programmierer würde vielleicht von gewissen Zwängen (das machen viele Engines so!) sprechen also hier ein anderes Bsp:

Engine:
3.00   0:00   +0.05   8...Nb4 9.Kb1 a5 10.a3 (1) 1
best move: Nc6-b4 time: 0:00.031 min  n/s: 2.048  nodes: 2


Wenn ich richtig Zähle sind das 4 Plys. Interessant auch das Rybka dafür 2 (ZWEI) Nodes zählt Da schneidet aber jemand ganz gewaltig am Baum rum ...

Noch ein interessantes Bsp:

Engine:
  2.00   0:00   +2.09   31...Rd8 32.h5 (0)
  3.00   0:00   +2.09   31...Rd8 32.h5 (1) 1
best move: Rd6-d8 time: 0:00.016 min  n/s: 1.024  nodes: 1


2 Plys, in 1 einem Node. Ich bin begeistert!

und hier die Krönung:

Engine:
  2.00   0:00   +2.44   32...Bd5 (0)
  3.00   0:00   +2.44   32...Bd5 (0)
best move: Be6-d5 time: 0:00.000 min


1 Ply in 0 Nodes - Phantastisch!

Ich fürchte, weil bei Rybka wirklich weder Nodes noch Plys stimmen, ist die Enigne für solche Test völlig ungeeignet.

Gruß
Ingo
Parent - - By Urs Maier Date 2009-07-14 21:53
ist doch ganz egal wie rybka die plys zählt. es geht lediglich darum genug partien zu sammeln, um eine statistische aussage treffen zu können.
meinetwegen entspricht dann ply 6 in rybka tatsächlich 9 ply. für den test wär das irrelevant.

noch lieber wäre mir aber, wenn man die zeit/zug beliebig festlegen könnte. geht das evtl. mit arena oder in der shredder GUI? also z.B.
0,02 sek/zug.
Parent - By Ingo Bauer Date 2009-07-14 22:56
Hallo

Nein, so kkurze Zeitkontrollen läßt die Classic nicht zu. Ich weiß auch nicht ob solche kurzen Zeiten nicht im Protokoll overhead (Völlig egal welches Protokoll) untergehen.

Bei 0.02 hast du auch probleme wenn eine Engine auf die Tbs zugreifen soll. In 0.02 haben die meisten Platten nicht mal ihre Köpfe positioniert, von laden oder suchen ganz zu schweigen ... Auch USB Sticks sehen da nur minimal besser aus.

Und was das Rybka gegen Rybka angeht weißt du nie ab vielleicht gerade die Engine mit Tbs weniger "besch...", da sie anders sucht ... und deswegen verliert dann verliert. Das Ergebniss hat zu viele Unbekannte! Ich halte Rybka für ungeeignet. Am besten wäre noch eine Open Source Engine der Such- und Zählverhalten bekannt und kontrollierbar ist aber auch da halte ich das ganze für sehr schwierig zu implementieren ...

Gruß
Ingo
Parent - - By Michael Scheidl Date 2009-07-15 01:17
Vorsicht, fixe Rechentiefe ist für einen Tablebase-Test ein problematischer, m.E. ungeeigneter Ansatz: Denn in der Praxis, also wenn Bedenkzeit- bzw. eventuell auch Analysezeitvorgaben den Rahmen setzen, wird ja innerhalb dessen die erreichbare Rechentiefe durch einen Tablebasezugriff - je nach konkreten Umständen - beeinflußt. Ich denke das kann in die eine oder andere Richtung gehen, aber genau diese Auswirkung würde ja durch die Fixierung der Rechentiefe ausgelöscht.

Kurz gefaßt, wenn man die Auswirkung von etwas testen will, darf man nicht einen Teil der Auswirkung verhindern indem man diesen auf dieselbe Größe zwingt.

Gerade im späten Endspiel sieht man in Computerpartien oft gewaltige Unterschiede der RT. bei gleichen oder sehr änlichen Engines - und zwar signifikant größere als im Mittelspiel, also nicht durch Hardwareunterschied erklärlich - was darauf schließen läßt daß nur eine Tbs. nutzt. Die Bewertungen bestätigen es oft. Eigentlich führt also eine Fixierung auf gleiche Rechentiefe den Test ad absurdum.

Meines Erachtens muß man für beide Seiten dieselben "normalen" Ressourcen (= identische CPU, -Cores, Zeitrahmen, Hashgröße) einstellen.

Zur Verdeutlichung: Jemand wolle beispielsweise den Stärkeeinfluß von Hardware vergleichen. Auf fixer, gleicher Rechentiefe wären zwei indentische Engines gegeneinander auf ganz verschieden schnellen Computern logischerweise gleich stark (natürlich wäre der Zeitbedarf unterschiedlich). Das eignet sich also nicht, um "externe" Faktoren zu vergleichen.

Des weiteren spielt es sicher eine große(!) Rolle, ob man  (A) keine Tbs. nur mit (B) allen 3/4/5/6-Steinern vergleicht, oder auch nur (B.1) 3/4er und (B.2) 3/4/5er in den Vergleich miteinbezieht.
Parent - - By Roland Rösler Date 2009-07-15 08:43
Hallo Michael,

daß mag alles richtig sein was Du sagst (das das der falsche Testansatz ist), aber bevor man gar nichts hat macht man erstmal das was machbar ist und schaut sich die Ergebnisse genau an.
Voraussetzungen, um bei einem solchen Test überhaupt brauchbare Ergebnisse zu bekommen sind folgende:
1. Viele Spiele (~10.000) um den Unterschied sauber herausarbeiten zu können. Bei Bedenkzeit 1'+1" pro Engine (~ 4 Minuten gesamt) dauert so ein Durchlauf 4 Wochen (wahrscheinlicher 3 Wochen) auf einem Core.
2. Alle sonstigen Bedingungen gleich bis auf EGTB (ob nur 3-4-5 Steiner oder 3-4-5-~10% (die wichtigsten) 6-Steiner ist dabei irrelevant).
3. Gespielt wird bis zum bitteren Ende (kein Aufgeben, keine Remisvereinbarung, kein GUI EGTB der das Spiel beendet (für die NO EGTB Engine)).

Was hat bnc (im Rybkaforum) bisher erreicht mit seinen Partien R3 sp ohne EGTB vs. R3 sp mit EGTB bei Tiefe 8:
1. Er hat 10.000 Partien (5.000 Paarungen s/w) gespielt mit breitem EB (ohne Dubletten) und das Ergebnis war 51,8% (~13 Elo) über alle Partien.
2. Der Zeitverbrauch (CPU time) von R3 sp EGTB ist ~2,5% höher (d.h. in einer Stunde 90 Sekunden zusätzlich).
3. Noch nicht bestätigt: In Partiepaarungen die identisch bis zum 10 Steiner verliefen (~40%) macht R3 sp EGTB ~53% (+21 Elo).

So, wer jetzt Zweifel hat, darf alles anders machen:
1. Er spielt 1000 Paarungen (2000 Spiele) von 10 Steinern (am besten kreiert von normalen Spielen) und schaut sich die Ergebnisse bei Bedenkzeit von 3'+2" an (Inkrement ist wichtig, damit die EGTB überhaupt geladen werden können!).
2. Er spielt 2500 Paarungen (5000 Spiele) mit breitem EB (keine Dubletten!) bei Bedenkzeit von 3'+2".
3. Er spielt 1000 Paarungen (2000 Spiele) mit breitem EB (keine Dubletten!) bei Bedenkzeit 40/1+20/2+rest 3'+2".

Alle Ergebnisse sind willkommen. Rybka3 Ergebnisse sind besonders interessant, weil R3 die beste Engine ist und möglicherweise besonders schlecht ohne EGTB spielt (d.h. im Vergleich schlechter als andere Engines). Und weil R3 den mp EGTB Bug hat und m.E. ohne EGTB spielt auf Cluster oder 8-core Maschinen auch wenn sie zugeschaltet sind.

Gruss Roland
Parent - By Michael Scheidl Date 2009-07-15 09:58
[quote="Roland Rösler"]
2. Der Zeitverbrauch (CPU time) von R3 sp EGTB ist ~2,5% höher (d.h. in einer Stunde 90 Sekunden zusätzlich).
[/quote]

Das ist ein Kernpunkt bezüglich der Verwendung fixer Rechentiefen. Wie Du schreibst (und ich muß zugeben mir die Tests von bnc nicht genau angesehen zu haben und sie erst gestern - mit Schrecken - entdeckt habe), waren das hier 8 Halbzüge.

(Somit sprechen wir auch sicherlich nicht von einer Stunde je Partie.)

In der Praxis sehen wir aber große RT.-Unterschiede, wenn offensichtlich eine Engine Tbs. nutzt und die andere nicht. Relativ klein sind diese noch, wenn die Tbs.- Engine wegen des Bremseffektes schlechter auf Tiefe kommt. Aber ganz nahe Tbs.-Material sind sie oft sehr groß zugunsten der Tbs.-Engine. Wir sprechen hier von zweistelligen Tiefen, normalerweise 20+. Also, wenn die Tbs.-Engine auf 30 kommt und die nicht Tbs.-Engine auch auf 30 kommen soll, ist der Unterschied des Zeitverbrauchs garantiert "astronomisch" höher als 2,5%...

Das kann man also so nicht seriös testen. - Aufgrund obiger Überlegung vermute ich, daß "tendenziell" die Tbs.-Engine durch die Fixierung der RT. stark benachteiligt wird, denn in einem 8-Steiner oder weniger, unter normalen Bedenkzeitstufen, läuft sicherlich oft deren Rechentiefe der Nicht-Tbs.-Engine um ein Mehrfaches davon.

So einen schweren Logikfehler bei einem Computerschach(*)-Testaufbau habe ich bisher noch nie gesehen. Ich kann nicht umhin, die Resultate vollkommen zu ignorieren. 

*) Von anderen Bereichen und derartigen Fehlern wollen wir nicht ausführlich reden, Stichwort Tschernobyl. M.a.W. das ist ein Test-GAU.

Natürlich gebe ich mich nicht der Hoffnung hin daß der Einwand mehrheitlich akzeptiert oder auch nur verstanden wird, aber Deiner sehr guten Empfehlung zufolge soll ich ja eher nach oben schauen. Somit war das die Botschaft und bei wem sie nicht ankommt, der ist selber schuld. Ich verwende weiterhin mein ausgefeiltes Subset an Nalimovs vom USB-Stick und lächle in mich hinein.
Parent - - By Georg Hutschenreuter Date 2009-07-15 10:42
Hallo Roland!
[quote="Roland Rösler"]
Hallo Michael,

Voraussetzungen, um bei einem solchen Test überhaupt brauchbare Ergebnisse zu bekommen sind folgende:
1. Viele Spiele (~10.000) um den Unterschied sauber herausarbeiten zu können. Bei Bedenkzeit 1'+1" pro Engine (~ 4 Minuten gesamt) dauert so ein Durchlauf 4 Wochen (wahrscheinlicher 3 Wochen) auf einem Core.

So, wer jetzt Zweifel hat, darf alles anders machen:
1. Er spielt 1000 Paarungen (2000 Spiele) von 10 Steinern (am besten kreiert von normalen Spielen) und schaut sich die Ergebnisse bei Bedenkzeit von 3'+2" an (Inkrement ist wichtig, damit die EGTB überhaupt geladen werden können!).
2. Er spielt 2500 Paarungen (5000 Spiele) mit breitem EB (keine Dubletten!) bei Bedenkzeit von 3'+2".
3. Er spielt 1000 Paarungen (2000 Spiele) mit breitem EB (keine Dubletten!) bei Bedenkzeit 40/1+20/2+rest 3'+2".

Gruss Roland
[/quote]
Dass bei diesen Bedenkzeiten die Endspieldatenbanken keinen relevanten Einfluss haben glaube ich sofort. Wie soll bei diesen Bedenkzeiten auf die Ednspieldatenbanken zugegriffen werden können? Die Züge geschehen doch viel zu schnell. Bis die Partien in der Nähe der Endspieldatenbanken sind, haben sie gemäß der angeführten Bedenkzeiten nur noch eine bis zwei Sekunden Bedenkzeit pro Zug. Und darin auch noch auf die Datenbanken zugreifen? Wie soll das vernünftig möglich sein? Es werden ein paar wenige irrelevante Endspielsteiner geladen in den Bruchteilen der Sekunde. Das soll als Beweis her halten, dass Endspieldatenbanken nichts bringen? Halte ich für völlig ungeeignet.
Parent - By Michael Scheidl Date 2009-07-15 12:34
Es ist schön zu sehen, daß mindestens ein - aber möglicherweise viel zahlreichere - Computerschachkenner meiner Kritik zustimmen. Was hier abläuft ist in der Tat absurd. Rykbas Konkurrenten werden sich einen Ast ablachen: Gratulation!!
Parent - - By Joachim Rang Date 2009-07-14 21:01
[quote="Urs Maier"]
selbst wenn theoretisch komplette 8-steiner z.B. auf einer solid state disk vorhanden wären, macht das nie und nimmer 50 elo aus.
[/quote]

Hm, 8-Steiner auf solid state disk, hui das dauert noch ein Weilchen und vermutlich hast Du recht, dass macht trotzdem keine 50 Elo aus. Vermutlich aber 20 Elo, also bestimmt so viel, dass man das zumindest messen kann, wobei vielleicht auch nicht. Wie lange wir darauf wohl noch warten müssen?
Parent - By Urs Maier Date 2009-07-14 21:03
20 jahre? oder länger?
Up Topic Hauptforen / CSS-Forum / Verbesserungspotenzial bei aktuellen Top-Engines

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill