|
||||||||||||
![]() Hm, ok, nach etwas Nachdenken ein Versuch der Analyse und gleichzeitig Versuch einer kleinen Erklärung für alle, die vielleicht nicht ganz so tief drin stecken (werde versuchen, programmierspezifische Fachausdrücke zu vermeiden oder ggf. zu erklären):
"ply" = Halbzug, in obigem Fall aktuelle Rechentiefe Fail-Low: Ich gehe davon aus, daß auch Kaplan, wie zu der Zeit schon allgemein üblich, mit eingeschränkten Erwartungsfenstern (alpha..beta) gearbeitet hat. Heißt, nach Abschluß der Rechentiefe 3 ist das Programm nicht mit einer Erwartungshaltung von -Unendlich bis +Unendlich an die Rechentiefe 4 herangegangen, sondern mit einer Erwartungshaltung (einem alpha..beta "Fenster") um die -0.97 herum, die sich aus Tiefe 3 ergeben hatte. Die Suche mit Tiefe 4 hat dann ergeben, daß die Bewertung deutlich unter -0.97 liegen wird, konnte aber aufgrund des eingeschränkten Fensters keinen exakten Wert liefern => ein sogenannter Fail-Low. Daraufhin wird die Suche auf der gleichen Tiefe noch einmal mit vergrössertem Erwartungsfenster neu gestartet, um die exakte Bewertung zu ermitteln. Kostet natürlich viel Zeit, wenn so etwas passiert, aber im Allgemeinen (immer dann, wenn es keinen Fail-Low oder Fail-High gibt) bringt das eingeschränkte Erwartungsfenster einen ganz enormen Zeitgewinn. So, was nun natürlich passiert sein könnte: Hashtabellen wird Kaplan wohl noch nicht verwendet haben, aber sicherlich zumindest Killerzüge und History-Tabellen, die damals auch schon üblich waren, evtl. weitere Infos, die von ply zu ply weitergereicht und z.B. für die Zugsortierung verwendet werden. Wenn das Programm nun wirklich einen Fail-Low hatte, eine neue Berechnung gestartet hat und diese dann mittendrin abgebrochen hat, dabei aber evtl. schon eine Bewertung von unter -5.00 ermittelt hatte, und Kaplan seine Tabellen nicht oder nicht alle zwischen den Zügen leert, dann kann es eben doch sein, daß im nächsten Zug schon auf Rechentiefe 1 der Fehler gefunden wird. (Falls nicht geleerte Hashtabellen im Spiel sind allerdings unter Umständen mit einer falschen Bewertung, die aber zumindest schon näher an der Wahrheit liegt) Und daß er die schlechte Bewertung das letzte Mal, als er am Zug war, nicht schon direkt auf Tiefe 3 bemerkt hat, wird irgendeiner Form der Selektivität zu "verdanken" sein. Ist trotzdem ein unschönes Phänomen. Muss aber nicht, wie in meiner Überschrift ursprünglich geschrieben, ein wirklicher "Bug" sein. Die Krux beim D++ ist, daß es nicht wirklich tief kommt in seinen Berechnungen, der 6 MHz Prozessor ist einfach zu langsam für dieses Programm. Bei 30 Min/Partie kommt er oft nur 3-4 Halbzüge tief. Das ist in verwickelten Positionen dann doch gelegentlich zu wenig, vor allem wenn der Gegner mit einer halbwegs stabilen Suche 5-6 Halbzüge tief kommt... So, jetzt spiele ich noch das "Rückspiel" MMV - D++ und dann haue ich mich in's Bett ![]() Viele Grüße, Heiko ![]() |
|
||||||||||||
AW: Saitek D++ - Bug?
Die zweite Partie endete übrigens Remis, also:
D++ 6MHz - MMV 0.5 - 1.5 Viele Grüße, Heiko ![]() |
|
||||||||||||
AW: Saitek D++ - Bug?
Hallo Heiko,
ja der D++ spielt schon sehr Rätselhaft (zumindest gegen andere Computer), meiner Opferte öfter völlig unangebracht und verlor dementsprechend schlimm. Das konnte der Superconny seinerzeit aber viel besser. Gegen Menschen allerdings spielt der D++ sehr interessant und aktiv. Gruß Otto |
|
||||||||||||
AW: Saitek D++ - Bug?
Hallo Otto und Heiko,
hat zwar eigentlich nicht direkt mit dem Thema zu tun.... wenn ich das noch richtig in Erinnerung habe, dann spielt Heiko's D++ mit der "normalen" Bibliothek oder ? Mir ist nach meiner Umrüstung des Turboking auf TK II aufgefallen, dass er mit Schwarz auf e4 fast nur noch mit c5 antwortet (ganz selten mal c6) und soweit ich weiss, sollte der Turboking II in etwa der D+ Version entsprechen. Würde mich jetzt mal interessieren, Otto, spielt die D++ Version auch mit einer sozusagen stark "eingeschränkten" Bibliothek?, was die Auswahl der Eröffnungen betrifft ? Viele Grüße Uwe |
|
||||||||||||
AW: Saitek D++ - Bug?
könnt ihr mal überprüfen ob die merkwürdigen züge auch mit der bibi passieren die eigentlich zum dpp dazugehört ?
ich meine mich erinnern zu können das das programm des dpp nicht in die 32K paßten und ein paar algos in den bibi baustein mußten. wenn der dann aber gegen eine andere bibi ausgewchselt wird könnte es sein das was am hauptprogramm fehlt.
__________________
Die ganze Welt des Computerschachs |
|
||||||||||||
AW: Saitek D++ - Bug?
![]() ich meine mich erinnern zu können das das programm des dpp nicht in die 32K paßten und ein paar algos in den bibi baustein mußten. wenn der dann aber gegen eine andere bibi ausgewchselt wird könnte es sein das was am hauptprogramm fehlt.
Obwohl ich ehrlich gesagt erwarten würde, daß das Programm abstürtzt, wenn es versucht Routinen anzuspringen, die nicht da sind. Aber was natürlich sein kann, daß die Routinen zur Bibliotheks-Zugauswahl im Bibliotheks-Eprom stecken. Ich werde mir noch mal ein paar Eproms bestellen, und dann mal die zum D++ gehörige Bibliothek brennen! Viele Grüße, Heiko ![]() |
|
||||||||||||
AW: Saitek D++ - Bug?
B6M_614.BIB sollte es sein, bei D+ und D++
__________________
Die ganze Welt des Computerschachs |
|
||||||||||||
AW: Saitek D++ - Bug?
Yoyo, hab ich ja schon auf'm Rechner, hab mir ja alles original bei Dir gesaugt
![]() Nur mein blöder Brenner hatte mir ja damals alle Eproms zerbrannt, bis ich das Netzteil gewechselt habe, und dann war keins mehr für die Eröffnungsbibliothek übrig, es hat gerade noch für das D++ und das Endspiel-Eprom gereicht... Viele Grüße, Heiko ![]() |
![]() |
Themen-Optionen | |
Ansicht | |
|
|