Ok, ich sehe schon, wer ELO will, holt sie sich. Und das in Andreas Ursprungsthread unisono die Meinung herrscht, dass man die Knotenleistung/sec nicht in ELO umrechnen, hält einen nicht nur davon ab, das trotzdem zu tun, nein, jetzt wird sogar noch der Quotient zweier Skalierungsfaktoren unterschiedlicher Engines gebildet, aus dem man dann Vorhersagen für den Ausgang TCEC-Matches prophezeit. Eigentlich will ich hier ja wirklich niemandem den Spaß am Glaskugellesen verderben, aber eine kleine Anmerkung muss ich doch loswerden:
Zitat:
Und im Zweifelsfall sind doch diese Knotenanzeigen, die man über viele Züge in vielen Stellungen/Partien bei realen Partien angezeigt bekommt, für mich das Maßgebliche. Und wenn ein Laborexperiment diesbzgl. stark abweichende Daten liefert, dann ist da m.E. große Skepsis angebracht.
Das fand ich sehr amüsant formuliert. Stellungen nach n Zügen sind also "real" die Stellung vor dem 1. Zug ist ein Laborexperiment. Werden dann die sich ergebenden Stellung in einer Partie von Zug zu Zug realer? Eigentlich dachte ich immer, dass die Grundstellung die "realste" aller Stellungen ist, denn sie kommt als Einzige aller Stellungen ja in jeder Partie vor.
Nein, im Ernst, ich glaube schon zu wissen, wie du das eigentlich meinst, und deine Beobachtung hat natürlich ihre Ursache. Die wird Benno aber gar nicht gefallen, denn da hast du einen der vielen Gründen, warum man nps nicht vernünftig in ELO umrechnen kann aufgedeckt: Andreas' Skalierungsfaktoren sind nämlich u.A. stellungsabhängig, und in deinen Messungen, hast du im Vergleich zu Andreas' nps-Zahlen diesbezüglich eine schon numerisch viel breitere Basis. Die Grundstellung ist bzgl. einer wenn es um nps und deren Skalierungsfaktoren auf SMP geht, offensichtlich nicht sehr representative Stellung. Die algorithmischen Unterschiede zwischen SF und Komodo bei der Suchbaumbeschneidung treten hier deutlicher zu Tage, als in einer "durchschnittlichen" Stellung aus dem Partieverlauf. Gründe hierfür könnten in dem nicht-taktischen Charakters der Grundstellung und der sich daraus ergebenden Konsequenzen für die Skalierungsfähigekeit der
in Komodo und SF werkelnden Algorithmen sein. Da müsste man nun wirklich tief in den Code einsteigen, aber z.B. könnte SF untypisch lange in schlecht skalierbaren Baumkürzungsoperationen unterwegs, während der ohnehin schon weniger kürzende Komodo nun multi-thread-aware auch noch extrabreit unterwegs ist, hier einfacheres Spiel hat? In der IDeA-Analyse bei Aquarium kann man sich übrigens sehr schon mit der Thematik beschäftigen, dort hat man
viele Stellschrauben was die Suchparameter und Baumstruktur angeht, und bekommt die Skalierungsauswirkungen dann im Superzeitlupentempo vor Augen geführt.
Das gilt natürlich nur für den dort implementierten Suchalgorithmus und hoffentlich kommt auch keine auf die Idee nun eine ELO für Aquarium ausrechnen zu wollen
gruß
roland