Vergleich 1-, 2-, 4-CPU

By Ingo Bauer Date 2009-09-01 11:44 Edited 2009-09-01 11:52

Hallo Gerhard

[quote="Gerhard Sonnabend"]

(http://www.husvankempen.de/nunn/blitz.htm)

[/quote]

Schöner Vergleich den man weiterspinnen kann (Auch wenn die Datenabasis SEHR dünn ist)

Die durchschnittliche Enigne gewinnt von 1 auf 2 = 72.8 Elo, und von 2 auf 4 54.3 Elo. (Der Durchschnittsgewinn von 1 auf 4 ist 127.1 Elo)

Geht man von einer linearen Abnahme aus ist der duchschnittliche Gewinn von 4 auf 8 Kerne 35,8 Elo und von 8 auf 16 bei 17.3 Elo. Das deckt sich mit der Annahme das manche Engine schon bei 8 Kernen nichts mehr gewinnen, von 16 Kernen ganz zu schweigen.

Sollte diese Annahme jemandem Plausibel erscheinen, kann er sich selber ausrechnen ob z.B:

1. 36 Elo den doppelten/dreifachen Preis von 4 auf 8 (echte) Kerne rechtfertigen oder
2. 4 zusätzliche HT Kerne (bei 50% Knotenmehrleistung) mit 18 Elo Plus (Elos sind nicht linear, aber so übern Daumen), das Risiko wert sind diese auch einzusetzen.

Nette Statistik, danke Gerhard.

Gruß
Ingo

PS: Wer will kann sich ausrechnen bei wieviel Kernen Fritz und Bright besser werden als Rybka

By Ingo Bauer Date 2009-09-01 12:03

Hallo

Vergessen:

1. Wenn ich von "dünner" Datenbasis rede, dann meine ich die Tatsache das es sich nur um 10 Engines handelt - de fakto ist sie allerdings wahrscheinlich die beste Datenbasis die existiert auf diesem Planeten!

2. Sollte die Abnahme der Elos nicht linear sein, so sollte sie doch mit der verwendeten Technik gegen Null streben. Bitte diese Tabelle nicht mit Cluster Engines mixen, da Cluster nach anderen Prinzipien programmiert werden.

Gruß
Ingo

By Horst Wandersleben Date 2009-09-01 13:21

Hallo Ingo,
die zahlen in der tabelle geben mathematisch weder indizien für das eine noch das andere modell.
Beachte bitte, dass bei zwei engines die 1-2CPU-differenz kleiner ist als die 2-4CPU-differenz. Bei einer engine sind die werte fast gleich.
Da bräuchte man mindestens die 4-8CPU-differenz, um halbwegs eine mathematische gesetzmäßigkeit feststellen zu können.
Vielleicht würden die erwähnten engines nochmal eine steigerung von über 60 Elo hinlegen können.
Viele grüße
Horst

By Gerhard Sonnabend Date 2009-09-01 12:12

Hi Ingo !

[quote="Ingo Bauer"]
Schöner Vergleich den man weiterspinnen kann (Auch wenn die Datenabasis SEHR dünn ist)

Die durchschnittliche Enigne gewinnt von 1 auf 2 = 72.8 Elo, und von 2 auf 4 54.3 Elo. (Der
Durchschnittsgewinn von 1 auf 4 ist 127.1 Elo)

Geht man von einer linearen Abnahme aus ist der duchschnittliche Gewinn von 4 auf 8 Kerne
35,8 Elo und von 8 auf 16 bei 17.3 Elo. Das deckt sich mit der Annahme das manche
Engine schon bei 8 Kernen nichts mehr gewinnen, von 16 Kernen ganz zu schweigen.

Sollte diese Annahme jemandem Plausibel erscheinen, kann er sich selber ausrechnen ob z.B:

1. 36 Elo den doppelten/dreifachen Preis von 4 auf 8 (echte) Kerne rechtfertigen oder
2. 4 zusätzliche HT Kerne (bei 50% Knotenmehrleistung) mit 18 Elo Plus (Elos sind nicht linear,
aber so übern Daumen), das Risiko wert sind diese auch einzusetzen.

Nette Statistik, danke Gerhard.
PS: Wer will kann sich ausrechnen bei wieviel Kernen Fritz und Bright besser werden als Rybka

[/quote]

Danke für Deine Ausführungen.

Zusätzlich würde ich behaupten, dass bei längeren Bedenkzeiten die "Gewinne"
noch geringer ausfallen würden. Evtl. ist da schon bei 4-8CPU Schluss ?!
Ich muss mal nachsehen, ob ich für 40/20 oder 40/40 genügend Material
zusammen bekomme.

Viele Grüsse,
G.S.

By Benno Hartwig Date 2009-09-01 12:36

[quote="Ingo Bauer"]Geht man von einer linearen Abnahme aus ist der duchschnittliche Gewinn von 4 auf 8 Kerne 35,8 Elo und von 8 auf 16 bei 17.3 Elo. Das deckt sich mit der Annahme das manche Engine schon bei 8 Kernen nichts mehr gewinnen, von 16 Kernen ganz zu schweigen.[/quote]
Ggf. trifft diese Annahme einer 'linearen Abnahme' doch nicht so gut.
Mir erscheint (zugegeben: aus dem Bauch heraus) realistischer, dass hier ungefähr ein gleicher Faktor gelten könnte:
54,3 / 72,8 = 0.75

Dann wäre beim Übergang von 4 auf 8 Kerne zu erwarten ein Plus von 41 ELO
und beim Übergang von 8 auf 16 Kerne immer noch ein Plus von ca. 30 ELO.
und beim Übergang von 16 auf 32 Kerne immerhin noch ein Plus von ca. 22 ELO...

Gibt es Gründe, die konkret für oder gegen das 'lineare Modell' oder das eben von mir vorgeschlagene Modell sprechen?

Benno

By Ingo Bauer Date 2009-09-01 14:32

Hallo Benno

[quote="Benno Hartwig"]
[quote="Ingo Bauer"]Geht man von einer linearen Abnahme aus ist der duchschnittliche Gewinn von 4 auf 8 Kerne 35,8 Elo und von 8 auf 16 bei 17.3 Elo. Das deckt sich mit der Annahme das manche Engine schon bei 8 Kernen nichts mehr gewinnen, von 16 Kernen ganz zu schweigen.[/quote]

Ggf. trifft diese Annahme einer 'linearen Abnahme' doch nicht so gut.
Mir erscheint (zugegeben: aus dem Bauch heraus) realistischer, dass hier ungefähr ein gleicher Faktor gelten könnte:
54,3 / 72,8 = 0.75

Dann wäre beim Übergang von 4 auf 8 Kerne zu erwarten ein Plus von 41 ELO
und beim Übergang von 8 auf 16 Kerne immer noch ein Plus von ca. 30 ELO.
und beim Übergang von 16 auf 32 Kerne immerhin noch ein Plus von ca. 22 ELO...

Gibt es Gründe, die konkret für oder gegen das 'lineare Modell' oder das eben von mir vorgeschlagene Modell sprechen?

Benno
[/quote]

Ich habe das "lineare Model" gewählt weil es einfacher zu rechnen ist! Ich selber würde auch eher davon ausgehen das sich der Trend etwas verlangsamt, insofern könnte ich statt mit 36 auch gut mit deinen 41 Elo leben.
Ich bin allerdings davon überzeugt das praktisch alle Engines irgendwann KEINEN Zuwachs mehr hätten und im Gegenteil sogar schlechter würden (siehe HT). Insofern glaube ich eher nicht an einen fixen Faktor. Es gibt wohl auch ein paar Papers im Netz, die, aufgrund theoretischer Überlegungen, von abnehmendem Grenznutzen ausgehen. Das übsteigt dann aber sowohl mein Interesse, als auch mein Können - wobei das fehlende Können wohl ursächlich für das fehlende Interesse ist.

Gruß
Ingo

By Benno Hartwig Date 2009-09-01 13:20

[quote="Ingo Bauer"]Die durchschnittliche Enigne gewinnt von 1 auf 2 = 72.8 Elo[/quote]
Wenn ich den effektiven Performancefaktor mit ungefähr 1,7 annehme, dann könnte man aus diesen Ergebnissen aber schließen, dass heute eine Verdopplung der Rechengeschwindigkeit schon ca 80 ELO (oder noch mehr?) an Stärkegewinn gibt.
(eher etwas mehr, als ich dachte)

Benno

By Ingo Bauer Date 2009-09-01 14:42

Hallo

[quote="Benno Hartwig"]
[quote="Ingo Bauer"]Die durchschnittliche Enigne gewinnt von 1 auf 2 = 72.8 Elo[/quote]
Wenn ich den effektiven Performancefaktor mit ungefähr 1,7 annehme, dann könnte man aus diesen Ergebnissen aber schließen, dass heute eine Verdopplung der Rechengeschwindigkeit schon ca 80 ELO (oder noch mehr?) an Stärkegewinn gibt.
(eher etwas mehr, als ich dachte)

Benno
[/quote]

Hmm, ob du die "1 auf 2 auf 4 CPU" Daten technisch relevant auf "von 1 auf 2 auf 4 GHz" umlegen kannst ist meines Wissens unbewiesen (muß aber nicht falsch sein) Allerding gab es seit Jahren keine echte MHz/GHz Verdopplung mehr - dazu kommen noch andere CPU Typen - ich vermute mal die Annahme 60, 70, 80 Elo wird noch lange eine Annahme bleiben.

Gruß
Ingo

By Horst Wandersleben Date 2009-09-01 13:11

Hallo Gerhard,
danke für diese aufschlussreiche aufstellung.
Sie zeigt deutlich wie nie, dass die wirkung von hardware sehr begrenzt ist.
Viele grüße
Horst

By Gerhard Sonnabend Date 2009-09-01 13:40

Hallo Horst !

[quote="Horst Wandersleben"]
Hallo Gerhard,
danke für diese aufschlussreiche aufstellung.
Sie zeigt deutlich wie nie, dass die wirkung von hardware sehr begrenzt ist.
Viele grüße
Horst
[/quote]

Zum grossen Teil sicherlich zutreffend. Jedoch gibt es "Ausreisser",
welche ein Aufrüsten durchaus sinnvoll erscheinen lassen.
Aber wie bereits geschrieben triff das wohl nur noch für Blitzspielstufen zu.

Viele Grüsse,
G.S.

By Gerhard Sonnabend Date 2009-09-01 14:28

Hier die Tabelle mit den selben Engines, jedoch gespielt für die
CEGT-40/20-Ratingliste. Lediglich eine einzige Engine (Naum 4.0 x64 1CPU)
hat noch nicht für die 40/20-Liste gespielt.

(http://www.husvankempen.de/nunn/rating.htm)

Für mich eine Überraschung !
Aber gleichzeitig auch wieder mal eine Bestätigung, dass die
diversen Spielstufen nicht miteinander verglichen werden können.

Die Steigerung von 2- auf 4-CPU ist durchschnittlich grösser
als die von 1- auf 2-CPU. Immerhin 4 Engines scoren besser; eine
genau gleich. Ob das nun an der geringeren Anzahl an Partien
liegt kann ich (fast) nicht glauben. Immerhin sind auch bei
diesem Vergleich meist 600-3000 Games in der Wertung, durch-
schnittlich sind es 1330 Games pro Engine.

Viele Grüsse,
G.S.

By Ingo Bauer Date 2009-09-01 14:58

Hallo Gerhard

[quote="Gerhard Sonnabend"]

[/quote]

Für die anderen Engines sollen berufenere sprechen, aber für Shredder habe ich im Laufe der Jahre doch soviel mitbekommen das, sosehr diese beiden Ergebnisse auch dem allgemeinen Vorurteil "Shredder skaliert schlecht" wiedersprechen, ich weiß das es nicht stimmen kann. Auch wenn ich die 99 Elo Gesamtgewinn nicht bezweifeln will ist der eine Sprung zu groß und der andere zu klein (Oder der Erste stimmt und der Zweite ist viel zu klein). Woran liegts: Entweder zu wenig Spiele oder an der Methodik. Ansonsten wäre es auch so das Shredder (und mit ihm der Enginedurchschnitt) auf 8 CPUs noch besser würde. Von 16, 32, 64 will ich nicht reden. Wer will darf wieder fragen wann Shredder Rybka überholt ...

Schade das du die Tabelle veröffentlicht hast. Alles was jetzt bewiesen ist ist, dass ich mich mit der "Pseudemathematischen Betrachtung" auf ganz dünnem Eis bewege!

Gruß
Ingo

By Benno Hartwig Date 2009-09-01 16:18 Edited 2009-09-01 16:22

[quote="Gerhard Sonnabend"]Für mich eine Überraschung ![/quote]
Für mich auch! Thanx!
Da diskutieren wir weiter oben, in welchem Maße die Spielstärkesteigerung abnimmt, wenn die Kernzahl wiederholt verdoppelt wird,
und da kommst du und belegst, dass sie gar nicht abnimmt, dass sie sogar steigt!

Dass die Effizienz tatsächlich steigt, glaube ich natürlich nicht. Vielleicht nimmt sie aber tatsächlich nicht so fix ab, wie es die Blitz-Tabellen vermuten ließen. Vielleicht haben wir doch auch noch bei 8 oder 16 Kernen eine gute Performancesteigerung.
Eigentlich möchte ich dies auch vermuten. Vas hat dies hier doch bestimmt mal analysiert. Er steckt ja immerhin einen erheblichen Aufwand in die Clusterei hinein. (Ob der Aufwand mit den Clustern lohnt angesichts der Tatsache, dass soweit ich weiß nicht irgendwie angedacht ist, dies zu einem käuflichen Feature zu machen, bleibt offen.) Und wenn er lohnende Performancesteigerungen erwartet bei Nutzung von mehreren vernetzten Rechnern, dann sollte diese Steigerung bei vielen Kernen in einem Rechner eher noch mehr erwartet werden.

Benno

By Gerhard Sonnabend Date 2009-09-02 10:46

Hi Benno !

[quote="Benno Hartwig"]
[quote="Gerhard Sonnabend"]Für mich eine Überraschung ![/quote]
Für mich auch! Thanx!
Da diskutieren wir weiter oben, in welchem Maße die Spielstärkesteigerung
abnimmt, wenn die Kernzahl wiederholt verdoppelt wird, und da kommst du
und belegst, dass sie gar nicht abnimmt, dass sie sogar steigt!

[/quote]

Na ja, als Beleg würde ich es nicht bezeichnen. Besser vielleicht als
"kleinen Trend" mit einigen Unsicherheiten, welcher bei der z.T. geringen
Partienanzahl noch sowohl in die eine als auch in die andere Richtung
ausschlagen könnte.

Ich wollte gerade eine Aufstellung aus der CCRL 40/40 Liste generieren.
Leider haben die viel zu wenig Spiele und auch bei weitem nicht alle Engines
"im Angebot".

Bei Rybka 3 x64 hat die CCRL übrigens auch einen grössener Sprung von
2- auf 4-CPU als von 1- auf 2-CPU zu vermelden. Allerdings hat die 2-CPU
lediglich 552 Games gespielt.

[quote="Benno Hartwig"]
Dass die Effizienz tatsächlich steigt, glaube ich natürlich nicht. Vielleicht nimmt
sie aber tatsächlich nicht so fix ab, wie es die Blitz-Tabellen vermuten ließen.
Vielleicht haben wir doch auch noch bei 8 oder 16 Kernen eine gute Performancesteigerung.
[...snip...]
[/quote]

Meiner Meinung nach muss man Spiele auf Blitzstufen immer isoliert von
allen anderen (mit längerer BZ) Spielen sehen. Bei den Suchtiefen, welche
im Blitz i.d.R. erreicht werden, ist eine geringe Steigerung der Suchtiefe
sicherlich viel wirkungsvoller als wenn die Programme länger an den einzelnen
Zügen rechnen dürfen. Eine gute Zugselektion und ein gutes Zeitmanagement
hilft im Blitz bestimmt auch mehr als bei längeren Bedenkzeiten.

Viele Grüsse,
G.S.

By Kurt Utzinger Date 2009-09-02 11:58

[quote="Gerhard Sonnabend"]
Meiner Meinung nach muss man Spiele auf Blitzstufen immer isoliert von
allen anderen (mit längerer BZ) Spielen sehen. Bei den Suchtiefen, welche
im Blitz i.d.R. erreicht werden, ist eine geringe Steigerung der Suchtiefe
sicherlich viel wirkungsvoller als wenn die Programme länger an den einzelnen
Zügen rechnen dürfen. Eine gute Zugselektion und ein gutes Zeitmanagement
hilft im Blitz bestimmt auch mehr als bei längeren Bedenkzeiten.

Viele Grüsse,
G.S.
[/quote]

Hallo Gerhard
Du hast hier einen meines Erachtens ganz wichtigen Punkt angeschnitten.
Deine Aussage trifft für mich ins Schwarze.
Gruss
Kurt

By Benno Hartwig Date 2009-09-02 13:08

[quote="Gerhard Sonnabend"]Bei den Suchtiefen, welche
im Blitz i.d.R. erreicht werden, ist eine geringe Steigerung der Suchtiefe
sicherlich viel wirkungsvoller als wenn die Programme länger an den einzelnen
Zügen rechnen dürfen.[/quote]
Es ist ja nicht so, dass die Blitztiefe wirklich gering ist, oder dass die Turniertiefe so auffallend tief geht.

Als so gravierend unterschiedlich sehe ich es nicht, wenn man einerseits im Blitz-Mittelspiel die Vollsuche von vielleicht 15 auf 16 plys vergrößern kann und andererseits bei Turnierzeit von 18 auf 19 plys.
Diese Tiefen habe ich mal frech so geschätzt. Widerspruch? Zustimmung?
Es sind nur ca. 3 plys mehr (oder von mir aus: 4), aufbauend auf einer sowieso schon recht großen Tiefe.
Es ist nicht so, dass die Engine bei den 18 Plys so grundsätzlich andersartige 'Überlegungen' anstellt als bei 15 Plys. Innerhalb dieser Tiefe Vollsuche (im Wesentlichen bei allen Engines brute force?), darauf aufsetzend, und in beiden Fällen nach gleichen Kriterien selektive Spitzen (insb. Ruhesuche)
Was übersehe ich ggf.?

Zeitmanagement ist aber sicher ein interessantes Thema.
Bei Fischer-Zeit oder auch generell bei x Züge in y Minuten ist dies wohl leichter zu handhaben, da die Engine immer wieder ein Polster untergeschoben bekommt.
Bei 'Partie in x Minuten' muss anders gerechnete werden. Wenn die Zeit knapp wird, wird dies nicht wieder geheilt. Dies aber sowohl, wenn x=5Minuten als auch x=180Minuten ist.
Darin sehe ich den Hauptunterschied, weniger in der eigentlichen Länge der Zeiten.
Mit diesen echt zuende gehenden Zeiten kann halt geschickt oder weniger geschickt hantiert werden.

Benno

By Gerhard Sonnabend Date 2009-09-02 14:39

[quote="Benno Hartwig"]
[quote="Gerhard Sonnabend"]Bei den Suchtiefen, welche
im Blitz i.d.R. erreicht werden, ist eine geringe Steigerung der Suchtiefe
sicherlich viel wirkungsvoller als wenn die Programme länger an den einzelnen
Zügen rechnen dürfen.[/quote]

Es ist ja nicht so, dass die Blitztiefe wirklich gering ist, oder dass die
Turniertiefe so auffallend tief geht.
Als so gravierend unterschiedlich sehe ich es nicht, wenn man einerseits im
Blitz-Mittelspiel die Vollsuche von vielleicht 15 auf 16 plys vergrößern kann
und andererseits bei Turnierzeit von 18 auf 19 plys.
Diese Tiefen habe ich mal frech so geschätzt. Widerspruch? Zustimmung?
[/quote]

Das sehe ich anders.
Viele Engines zeigen ein total unterschiedliches Verhalten im Bezug
auf den Qutput. Vergleiche mal Rybka, Junior, Hiarcs, Stockfish und
Shredder miteinander. Der eine zeigt auf Quad (@2.4GHz) (in ein und
der selben Stellung) 12HZ, der nächste 13HZ, 15HZ oder auch nur 11HZ
Tiefe an.
Diese Angaben lassen sich nicht vergleichen.

Besser ist, was ProDeo zu bieten hat, nämlich in der Datei "search.txt".

Hier mal eine, welche aber nicht sehr viele Spiele auf dem Buckel hat,
es sind so um die 800 Games auf Level 40/20+...:

Code:


Depth           Moves                    Moves                   Moves    
               Changed                  Changed                 Changed   
             Middle Game              End Game (1)            End Game (2)

01      48518 - 40078 = 82.6%    32845 - 24704 = 75.2%    18119 - 11184 = 61.7%
02      47787 - 19968 = 41.8%    30490 - 11516 = 37.8%    17471 -  5348 = 30.6%
03      47754 - 15702 = 32.9%    30047 -  8640 = 28.8%    17159 -  4677 = 27.3%
04      47457 - 13961 = 29.4%    29122 -  7203 = 24.7%    16539 -  3214 = 19.4%
05      47399 - 13234 = 27.9%    28921 -  7156 = 24.7%    16406 -  3582 = 21.8%
06      45494 - 12469 = 27.4%    27936 -  6393 = 22.9%    15954 -  3128 = 19.6%
07      45183 - 11288 = 25.0%    27634 -  5915 = 21.4%    15798 -  2882 = 18.2%
08      42648 -  9539 = 22.4%    26856 -  5233 = 19.5%    15549 -  2422 = 15.6%
09      34762 -  7039 = 20.2%    24205 -  4235 = 17.5%    15253 -  2241 = 14.7%
10      25370 -  4580 = 18.1%    19145 -  2979 = 15.6%    14640 -  1891 = 12.9%
11      17074 -  2815 = 16.5%    13711 -  1909 = 13.9%    13176 -  1432 = 10.9%
12       7971 -  908 =  11.4%     8753 -  1073 = 12.3%    10770 -  1040 =  9.7%
13       2579 -  208 =   8.1%     4667 -   460 =  9.9%     8665 -   723 =  8.3%
14        556 -   20 =   3.6%     1887 -   136 =  7.2%     6663 -   456 =  6.8%
15        142 -    2 =   1.4%      663 -    28 =  4.2%     4597 -   253 =  5.5%
16         47 -    0 =   0.0%      254 -     4 =  1.6%     2759 -    99 =  3.6%
17         30 -    0 =   0.0%      157 -     0 =  0.0%     1736 -    54 =  3.1%
18         25 -    0 =   0.0%      101 -     0 =  0.0%     1208 -    35 =  2.9%
19         19 -    0 =   0.0%       73 -     0 =  0.0%      860 -     9 =  1.0%
20         18 -    0 =   0.0%       60 -     0 =  0.0%      672 -    18 =  2.7%
21         18 -    0 =   0.0%       52 -     0 =  0.0%      523 -     9 =  1.7%
22         17 -    0 =   0.0%       47 -     0 =  0.0%      436 -     8 =  1.8%
23         17 -    0 =   0.0%       40 -     0 =  0.0%      344 -     0 =  0.0%
24         14 -    0 =   0.0%       37 -     0 =  0.0%      272 -     3 =  1.1%
25         12 -    0 =   0.0%       34 -     0 =  0.0%      228 -     1 =  0.4%
[..snip.. / geht normal bis 60)

ProDeo ist kein Tiefbohrer, der kritische Bereich im Blitz (@2.4GHz) liegt bei
dieses Engine im Bereich von 10-13HZ. Sind allerdings noch Schwerfiguren auf dem
Brett, so tendiert die Engine eher gegen 10HZ.

Viele Grüsse,
G.S.

By Benno Hartwig Date 2009-09-02 14:58

[quote="Gerhard Sonnabend"]
Diese Angaben lassen sich nicht vergleichen.[/quote]
Thanx für die Infos.
Mit meinem Einwand wollte ich halt auch lediglich auf folgendes Hinweisen:
Auch wenn die Bedenkzeit verzehnfacht wird, wird (als grobe Schätzung für einen mittleren Wert) die Suchtiefe nur um nicht mal 3 Plys wachsen, die Suchtiefe wird ggü Blitz also nur ungefähr um knapp 20% (die Suchtiefe in den Spitzen noch weniger!) zunehmen.
Ich vermute daher eigentlich nicht, dass hier so grundsätzlich andersartige Analyseergebnisse herausspringen können.

Benno

By Gerhard Sonnabend Date 2009-09-02 15:09

[quote="Benno Hartwig"]
[quote="Gerhard Sonnabend"]
Diese Angaben lassen sich nicht vergleichen.[/quote]
Thanx für die Infos.
Mit meinem Einwand wollte ich halt auch lediglich auf folgendes Hinweisen:
Auch wenn die Bedenkzeit verzehnfacht wird, wird (als grobe Schätzung für einen mittleren Wert) die Suchtiefe nur um nicht mal 3 Plys wachsen, die Suchtiefe wird ggü Blitz also nur ungefähr um knapp 20% (die Suchtiefe in den Spitzen noch weniger!) zunehmen.
Ich vermute daher eigentlich nicht, dass hier so grundsätzlich andersartige Analyseergebnisse herausspringen können.
[/quote]

Aber gerade im kritischen Bereich (siehe Tabelle für ProDeo)
wechselt der Zug immerhin in 16.5/11.4/8.1% der Fälle.
Aber, nicht jeder Zugwechsel muss gleichbedeutend sein mit:
"besseren Zug gefunden", das ist auch klar.
Wenn ich mir allerdings den "branching factor" moderner
Engines ansehe, dann könnten/sollten bei 10-facher Bedenkzeit
mehr als 3HZ herausspringen. Ich denke 4-5 ist realistischer.

Viele Grüsse,
G.S.

By Roland Rösler Date 2009-09-02 15:20

[quote="Gerhard Sonnabend"]
Wenn ich mir allerdings den "branching factor" moderner
Engines ansehe, dann könnten/sollten bei 10-facher Bedenkzeit
mehr als 3HZ herausspringen. Ich denke 4-5 ist realistischer.[/quote]

Geht man von einem "branching factor" von 2 aus, braucht man für 3 Hz mehr die 8-fache Zeit, für 4 Hz mehr die 16-fache und für 5 Hz die 32-fache Bedenkzeit! Ein Halbzug mehr bedeutet etwa 70 Elo, die man auch erhält, wenn man die Bedenkzeit verdoppelt!
Sehe ich da irgendwas falsch? Welchen "branching factor" moderner Engines legst Du zugrunde?

By Gerhard Sonnabend Date 2009-09-02 15:30

[quote="Roland Rösler"]
[quote="Gerhard Sonnabend"]
Wenn ich mir allerdings den "branching factor" moderner
Engines ansehe, dann könnten/sollten bei 10-facher Bedenkzeit
mehr als 3HZ herausspringen. Ich denke 4-5 ist realistischer.[/quote]

Geht man von einem "branching factor" von 2 aus, braucht man für 3 Hz mehr die 8-fache Zeit, für 4 Hz mehr die 16-fache und für 5 Hz die 32-fache Bedenkzeit! Ein Halbzug mehr bedeutet etwa 70 Elo, die man auch erhält, wenn man die Bedenkzeit verdoppelt!
Sehe ich da irgendwas falsch? Welchen "branching factor" moderner Engines legst Du zugrunde?
[/quote]

Um die 1.7.
Schwank aber ein wenig je nach Stellung.

Viele Grüsse,
G.S.

By Benno Hartwig Date 2009-09-02 15:38

[quote="Gerhard Sonnabend"]Wenn ich mir allerdings den "branching factor" moderner
Engines ansehe, dann könnten/sollten bei 10-facher Bedenkzeit
mehr als 3HZ herausspringen. Ich denke 4-5 ist realistischer.[/quote]4 Plys würde erfordern, dass ein Ply mehr bereits mit der 1m78-fachen Zeit erreicht wird.
5 Plys mehr würde erfordern, dass dies bereits in der 1,58-fachen Zeit gelingt.
Durchschnittlich.
Ich finde das sportlich.
Sind wir wirklich schon so weit?

Benno

PS:
Thanx, deine Changes-Tabelle von Deo ist wirklich sehr interessant.
Den recht starken Einbruch ab ca. 13 HZ verdanken wir aber ggf. hier auch dem relativ seltenen Vorkommen dieser Tiefen.
Aber in moderaterer Form sinkt die Häufigkeit eines Zugwechsels aber tatsächlich kontinuierlich.
Mal drüber nachdenken...

By Gerhard Sonnabend Date 2009-09-02 15:52

[quote="Benno Hartwig"]
[...snip...]
PS:
Thanx, deine Changes-Tabelle von Deo ist wirklich sehr interessant.
Den recht starken Einbruch ab ca. 13 HZ verdanken wir aber ggf. hier auch dem relativ seltenen Vorkommen dieser Tiefen.
Aber in moderaterer Form sinkt die Häufigkeit eines Zugwechsels aber tatsächlich kontinuierlich.
Mal drüber nachdenken...
[/quote]

U.U. findet sich ja jemand, der seinen ProDeo schon ewig auf
der Platte hat und viele Spiele auf mind. Aktivschachlevel damit
durchgeführt hat ? Das wäre sicherlich eine sehr schöne Sache,
diese "search.txt" zu studieren.
Zum "branching factor" habe ich meine Meinung in Bezug auf
moderne Engines schon geschrieben, ca. 1.7 aber schwankend
je nach Stellung.

Viele Grüsse,
G.S.

By Roland Rösler Date 2009-09-02 04:11

[quote="Gerhard Sonnabend"]
Auch heute wieder ausdrücklich der Hinweis, dass es sich um
Spiele auf der Blitzstufe handelt und man den Vergleich nicht
ohne weiteres auf andere Spielstufen übertragen sollte/kann.[/quote]

Ich verstehe diesen Hinweis nicht! 40/4 auf single core ist 40/7 (1,75) auf dual core und 40/12 (3) auf quad und 40/20 (5) auf octo und ... Wenn Du also zwei Programme auf quad core mit 40/4 laufen lässt, kannst Du sie ebenso auf 1 core mit 40/12 laufen lassen. Was ich in der Tabelle sehe ist, daß ein Programm mit dreifacher Bedenkzeit etwa 127 Elo zulegt, d. h. eine Verdoppelung der Bedenkzeit bzw. eine Verdoppelung der Geschwindigkeit bringt hier knapp 90 Elo Punkte (bei 40/20 auf single core sind es nur knapp 70 Elo Punkte).
Beachte: Bedenkzeit sagt im CS gar nichts, wenn man nicht angibt, auf welchem Computer (# cores, GHz) gespielt wurde.

By Gerhard Sonnabend Date 2009-09-02 07:04 Edited 2009-09-02 07:08

[quote="Roland Rösler"]
[quote="Gerhard Sonnabend"]
Auch heute wieder ausdrücklich der Hinweis, dass es sich um
Spiele auf der Blitzstufe handelt und man den Vergleich nicht
ohne weiteres auf andere Spielstufen übertragen sollte/kann.[/quote]

Ich verstehe diesen Hinweis nicht! 40/4 auf single core ist 40/7 (1,75) auf dual core und 40/12 (3) auf quad und 40/20 (5) auf octo und ... Wenn Du also zwei Programme auf quad core mit 40/4 laufen lässt, kannst Du sie ebenso auf 1 core mit 40/12 laufen lassen. Was ich in der Tabelle sehe ist, daß ein Programm mit dreifacher Bedenkzeit etwa 127 Elo zulegt, d. h. eine Verdoppelung der Bedenkzeit bzw. eine Verdoppelung der Geschwindigkeit bringt hier knapp 90 Elo Punkte (bei 40/20 auf single core sind es nur knapp 70 Elo Punkte).
Beachte: Bedenkzeit sagt im CS gar nichts, wenn man nicht angibt, auf welchem Computer (# cores, GHz) gespielt wurde.
[/quote]

Hallo Roland !

Was ich damit gemeint habe ist, dass man Blitz-Ergebnisse nicht mit
z.B. Aktivschach-Ergebnissen vergleichen kann, da dies unterschiedliche
Disziplinien sind und deshalb eben unterschiedliche Resultate heraus
kommen. Natürlich unter vergleichbaren (Hardware)Bedingungen, dies
versteht sich aber von selbst, nicht wahr ?
U.U. hast Du es ja noch nie wahrgenommen: es wird sehr häufig gesagt
(behauptet), dass bereits Ergebnisse auf kurzen Bedenkzeiten ausreichen
um ableiten zu können, wie sich die Programme bei längeren Bedenkzeiten
platzieren würden. Unsere Listen (auch die der CCRL) zeigen jedoch, dass
dies nicht der Fall ist.

Beachte: Bedenkzeit sagt im CS gar nichts, wenn man nicht angibt, auf
welchem Computer (# cores, GHz) gespielt wurde.

Werfe halt mal einen Blick auf die CEGT-Seiten (deshalb auch meine Links)
und Du wirst feststellen, dass alles sehr klar und deutlich dokumentiert ist.

Viele Grüsse,
G.S.

By Benno Hartwig Date 2009-09-02 08:44 Edited 2009-09-02 08:50

[quote="Gerhard Sonnabend"]...es wird sehr häufig gesagt
(behauptet), dass bereits Ergebnisse auf kurzen Bedenkzeiten ausreichen
um ableiten zu können, wie sich die Programme bei längeren Bedenkzeiten
platzieren würden.[/quote]
Wenn einen die relativen Spielstärken bei längeren Zeiten interessieren, sind natürlich 1000 Spiele bei langen Zeiten viel besser als 1000 Spiele bei kurzen Zeiten.
Klar!
Nur ist die Zeit eine begrenzte Resource.

Und es bleibt zu überlegen, ob ggf. die für die einzelnen Engines zu erwartenden Fehler bei 100 Spielen mit langer Zeit wirklich kleiner sind als bei 1000 Spielen mit kurzer Zeit.
Ich denke, nur mit Blick auf diese Problematik könnte jemand lieber die Ergebnisse bei kurzen Zeiten als Schätzwert für Stärken bei langen Zeiten nehmen.
Und ich denke, er macht es so dann oft auch richtig, sofern er nicht wirklich die Zeit hat, eine richtig große Partienzahl bei langen Zeiten auszuspielen..

Benno

By Peter Martan Date 2009-09-02 09:40

Hallo Benno!
[quote="Benno Hartwig"]
Wenn einen die relativen Spielstärken bei längeren Zeiten interessieren, sind natürlich 1000 Spiele bei langen Zeiten viel besser als 1000 Spiele bei kurzen Zeiten.
Klar!
Nur ist die Zeit eine begrenzte Resource.

Und es bleibt zu überlegen, ob ggf. die für die einzelnen Engines zu erwartenden Fehler bei 100 Spielen mit langer Zeit wirklich kleiner sind als bei 1000 Spielen mit kurzer Zeit.
[/quote]

Die wirklich interessante Frage an den Statistiker! Außer der hardware, bei der ja auch nur bedingt Mhz x Zeit an beiden Teilen austauschbar wirklich dasselbe Produkt Gesamtzahl an berechneten kN ergibt (?), ist natürlich die hardware (Bedenkzeit)- Nutzung von engine zu engine verschieden und ich würde sagen zum Leistungszuwachs pro Zeit (hardware) einer engine sollten sehr wohl auch engine- engine matches ein und derselben engine gegen sich selbst mit Zeitvorteilen einer Seite gemacht werden. Ich glaube noch mehr als im Vergleich mit anderen engines, ist z.B. Rybka und da wieder vor allem R3 mit viel mehr Zeit (hardware)- Vorteil gegen diesbezüglich gehandicapte identische engine auszustatten, um die Remishäufgkeit, die bei R3 gegen R3 für mich eklatant höher ist als bei anderen engines, auszugleichen.
Wär ja auch logisch, die engine, die am erfolgreichsten im Suchbaum selektiert, sollte von mehr Zeit (hardware) am wenigsten und am allerwenigsten gegen sich selbst profitieren.
Machen außer mir auch andere die Beobachtung, dass im handicap- match viel Zeit gegen wenig oder ein Kern gegen 4, engines wie Fritz, Shredder, Stockfisch, bright und Toga gegen R3 realtiv besser abschneiden als R3 selbst mit Zeitvorteil gegen R3?
Natürlich auch eine Frage des Buches...

By Benno Hartwig Date 2009-09-02 09:53

Hallo Peter,

[quote="Peter Martan"]Wär ja auch logisch, die engine, die am erfolgreichsten im Suchbaum selektiert, sollte von mehr Zeit (hardware) am wenigsten und am allerwenigsten gegen sich selbst profitieren.[/quote]Wieso wäre das (das eine wie das andere) eigentlich logisch?
Ganz egal, wie konkret selektiert wird: mehr Zeit bedeutet tiefer gucken, Gewinnwege sehen, Fallen ausweichen.
Wieso sollte ein 'besonders erfolgreich selektierende Engine' hier weniger häufig Gewinnwege finden?
Ok, vielleicht weicht sie manchmal Fallen aus, die ihre Gegner sowieso mit erkläglicher Wahrscheinlichkeit eh nicht gefunden hätten. Beim Spiel gegen sich selbst wäre aber gerade dieses Fallenausweichen schon immer wichtig und sollte Vorteile bringen.

Benno

By Peter Martan Date 2009-09-02 12:38 Edited 2009-09-02 12:47

[quote="Benno Hartwig"]
Ganz egal, wie konkret selektiert wird: mehr Zeit bedeutet tiefer gucken, Gewinnwege sehen, Fallen ausweichen.
Wieso sollte ein 'besonders erfolgreich selektierende Engine' hier weniger häufig Gewinnwege finden?
Benno
[/quote]

Gewinnwege, die du nicht innert 10 Zügen siehst, siehst meiner Erfahrung nach seltener in 20 Zügen als dass du einfach in den ersten 10 was übersehen hast, was einen Gewinnweg darstellen würde.
Ich spreche von der Eröffnung und dem Mittelspiel und bin mir klar, dass Computer anders rechnen als Menschen denken, selektiert aber ein Programm schon in den ersten 20 Hz alles weg, was rechts und links der Schmalspurbahn HV wächst, wird zwar sicherer vermieden, dass in der am Ende des Tunnels noch Überraschungen durch andere engines, (im Maximalfall derselben engine) fallenstellender Weise aufgerichtet werden können, dafür ist alles, was zwar auch nicht sofort ins taktische Verderben aber zu einer einfach anderen langfristigen Planung führt, auch weg.
Würden wir den für Computerschach unpassenden Vergleich mit Strategie und Taktik weiter strapazieren, wäre die selektivere engine die erfolgreichere gewissermaßen durch weiteres strategisches planen in ihrem und dem gleichen Schema anderer engines folgenden Suchbaum, variantenreicheres Spiel müsste sich erst mit größerem Zeit (hardware)- Aufwand lohnen als bei von vornherein weniger selektiv rechnenden.
Soweit meine, zugegeben vielleicht etwas künstliche Logik hinter der aber ansonsten einfach praktischen Erfahrung, dass Rybka und rybkalike engines, (sind seit Rybka, eigentlich seit Fruit deutlich mehr geworden

) auch mit großem Zeitvorteil gegen sich selbst eher remis spielen als gegen z.B. Fritz (sagen wir bis Version 10), der von mehr Zeit und hardware meiner Meinung nach mehr profitiert relativ.
Dass sich das nicht in Statistik R3 gegen Fritz 10 allein beweisen lässt, liegt meiner Meinung nach einfach daran, dass bei geringerer Remishäufigkeit natürlich nicht nur die Zahl der Siege sondern auch die der Niederlagen steigt und höchst wahrscheinlich Fritz insgesamt in der Eloauswertung immer noch nicht so viel von mehr Zeit profitiert, als Ryba im direkten match der beiden, trotzdem wäre Fritzens Erfolg gegen sich selbst höher bei gleichem handicap als der Rybkas.
So gesehen kann es der Wahrheits- (Varianten- ) Findung sehr wohl immer wieder mal dienen, außer Rybka auch andere engines zuzuziehen, das wissen wir ja alle.
Diesen Grenznutzen, den man ab einer gewissen hardware- Zeitaufwandskurve aus einer noch so erfolgreichen (gegen die anderen engines) Einzelengine zieht, kann man meiner Meinung nach daher beobachten und so begründen, mein ich halt.

Und um es auf den Punkt zu bringen: wenn Fritz gegen Rybka durch mehr Zeit nicht besser punktet als Ryba gegen Rybka, trotzdem aber gegen andere engines und vor allem gegen sich selbst, ist seine hardware- Bedenkzeitnutzung besser als die von Rybka, nur nicht in einer Sammelstatistik in der immer alle engines gleich häufig gegen alle anderen (noch dazu meistensn gegen Rybka ja doch noch etwas häufiger

) antreten.

By Benno Hartwig Date 2009-09-02 15:15

[quote="Peter Martan"] selektiert aber ein Programm schon in den ersten 20 Hz alles weg, was rechts und links der Schmalspurbahn HV wächst, wird zwar sicherer vermieden, dass in der am Ende des Tunnels noch Überraschungen durch andere engines, (im Maximalfall derselben engine) fallenstellender Weise aufgerichtet werden können, dafür ist alles, was zwar auch nicht sofort ins taktische Verderben aber zu einer einfach anderen langfristigen Planung führt, auch weg.[/quote]
Ist es denn so, dass Engines innerhalb der Vollsuche, die ja normalerweise auch schon im Blitzen vielleicht Tiefen von 15 erreicht, irgendwas wegselektieren?
Echte Selektion (bzw. Vertiefung) setzt doch erst danach ein, oder liege ich da falsch?

[quote="Peter Martan"] Soweit meine, zugegeben vielleicht etwas künstliche Logik hinter der aber ansonsten einfach praktischen Erfahrung, dass Rybka und rybkalike engines, (sind seit Rybka, eigentlich seit Fruit deutlich mehr geworden

) auch mit großem Zeitvorteil gegen sich selbst eher remis spielen als gegen z.B. Fritz (sagen wir bis Version 10), der von mehr Zeit und hardware meiner Meinung nach mehr profitiert relativ.[/quote]
Rybka hat meiner Meinung nach vor allem eine bessere Positionsbewertung.
Und Rybka spielt nicht risikoreich, sie wartet eher darauf, dass ihr Gegner, wegen seiner schlechteren Positionsbewertung, etwas zulässt, was sie dann erkennt und ausnutzen kann.
Es mag sein, dass dieses risikoarme Warten gegen eine nur zeit-gehandicapte Rybka3 weniger zum Erfolg führt, dass die Remis häufig bleiben.

Aber solche Handicap-Fragen finde ich auch interessant:
Fritz11 20sec/Zug - Fritz11 60sec/Zug
Rybka3 20sec/Zug - Rybka3 60sec/Zug
"Sind die Vorteile vergleichbar groß"

oder auch:
Wieviel Verbesserung erhält man im Spiel gegen Rybka3 bei 20 Sec/Zug
beim Übergang von Fritz11 20sec/Zug auf 60sec/Zug
und
Wieviel Verbesserung erhält man im Spiel gegen Fritz11 bei 60 Sec/Zug
beim Übergang von Rybka3 20sec/Zug auf 60sec/Zug
"Steigern sich Fritz11 und Rybka3 in ähnlichem Maße?"

Benno

By Peter Martan Date 2009-09-02 15:55

[quote="Benno Hartwig"]
Ist es denn so, dass Engines innerhalb der Vollsuche, die ja normalerweise auch schon im Blitzen vielleicht Tiefen von 15 erreicht, irgendwas wegselektieren?
Echte Selektion (bzw. Vertiefung) setzt doch erst danach ein, oder liege ich da falsch?
[/quote]

Du magst schon recht haben, dass das "sharpening" der HV erst nach den Blitzbedenkzeiten so richtig greift aber dass bis dahin nix wegselektiert wird, glaub ich nicht. Schau dir mal die vielen Zugzwangbeispiele an, bei denen man erst so richtig sieht, mit wieviel nullmove schon in den ersten Zügen gearbeitet wird heutzutage.
Und dann: um die Suchtiefen gerade nach den kurzen Bedenkzeiten, geht es natürlich erst recht. Das Dilemma ist ja, dass du zwar (selbst das, was R3 angibt +gute 3HZ bei den anderen) 15 gleich hast, über 21 aber (im Mittelspiel) dann auch mit sehr viel mehr Zeit kaum noch kommst. Was da noch gefunden wird oder nicht, das ist schon früher gefunden oder abgeworfen worden oder wird erst bei den viel späteren Suchtiefen gefunden, obwohl es viel näher liegt aber bis dahin immer wieder verworfen wurde. Das Ganze ist da deshalb so kompliziert, weil es eine reine Frage der Suchreihenfolge ist, dass die erste Zahl in der angegebenen Suchtiefe wirklich brute force war, ist lang vorbei, spätestens seit Fritz 10 auch bei Fritz.

[quote="Benno Hartwig"]
Rybka hat meiner Meinung nach vor allem eine bessere Positionsbewertung.
Und Rybka spielt nicht risikoreich, sie wartet eher darauf, dass ihr Gegner, wegen seiner schlechteren Positionsbewertung, etwas zulässt, was sie dann erkennt und ausnutzen kann.
Es mag sein, dass dieses risikoarme Warten gegen eine nur zeit-gehandicapte Rybka3 weniger zum Erfolg führt, dass die Remis häufig bleiben.
[/quote]

Genau deiner Meinung, ich halte Rybka, genauer R3 auch längst nicht mehr für die selektivste unter den selektiven engines, im Gegenteil, man soll nur sehen, wie die Suchtiefe (-angaben) langsamer werden, wenn es irgendwie taktisch verwickelt wird, diese Maschine rechnet nicht nur erstens wahrscheinlich sehr viel mehr Stellungen in der Zeit als andere, sondern sehr wohl auch sehr viel mehr reine Taktik dabei, nicht umsonst ist sie eine der besten, wenn nicht die beste Problemlöserin, wenn's nicht gerade um Zugzwang- und Endspielstudien geht.
Risikoarm spielt sie aber sehr wohl auch. Ich glaube, sie kann sogar das am besten von den vielen Dingen, die sie auch gut kann: das Spiel auf Varianten einschränken, die berechenbar bleiben, statische von dynamischen Stellungen unterscheiden, wie auch immer sie das macht und da wo kein Fortschritt zu erzielen ist, wenig rechnen, dafür die kritischen sehr schnell sehr tief.
Natürlich ist dabei die Bewertung der Witz aber nach Lipnitzky ist nur die Bewertung einer statischen Stellung ohne weitere Variantenberechnung sinnvoll, alles an Dynamik muss bis zu einer statischen Position am Ende der jeweiligen Variante berechnet werden, so irgendwie muss sie das wohl verstanden haben.

Durch diese Ökonomie des Rechnens schafft sie das einmalige Zeitmanagement, dafür schaut über einer gewissen Bedenkzeit weniger und weniger neues bei ihr raus, meinem Gefühl nach. Während andere engines in wenig dynamischen Stellungen noch nach Stunden den best move immer wieder ändern, passiert das bei R3 kaum.
Was nicht ins Schema passt, wird nicht berechnet, außergewöhnliche Stellungen lässt sie möglichst nicht aufs Brett kommen, setzt man sie ihr (eine andere engine, die dafür natürlich erst recht lang braucht) vor, ist sie selten aber doch zu überraschen.

[quote="Benno Hartwig"]
Aber solche Handicap-Fragen finde ich auch interessant:
Fritz11 20sec/Zug - Fritz11 60sec/Zug
Rybka3 20sec/Zug - Rybka3 60sec/Zug
"Sind die Vorteile vergleichbar groß"

oder auch:
Wieviel Verbesserung erhält man im Spiel gegen Rybka3 bei 20 Sec/Zug
beim Übergang von Fritz11 20sec/Zug auf 60sec/Zug
und
Wieviel Verbesserung erhält man im Spiel gegen Fritz11 bei 60 Sec/Zug
beim Übergang von Rybka3 20sec/Zug auf 60sec/Zug
"Steigern sich Fritz11 und Rybka3 in ähnlichem Maße?"
[/quote]

Ja Benno, interessante Fragen, ich meinte allerdings mehr wirklich relevante Zeitunterschiede: lass mal R3 mit 15 Hz (was du als schon noch irgendwie Blitz- oder Rapid auch meiner Meinung nach einschätzt, bei R3 muss man schon eher 14 nehmen, bei 15 (in Wirklichkeit ja wahrscheinlich mindestens 18) lässt sie sich manchmal schon ganz schön Zeit, gegen R3 mit 19 Hz einige Mittelspiele ausspielen, je nachdem wie schnell sich die Figuren halt aufbrauchen, mit 30 Zügen limitiert und dann wundere dich mit mir darüber, wie selten dabei die Stellung schon aus dem Gleichgewicht kommt, je nachdem, was für ein Buch du halt verwendest.
Und dann probier das mit anderen engines, natürlich kann man auch Fritz 10 19 HZ machen lassen und R3 14, erfolgreicher wird R3 gegen sich selbst sein, mehr action hast du mit Letzterem.

By Urs Maier Date 2009-09-03 10:58 Edited 2009-09-03 11:03

Zitat:

Ist es denn so, dass Engines innerhalb der Vollsuche, die ja normalerweise auch schon im Blitzen vielleicht Tiefen von 15 erreicht, irgendwas wegselektieren?
Echte Selektion (bzw. Vertiefung) setzt doch erst danach ein, oder liege ich da falsch?

was??

vollsuche 15 ply? du bist lustig! grobe schätzung: 30^15 = 1,4 *10^22

dafür braucht rybka auf nem core2duo genauso lang wie es die erde gibt. (wenn man der n/s anzeige glaubt)

By Peter Martan Date 2009-09-03 11:26

Eben, netter Vergleich.
Drum ist ja der Unterschied zwischen dem, was da an erster Stelle in der HZ- Angabe steht und brute force buchstäblich eine ziemliche Angabe, die Rajlich dadurch, dass er wieder ein paar HZ abzieht, nur sehr bedingt ausgleicht. Bei Fritz 6 war das vielleicht noch so, dass er die erste Stelle an HZen wirklich brute force berechnet hat, deshalb ist er ja im Problemlösen immer noch ganz schön gut, seither ist das aber ein Wert, von dem eigentlich keiner mehr weiß, was er bei den engines heißt, die man nicht selber programmiert (oder gecloned) hat.

Und drum sind auch soviele Taktik- Aufgaben mit Nullzug und oder forward pruning ausgeschaltet von vielen Programmen schneller lösbar als mit default Einstellungen. Selbst Zappa, der ja relativ wenig selektiv ist, hat werkseitig sowohl ein forward pruning als auch einen Nullzug- Algorithmus in den Optionen, die man abwählen kann. Und bei den meisten der schnellen Selektierer bringt auch deshalb schon der bloße Multivariantenmodus manche taktische Varianten viel schneller nach oben, einfach weil dann erst auch andere als die eine alleinige HV tiefer berechnet werden.

By Benno Hartwig Date 2009-09-03 12:40

[quote="Urs Maier"]

Zitat:

Ist es denn so, dass Engines innerhalb der Vollsuche, die ja normalerweise auch schon im Blitzen vielleicht Tiefen von 15 erreicht, irgendwas wegselektieren? Echte Selektion (bzw. Vertiefung) setzt doch erst danach ein, oder liege ich da falsch?

was??
vollsuche 15 ply? du bist lustig! grobe schätzung: 30^15 = 1,4 *10^22

Na, Urs, da wolltest du mich sicher missverstehen, oder? Sei dir der Spaß gegönnt.

Aber dass ich die cuts des alpha-beta-Verfahrens nicht mit 'wegselektieren' meinte, hattest sicher auch du verstanden.
Vor Urzeiten las ich mal, dass wir bei (fast) optimaler Zugsortierung dann ca. mit einer mittleren Verzweigung von wurzel(echte_Verzweigung) rechnen können, also ca. wurzel(30)=5.5 (Sorry, ich habe keine Quelle, und hoffentlich täuscht da nicht meine Erinnerung)
Bei Tiefe 2 hast du z.B. nicht 30*30=900 Blätter sondern deren 30+29=59.

Abenfalls meinte ich mit wegselektieren nicht die Analysen, die dank das Hashtabellen bei Zugumstellungen gespart werden.
Mit welchem effektiven Braching-Faktor muss so gerechnet werden? Gut 3 oder so? Weiß ich nicht. Weiß es jemand?
Dann wäre: 3^15=14348907=1,4*10^7, und das klingt dann auch nicht mehr soo astronomisch.

(Auch 4^15=1073741824=1,07*10^9 bleibt vielleicht vorstellbar)

Das, Urs, wäre immer noch ein echtes Brute-Force ohne jegliche Selektion (bzw. ein Streichen) von Zügen.

OK. Aber:
dass z.B. Nullmove-Strategien doch zu einigen echten 'Wegselektionen' führen können, stimmt natürlich. Die haben dann ja auch bisweilen zu Verwunderung geführt.
Und letztlich weiß ich auch nicht recht, wie geschafft wird, dass ein effektiver Verzweigungsfaktor erreicht wird, der irgendwo in der Gegend von tatsächlich vielleicht 2 liegt.
Kann da jemand (kannst du) einen Hinweis geben? Stichworte, die man Google vorwerfen kann?

Benno

By Urs Maier Date 2009-09-03 13:13

hallo Benno,

ich wollte dich gar nicht mißverstehen. eine Vollsuche ist eine Brute-Force-suche. da wird gar nichts abgeschnitten oder selektiert. das heißt es kommt kein alpha-beta algorithmus zur anwendung. alpha-beta beinhaltet immer eine stellungsbewertung, die mehr als matt oder nichtmatt ausdrückt.
auch eine zugsortierung ist bei brute-force irrelevant.

immer wenn eine stellungsbewertung herangezogen wird, entsteht raum für fehler in der berechnung.

da liegst du also falsch.

By Benno Hartwig Date 2009-09-03 13:50

[quote="Urs Maier"]da liegst du also falsch.[/quote]Ich denke, du liegst da falsch.

Die alpha-beta-cuts und die Prüfung auf die Zugumstellung liefert exakt das Analyseergebnis, welches ein vollständiges Durchlaufen mit jeweils Verzeigung 30 liefert. Soweit ich weiß nennt man derart reduzierte Vorgehen immer noch brute force.
Es wird halt nur auf das Bewerten von Zügen verzeichtet, weil
- man den Wert schon kennt
- man weiß, dass der Zug, gleich welchen Wert er hat, für das minimax-Suchergebnis irrelevant ist
Ich denke, niemand versteht 'brute force' dann so, dass auch solche Züge zu analysieren sind.

Wenn in der Literatur beschrieben wurde "Schachprogramm XYZ ist ein brute-force-Programm", so hat halt sicher niemand damit in Abrede gestellt, dass hier wenigstens mit alpha-beta-Fenstern gearbeitet wurde. Oder glaubst du das?

Ich denke, in der Schachprogrammierung war die Sprechweise der letzten Jahrzehnte ganz eindeutig so.

Irgendeine Vorabbewertung eines Zuges (eine Schätzung der Aussichten des Zuges) hat halt Einfluss auf die Verarbeitungsgeschwindigkeit, sie hat (abgesehen von exakt gleich guten Zügen) keinen Einfluss auf die letztliche Zugwahl oder Bewertung.
Es kann dadurch kein guter Zug übersehen werden, es kann keine Falle übersehen werden.

Benno

By Urs Maier Date 2009-09-03 14:37

warum informierst du dich nicht und behauptest einfach irgendwas, was sich in deinem gedächtnis eingegraben hat?

brute-force ist ungleich alpha-beta

googles dir halt.

By Benno Hartwig Date 2009-09-03 14:55 Edited 2009-09-03 15:05

Ich denke, du irrst, wenn du alpha-beta nicht zu den Brute-force Verfahren zählst, und ich denke, du bist einfach etwas dickköpfig,
Und ich akzeptiere, dass du vielleicht von mir Ähnliches denkst.
Wir werden beide damit leben können,
Benno

By Olaf Jenkner Date 2009-09-03 14:14

Zur Brute-Force-Suche:

Natürlich darf man jeden Algorithmus als Brute-Force bezeichnen, bei dem Züge
nicht untersucht werden, für die sich mathematisch zeigen läßt, daß sie erfolglos
sind. Dies ist bei Alpha-Beta der Fall. Ein Brute-Force-Programm wird also selbst-
verständlich nicht bis zur aktuellen Suchtiefe von z.B: 20 HZ weiterrechnen, wenn
nach dem 10. HZ nur noch König und Läufer gegen König auf dem Brett sind. Denn
dann geht rein mathematisch nichts mehr. Es kann auch andere Gründe für das Igno-
rieren von Zugmöglichkeiten geben.

OJe

By Urs Maier Date 2009-09-03 17:24

wenn du eine typische schachstellung mit einigen figuren auf dem brett hast, sind die möglichkeiten mit mathematischer gewissheit den suchbaum zu beschneiden sehr begrenzt. das einzige was mit da einfällt sind zugumstellungen, matts, zugwiederholungen und ganz spät in der partie in der stellungsbewertung gespeicherte remis- und verluststellungen. all diese dinge schränken aber den suchbaum in einer typischen stellung nur sehr marginal ein. zudem könnte die durchschnittliche anzahl der legalen züge in einer partie etwas höher als die von mir angenommenen 30 sein.

daher ist meiner meinung nach alpha-beta ganz und gar nicht brute-force, sondern eher das gegenteil.

By Benno Hartwig Date 2009-09-03 21:00

[quote="Urs Maier"]wenn du eine typische schachstellung mit einigen figuren auf dem brett hast, sind die möglichkeiten mit mathematischer gewissheit den suchbaum zu beschneiden sehr begrenzt. das einzige was mit da einfällt sind zugumstellungen, matts, zugwiederholungen und ganz spät in der partie in der stellungsbewertung gespeicherte remis- und verluststellungen.[/quote]
Und dazu kommen eben Züge, die allenfalls dazu taugen, einen bereits widerlegten Zug noch kräftiger zu widerlegen. (alpha-beta)
Auch diese Cuts erfolgen mit logischer Gewissheit (kommt mir passender vor als die mathematische, aber wir meinen wohl dasselbe),
und das kommt sehr häufig vor!
http://de.wikipedia.org/wiki/Alpha-Beta-Suche#Vergleich_von_Minimax_und_AlphaBeta
versucht eine Schätzung der Häufogkeit, wahlweise ohne und mit Zug-Sortierung.
Mit einer Zug-Selektion hat dieses Vorgehen dabei auch nichts zu tun.

Benno

By Urs Maier Date 2009-09-03 21:16

die alpha-beta methode schneidet äste eines suchbaumes auf grund von wahrscheinlichkeiten ab. sie benutzt die stellungsbewertung, um "minderwertige" äste weniger tief zu verfolgen oder gleich abzuschneiden. da die stellungsbewertung aber in keinsterweise mathematische (und oft auch praktische) gewissheit liefern kann, werden teilweise die falschen äste abgeschnitten.
die stellungsbewertung liefert einfach eine wahrscheinlichkeit dafür, daß ein zug schlecht oder gut ist.
eine stellungsbewertung im schach ist aber eben häufig fehlerhaft.

deswegen ist eine brute-force suche bis ply x besser als eine alpha-beta suche bis ply x. daß eine brute-force suche im schach völlig inpraktikabel ist, ändert daran nichts.

du kannst deine sturheit auch damit besiegen, einfach mal kurz zu googeln und dir endlich die definition der entsprechenden begriffe aneignen.

By Benno Hartwig Date 2009-09-03 21:33

Thanx, Urs, für diese Posting.
Denn damit ist endlich klar geworden, dass du tatsächlich nicht weißt, was alpha-beta macht.

Alpha-beta leistet z.Beispiel folgendes (Minimax-Logik):
Es wurde der Wert eines Zuges ermittelt (vielleicht 3, angestrebt werde dabei ein möglichst großer Wert)
Nun soll der zweite Zug bewertet werden, und das Programm erkennt, dass ein bestimmter Antwortzug darauf bereits zwingend einen kleineren Wert liefert (vielleicht 2, der Zug ist also widerlegt.).
Dann kann sich das Programm mit Gewissheit sparen, weitere Antwortzüge zu Überprüfen. Sie könnten allenfalls eine noch deutlichere Widerlegeung des bereits widerlegten Zuges liefern.

Das ist das elementare alpha-beta, dessen recht große Wirksamkeit der Wikipedia-Artikel abschätzt.
Diese Cuts erfolgen eben mit Gewissheit und ändern das Ergebnis nicht.
Ein totales Durchrechnen würde denselben Lösungszug und denselben Wert liefern.
Ein eingeschaltete Zugsortierung ändert die Logik dann nicht mehr, sie wirkt aber beschleunigend, da Widerlegungen früher bzw. häufiger eintreten.

Ich denke, dass du es nun verstanden hast und ich hoffe, dass du mir nun nicht noch mal mit einem Frechheiten-Posting kommst.
Geoutet hast du dich ja nun.

Benno

By Urs Maier Date 2009-09-04 03:17 Edited 2009-09-04 03:24

ich komme mir vor wie don quijote mit seinen windmühlen..

es ist doch nichts kompliziertes!

ich bin mir eigtl. sicher, daß wir hier über alpha-beta und mini-max im bezug auf schachprogramme schreiben, richtig?

Zitat:

Es wurde der Wert eines Zuges ermittelt (vielleicht 3...

einfache frage: wie hat das schachprogramm diesen wert ermittelt?
antwort: durch die stellungsbewertung (egal ob das nun eine einfache materialzählung ist, feldertabellen einfließen oder noch dynamischere sachen)

frage: ist dieser ermittelte wert absolut zuverläßig/beweisbar korrekt?
antwort: in der absoluten mehrzahl der fälle nicht (ausnahmen: 3-fache stellungswiederholung, matt, patt, zugumstellung zu einem berechneten knoten (ebenfalls in der regel kein korrekter wert, erlaubt aber dennoch das abschneiden eines astes) oder endspieltabellenzugriff)

da alpha-beta durch eine ungenaue stellungsbewertung maßgeblich beeinflußt ist, liefert sie also nicht zwangsläufig das gleiche ergebnis wie brute-force

vergleichen wir nun das einfache spiel tic-tac-toe:
http://www.spinfo.phil-fak.uni-koeln.de/fileadmin/spinfo/ki0809/KI_12.pdf

wie du siehst, haben wir hier eine ungleich größere anzahl von "matts", also gesicherten werten, was es ermöglicht, das spiel lückenlos und zuverläßig zu erfassen.
bei diesem spiel entspricht das ergebnis von alpha-beta dem von brute-force.
tatsächlich werden endspieltabellen im schach ja ebenfalls mit alpha-beta "rückwärts" erstellt, aber eben mit gesicherten werten. allerdings fällt dabei nicht die stellungsgenerierung weg.

verbindest du alpha-beta suche aber mit nicht gesicherten werten wie im schach, hat sie eine andere qualität als brute-force!

Ich hoffe, dass du es nun verstanden hast oder vielleicht ein engineprogrammierer die diskussion beendet.

By Peter Martan Date 2009-09-04 06:02 Edited 2009-09-04 06:06

Hallo Urs!
Kann es sein, dass selbst Programmierer das heutzutage verschieden sehen? Es scheint sich für mich um eine reine Definitionsfrage zu handeln und da kenne ich ähnliche Fälle aus anderen etwas entrückten Wissenschaften, wo Spezialisten des selben Faches aber verschiedener Spezialisierungsrichtungen sich nicht mehr einigen können, weil sie einfach verschiedenen Lehrmeinungen anhängen. In solchen Fällen mit Wikipedia zu kommen, halte ich für ähnlich sinnvoll, wie wenn Dr. House mit seinem Stab gemeinsam einen Fall (noch dazu immer ein und denselben leidenden Patienten in einer Folge) wieder einmal erst durch den 19. Therapieversuch knapp am (iatrogenen) Tod vorbei ex juvantibus diagnostiziert und man dann daraus einen Casereport in einer angesehenen medzinischen Fachzeitschrift machen wollte.

By Urs Maier Date 2009-09-04 12:25

es geht doch um ein sehr einfaches klares thema. über eine definition kann man sich doch austauschen.
ich habe alles klar geschildert und man sollte logisch argumentieren können.

man sollte es können...

alpha-beta ist so gut wie wie die zugrundeliegenden daten mit denen es arbeitet. wenn diese daten verlässlich sind ist das ergebnis von alpha-beta auch verläßlich.
wenn sie es nicht sind, ist das ergebnis auch nicht verläßlich.

die zugrundeliegenden daten im schach sind allermeist unsichere stellungsbewertungen/wahrscheinlichkeiten, also ist alpha-beta nicht verläßlich.

brute-force arbeitet mit den gleichen daten und ist demnach auch nicht verläßlich, kann aber durch breitere suche teilweise fehler ausgleichen.

ergo: alpha-beta kommt im schach nicht zwangsläufig zum gleichen ergebnis wie brute-force

das wäre nur der fall, wenn in der alpha-beta suche ausschließlich gesicherte daten wie matts etc. verwendet würden, was den suchbaum aber nur wenig einschränken würde und damit nicht praktikabel ist.

an alle diskutanten: was zum geier ist dagegen zu sagen?

By Peter Martan Date 2009-09-04 12:50 Edited 2009-09-04 12:54

Ich sag ja auch gar nix dagegen.

Benno zitiert aus der Schachhistorie eine Unterscheidung zwischen brute force, die nur Alpha- Beta- Beschneidung, die in dem Zusammenhang auch als backward pruning bezeichnet wird, durchführt, von forward pruning Techniken selektiverer Programme, die die auch von dir, glaub ich, hauptsächlich gemeinten Selektionskriterien wie vorgegebene Stellungsbewertungen und Tabellen anwendet.
Ich finde also, dass ihr gar nicht so weit auseinander seid, wenn ihr nicht weiter alle zwei darauf herumreitet, ob man Alphabeta heutzutage nicht auch so eng definieren kann, dass dann im Endeffekt wirklich praktisch nix mehr weggeschnitten wird, was sich nicht als mathematisch der Weiterberechnung unlogisch erweist, so verstehe ich ihn jedenfalls aber eigentlich hätte ich mich nicht einmischen sollen.

By Benno Hartwig Date 2009-09-04 14:14

[quote="Peter Martan"]Benno zitiert aus der Schachhistorie eine Unterscheidung zwischen brute force, die nur Alpha- Beta- Beschneidung, die in dem Zusammenhang auch als backward pruning bezeichnet wird, durchführt, von forward pruning Techniken selektiverer Programme, die die auch von dir, glaub ich, hauptsächlich gemeinten Selektionskriterien wie vorgegebene Stellungsbewertungen und Tabellen anwendet.
Ich finde also, dass ihr gar nicht so weit auseinander seid, wenn ihr nicht weiter alle zwei darauf herumreitet, ob man Alphabeta heutzutage nicht auch so eng definieren kann, dass dann im Endeffekt wirklich praktisch nix mehr weggeschnitten wird, was sich nicht als mathematisch der Weiterberechnung unlogisch erweist, so verstehe ich ihn jedenfalls aber eigentlich hätte ich mich nicht einmischen sollen.[/quote]
Ja, Thanx, Peter.
Mag sein, dass wir dein Posting mal als eine gut gemeinte Bremse sehen sollten.
Inhaltlich liegen wir wohl wirklich nicht weit auseinander.
"Was genau ist der alpha-beta-Algorithmus?" ist tatsächlich eigentlich gar nicht so interessant, wenn man sich doch eigentlich verständigen konnte, welche programmierten Mechanismen man eigentlich gemeint hat.

Benno

By Peter Martan Date 2009-09-04 16:16

Bitte gern, Benno!

Ich glaube, dass Urs einfach wie viele andere mit Alphabeta heutzutage etwas anderes verbindet, als es ursprünglich war und ursprünglich ging die Diskussion ja darum, dass du meintest, die engines würden auch heute noch und das schon im Blitzen die erste 15 HZ ziemlich komplett durchrechnen. Dass das nicht so ist, bin ich nach wie vor seiner Meinung.