Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / die "multiplikative-MV-Doppelengine"
- - By Benno Hartwig Date 2013-12-22 12:44
Mich würde ja auch die Spielstärke einer 'Doppelengine' interessieren.
Gemeint ist hier:

  2 Engines (beispielsweise Stockfish und Houdini)
  beide rechnen mit MV=5
  Infrage kommen nur Züge, die beide Engines zu den Top 5 Rechnen.
  Und gewählt wird der Zug, bei dem das Produkt aus beiden Bewertungen maximal ist.

Vermutlich gewinne ich hier keine Stärke.
Aber ist das sicher?

Benno
Parent - - By Guest Date 2013-12-22 13:23
damit schaltetest du falls eine engine wirklich den lösungszug gefunden hat definitiv aus. 1x0=0
Parent - - By Benno Hartwig Date 2013-12-22 19:34
Stimmt!
Addieren fand ich halt auch blöd, weil z.B. Stockfish dann dank seiner großen Bewertungen dann den Partner unterbuttern würde.
Da müsste ein andere Mechanismus her, um aus 2 Werten einen zu machen.
Benno
Parent - - By Michael Scheidl Date 2013-12-22 21:05
Stockfish ist als ein Sonderfall bekannt, sodaß man SF.-Evals/2 benutzen könnte. Dann könnte einfach das arithmetische Mittel gezogen werden, sodaß Null-Bewertungen kein prinzipielles Problem wären. Ein Problem ist eher, daß sich Züge durchsetzen können wo eine Engine stark falsch liegt, und der Zug es bei der zweiten gerade noch in die Top-5 schafft.

Mir scheint nach diesem Konzept auch eine Konfiguration "Drei Engines, MultiPV(3)" interessant. Aber es sind eher theoretische Überlegungen, denn wird uns das je einer programmieren? Weiters kommen mir spontan Zweifel, ob dann nicht nur auf dem kleinsten gemeinsamen Nenner gespielt wird, was nicht vielversprechend klingt.

Ein interessantes Experiment wäre es aber auf jeden Fall.
Parent - By Michael Hoeppenstein Date 2013-12-22 21:30
Ich denke, diese Vorgehensweise verzerrt das Ergebnis, da hier eine willkürliche Gewichtung vorgenommen wird. Man müsste die Bewertungen der verschiedenen Schachmotoren aufeinander abstimmen (z.B. auf Houdini eichen mit Hilfe verschiedener ausgewählter Positionen) um mit dem arithmetischen Mittel arbeiten zu können.
Parent - - By chess wendicus Date 2013-12-22 13:42
Vergleich zu Politik: Die beste Lösung kann in einer Demokratie niemals durchgesetzt werden!
Parent - - By Benno Hartwig Date 2013-12-22 19:37
Ja, einfach so 'Demokratie' war nicht mein Gedanke.

Ich dachte eher:
Oftmals werden beide Engines die Züge ähnlich bewerten. Dann macht diese Idee nichts kaputt.
Aber falls eine was Tolles entdeckt, dann bekommt dieser Zug sein Plus.
Und falls eine was Böses wittert, dann bekommt der Zug sein Minus, und es wird ggf. ein anderer genommen, den beide anständig finden.

Aber ggf. war das Ganze auch wirklich nur eine dumme Idee.
Benno
Parent - - By chess wendicus Date 2013-12-22 20:10
Aber Du must doch abstimmen, welchen Zug du spielen willst. Einer muss entscheiden, damit wären wir wieder beim Dreihirn! 
Parent - By Benno Hartwig Date 2013-12-23 17:35
Dafür will ich ja eine feste vorher definierte Regel.
In der Partie sollten nur noch die Engines sprechen und diese Regel gelten.
Benno
Parent - - By Michael Hoeppenstein Date 2013-12-22 20:24
Hallo,
Ein Problem entsteht, wenn einer der Schachmotoren die Stellung mit 0,00 bewertet. Dann ist das Produkt ebenfalls null. Zur Berechnung müsste man jeweils einen kleinen Offset - vielleicht +0,001 - addieren.
Grüße, Michael
Parent - - By Thomas Plaschke Date 2013-12-23 08:56
Die Produktbildung birgt noch einen Stolperstein: - mal + = - und - mal - = +.
Oder?
Gruß
Th. Plaschke
Parent - By Chess Player Date 2013-12-23 10:25
Das gäbe aber lustige Partien...Schade, dass wir sie niemals zu sehen bekommen...
Parent - By Michael Hoeppenstein Date 2013-12-23 17:17
Hier wäre die Mittelwertbildung doch besser...
Parent - - By Benno Hartwig Date 2013-12-23 17:33
Schon Guests Posting hatte mich ünerzeugt, dass 'multiplizieren' nicht taugt.
Und du hast sicher Recht: mit dem + und - würde es ganz irre.


Vielleicht ist die Idee einer automatischen Zugwahl aus zwei Engine-Analysen kompletter Unsinn.
Auf jeden Fall taugt Multiplizieren (ich dachte halt an geometrisches Mittel) nicht,
das addieren (mit Gedanken an das arithmetische Mittel) will mir aber auch nicht gefallen.
Was könnte ggf. taugen? Gar nichts?

Benno
Parent - - By Michael Hoeppenstein Date 2013-12-23 18:26
Wie wäre es mit dem harmonischen Mittel x_harm = n/(1/x_1 + ... + 1/x_n)?
Parent - - By Klaus Meier Date 2013-12-23 22:25 Edited 2013-12-24 10:57
Wähle den Zug, dessen Bewertung Null am nächsten kommt !
z.B.:
Engine1 zeigt als stärksten Zug Sf3 mit Bewertung +3.5
Engine2 zeigt .........................Lf3 mit Bewertung +2,5
-->
2,5 kommt Null am nächsten
-->
Lf3
Parent - - By Chess Player Date 2013-12-24 12:36
Oder so?

Engine1 zeigt als stärksten Zug Sf3 mit Bewertung +3.5
Engine2 zeigt .........................Lf3 mit Bewertung -2,5

-2,5 kommt Null am nächsten 

Das ist es auch nicht!
Parent - By Klaus Meier Date 2013-12-24 12:57
Chess Player schrieb:

Oder so?

Engine1 zeigt als stärksten Zug Sf3 mit Bewertung +3.5
Engine2 zeigt .........................Lf3 mit Bewertung -2,5

-2,5 kommt Null am nächsten 

Das ist es auch nicht!


nee Engine1 tappt mit Sf3 (+3.5) in eine Falle. Matt in 17 Zügen nach Sf3 !
hatt Engine1 übersehen.

Engine2 hat mit Lf3 (-2.5) immerhin noch eine Verteidigung gefunden... so ist das ! 
Parent - By Peter Martan Date 2013-12-30 08:36 Edited 2013-12-30 08:40
Entschuldige, Benno, ich hab diesen thread jetzt erst gelesen, weil ich auch gerade wieder mit MV herumexperimentiere.
Ähnliche Ansätze wie du hatte ich früher auch schon und bin damals für mich selbst zum Schluss gekommen, dass die Quotienten aus den verschiedenen Evals der verschiedenen Züge des MV einer und derselben engine mir am meisten sagen.
Wie auch schon Michael (mir scheint sowohl Hoeppenstein als auch Scheidl früher mal ) zum 0.00- Wert meinte, nehme ich dann, um nicht eventuell durch 0 dividieren zu müssen, 0.01 als Plus- oder Minuswert statt dessen, je nachdem, ob das Vorzeichen des Dividenden + oder - ist, so bleibt das Vorzeichen im 0.00-Output immer +, so lange kein realer -0.01-Output daraus wird, und der gröstmöglich negative Wert (somit der kleinste ) ergibt sich immer erst dann, wenn man einen positiven durch einen sehr kleinen negativen Wert dividiert.
Mir scheint das keine Verzerrung sondern eine Abbildung derjenigen schachlichen Realität, dass die am stärksten zählenden  Evalunterschiede nahe 0 sein sollten, wenn ein noch so kleiner Vorteil der einen Seite zu einem Nachteil wird, die Stellung also wörtlich kippt.
Hast du jetzt eine relativ große numerische Stockfish- Eval für den erstgereihten MV- Zug und eine nicht viel kleinere für den nächsten, sollte der genannte Quotient der beiden ein vergleichbares Ergebnis liefern zu dem bei einer anderen engine, die numerisch beide kleiner bewertet, aber ebenso nahe beisammen.
Schlägt bei einer engine die Eval von klein positiv zu klein negativ um zwischen den beiden in Frage kommenden MV- Zügen einer engine, sollte sich so tatsächlich durch den Vorzeichenwechsel ein stärker zählender Quotient ergeben als bei zwei ebenfalls kleinen aber im Vorzeichen gleich bleibenden Zügen einer anderen engine.

BTW wäre das auch ein Ansatz zu dem früheren Problem (warst das auch du?) mit dem "Remisvermeidungscontempt", in Stellungen mit nahe beinander liegenden Evals von Kandidatenzügen könnte er automatisch höher gesetzt werden, hast du keine ähnlich stark bewerteten Evals, wird die Wahrscheinlichkeit steigen, dass das Remis tatsächlich lieber angesteuert werden sollte.

Ich würde übirgens solche Experimente niemals mit ganzen Partien statistisch untersuchen wollen, sondern immer nur als Stellungstest einzelner Stellungen und Varianten.
Mehr noch als im MV- Mode interessiert mich diese ganze Rechnung in Hinblick auf den Verlauf von Evalveränderungen über die der Halbzüge einer bestimmten Variante hinweg. Auch hier zählen ja Evalveränderungen viel mehr als ihre einzelnen numerischen Werte.
Up Topic Hauptforen / CSS-Forum / die "multiplikative-MV-Doppelengine"

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill