Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / Ethereal 11 erschienen
1 2 Previous Next  
- - By Stefan Pohl Date 2018-09-07 14:37
https://github.com/AndyGrant/Ethereal/releases

Übrigens der erste offizielle Release von Ethereal, der auch pondern kann - wer meint, daß er es braucht...

Da ich meinen Testrun erst gestern mit Ethereal 10.97 gestartet hatte, hab ich nun noch mal von vorne begonnen, mit der offiziellen 11er Release-Version. Ergebnis nicht vor dem nächsten Wochenende. Schon der begonnene Testrun mit Version 10.97 ließ erhoffen, daß Ethereal Shredder 13 und Fizbo 2 wird überholen können (Angabe ohne Gewähr). Bin gespannt!
Parent - By guest171218 Date 2018-09-07 16:27
Hallo,

Zitat: "... daß Ethereal Shredder 13 und Fizbo 2 wird überholen können"

das hat die version 10.88 wohl bereits geschafft wie man hier sehen kann

http://www.cegt.net/3Plus1Rating/3plus1Purelist/rangliste.html

Gruß MiKa.
Parent - - By Heiko Krauß Date 2018-09-07 18:29
das geht ja wie´s Katzen machen 
eine Version nach der anderen wird heraus gehauen.

Beim TCEC geht´s jetzt ans Eingemacht.
Stockfish , Komodo und Houdini sind die nächsten Gegner von Ethereal 10.97
Parent - - By guest171218 Date 2018-09-07 19:55
Hallo,

ja, der absolute wahnsinn wie das gerade ab geht.
und die cegt hat für meine persönliche lieblingsliste,
die 3plus1 mit ponder an, auch bereits wieder die neue
ethereal version 11 in der mache. in der regel sind die
immer sehr schnell, morgen oder übermorgen gibt es
sicherlich die ersten ergebnisse?!

http://cegt.forumieren.com/t1023-testing-ethereal-11-00-x64

Gruß MiKa.
Parent - - By guest171218 Date 2018-09-12 20:14
Hallo,

ich hatte es schon vermutet und auch ein wenig gehofft,
die cegt hat wieder tempo vorgelegt, danke dafür!
dies muß auch mal gesagt werden glaube ich.

natürlich sind 1200 partien nur eine kleine stichprobe
und es wurde dabei sogar das direkte match gegen shredder
version 13 knapp verloren?! und trotzdem meine ich:
diese version von ethereal (nummer 11.00) liegt nun sicher
vor ginkgo, shredder, fizbo und booot! bei der nummer 10.88
war es noch deutlich knapper.

Gruß MiKa.
Parent - By guest171218 Date 2018-09-15 10:44
Hallo,

wie ich gerade sehe sind nun schon 3200 partien
mit der ethereal version 11.00 gespielt worden
für die cegt-liste 3plus1 mit ponder an!
nach meinen notizen hat sich das rating nicht mehr
geändert über die letzten 2000 partien, war also von
anfang an stabil. sehr schöner test, bitte weiter so.

kopie aus talkchess [http://talkchess.com/forum3/viewtopic.php?f=6&t=68394%5d

...
Fire 7.1 x64             3246 / 3200 games

Ethereal 11.00 x64       3183 / 3200 games

Ginkgo 2.1 x64           3152 / 3200 games
Deep Shredder 13 x64     3150 / 3200 games
Fizbo 2.0 x64            3142 / 3200 games
Booot 6.3 x64            3139 / 3200 games
...


Gruß MiKa.
Parent - - By Stefan Pohl Date 2018-09-15 11:22
Testrun von Ethereal 11 ist durch.

https://www.sp-cc.de

(Perhaps you have to clear your browsercache or reload the website)

Hier noch die Einzelergebnisse, die man natürlich auch auf meiner Website aufrufen kann:


Ethereal 11 pext       : 6000 (+866,=2920,-2214), 38.8 %
vs.
Stockfish 9 180201       : 1000 (+ 20,=417,-563), 22.9 %
Houdini 6 pext           : 1000 (+ 38,=433,-529), 25.4 %
Komodo 12 bmi2           : 1000 (+ 47,=472,-481), 28.3 %
Fire 7.1 popc            : 1000 (+146,=566,-288), 42.9 %
Fizbo 2 bmi2             : 1000 (+341,=468,-191), 57.5 %
Shredder 13 x64          : 1000 (+274,=564,-162), 55.6 %
Parent - - By guest171218 Date 2018-09-15 11:57
Hallo,

vielen dank für den testrun, 6000 partien, unglaublich!
da ich es nicht finden kann auf ihrer seite und auf die
schnelle: mit welcher bedenkzeit wurde gespielt?

Gruß MiKa.
Parent - By Stefan Pohl Date 2018-09-15 12:09
MiKa schrieb:

Hallo,

vielen dank für den testrun, 6000 partien, unglaublich!
da ich es nicht finden kann auf ihrer seite und auf die
schnelle: mit welcher bedenkzeit wurde gespielt?

Gruß MiKa.


Hardware: i7-6700HQ 2.6GHz Notebook (Skylake CPU), Windows 10 64bit, 8GB RAM
Fritzmark: singlecore: 5.3 / 2521 (all engines running on one core, only), average meganodes/s displayed by LittleBlitzerGUI: Houdini: 2.6 mn/s, Stockfish: 2.2 mn/s, Komodo: 2.0 mn/s
Hash: 512MB per engine
GUI: LittleBlitzerGUI (draw at 130 moves, resign at 400cp (for 4 moves))
Tablebases: None
Openings: HERT testset (by Thomas Zipproth)
Ponder, Large Memory Pages & learning: Off
Thinking time: 180''+1000ms (= 3'+1'') per game/engine (average game-duration: around  7.5 minutes).
Parent - By guest171218 Date 2018-09-07 20:12
Hallo,

manchmal schreibt die cegt auch zwischenstände in die postings,
so wie hier (habe ich gerade entdeckt, etwas nach unter scrollen)

http://cegt.forumieren.com/t1017-some-short-tests

da wird gerade eine version des programms xiphos getestet und
die zwischenstände sind die gegen engine chiron und equinox.

evtl. machen sie das auch beim test mit ethereal version 11?

Gruß MiKa.
Parent - - By Heiko Krauß Date 2018-09-07 18:48
habe mir die 11.0 soeben herunter geladen und habe da eine Frage.
Ich weis zwar nicht was der syzygy probe depht genau bewirkt,
aber bei allen anderen Engines steht er auf 1, bei Ethereal auf 0

Sollte man auf 1 umstellen ?
LG Heiko
Parent - - By Michael Scheidl Date 2018-09-08 03:13
Für Ethereal kann ich es nicht beschwören, aber normalerweise beeinflußt der Parameter die Intensität des Tablebasezugriffs. Je größer desto weniger wird zum Beispiel bei Houdini 5 zugegriffen. Default ist dort 5, aber da ich die Syz auf einer SSD (und keine 6-Steiner) habe, vergönne ich der Engine mehr Zugriffe per Einstellung auf 2 oder 3.

Umgekehrt, hat man die Tables auf einer herkömmlichen Festplatte liegen und vielleicht noch die 6er mit dazu, würde ich ein größeres Setting in Betracht ziehen, um den vielzitierten Bremseffekt zu reduzieren. Ich denke, man kann nicht von vornherein sagen wo die optimale Balance liegt.
Parent - - By Peter Martan Date 2018-09-08 09:26
Ich gehe auch davon aus, dass mehr (Einstellung) weniger (Zugriff) heißt. Das 0 verunsichert allerdings etwas, und jedenfalls greift Ethereal, ziemlich egal, was man da einstellt, schon bei Mittelspielstellung ständig sehr fleißig zu, zumindest zeigt er praktisch immer zahlreiche Hits an.

Eine Readme wäre hilfreich, hab' ich aber auf der github- site noch keine gefunden.
Parent - By Heiko Krauß Date 2018-09-08 10:41
Danke Michael und Peter,
ich habe jetzt mal auf 1 eingestellt, wie es bei meinen anderen Engines ist.
Für meine FS-Analysen wird es nur eine untergeordnete Rolle spielen,
aber die 0 hat mich doch etwas irritiert
Parent - - By Roland del Rio Date 2018-09-08 15:43
Da hast du dich aber nicht allzusehr beim Suchen bemüht. Ich helfe mal aus:

Zitat:

### SyzygyProbeDepth
Minimum depth to start probing table bases (although this depth is ignored when a position with a cardinality less than the size of the given table bases is reached). Without a strong SSD, this option may need to be increased from the default of 0. I have done some of my testing on an standard hard drive, and found a Probe Depth of 8 to be acceptable.


Ist ein Standard UCI Parameter, der im Grunde nichts mit der Engine zu tun hat. Die Angaben im Readme sind genauso richtig oder falsch wie die tausend anderen Empfehlungen hierzu, die in den Foren kursieren. Hängt einfach vom jeweiligen System ab.
Parent - By Heiko Krauß Date 2018-09-08 16:16
Aha - habs mal übersetzen lassen (kann kein Englisch)

SyzygyProbeTiefe
Minimale Tiefe, um mit dem Antasten von Tischbasen zu beginnen (obwohl diese Tiefe ignoriert wird, wenn eine Position mit einer Kardinalität kleiner als die Größe der angegebenen Tischbasen erreicht wird). Ohne eine starke SSD muss diese Option möglicherweise von der Standardeinstellung 0 erhöht werden, da ich einige meiner Tests auf einer Standardfestplatte durchgeführt habe und eine Sonden-Tiefe von 8 als akzeptabel empfand.

Übersetzt mit www.DeepL.com/Translator

SSD hab ich nicht , also wäre dann 8 richtig

Dann steht meinem IM-Titel ja nix mehr im Wege   
Parent - - By Michael Scheidl Date 2018-09-08 16:45
Zitat:
Minimum depth to start probing table bases

Das ist völlig unlogisch, denn die Millionen Tablebasestellungen entstehen doch erst in großen Tiefen, und dort kann ein solcher Parameter Einfluß nehmen. Die "Handvoll" Stellungen die es bei Tiefen wie 7 oder so gibt sind doch unbedeutend, dort kosten die die paar Zugriffe keine Spielstärke. Ich weiß nicht was Du da zitierst.

Die logische Regulierung ist nicht "ab wann" Zugriffe stattfinden, sondern "bis wann", bezogen auf die Rechentiefe.
Parent - By Roland del Rio Date 2018-09-08 17:26
Zitat:
Ich weiß nicht was Du da zitierst.


Nun, wie geschrieben zitiere ich das gesuchte Readme des Programmierers von Ethereal. Für Inhaltliche Frage und Kommentare bitte an den Author wenden. Ich persönlich finde es weiterhin etwas eigenartig, dass er den zweiten Parameter in diesem Zusammenhang, "syzygy probe limit", nicht über UCI durchreicht. Aufgrund seines Readme erahne ich, wie er den per default hard-coded, sicher kann ich mir da aber natürlich auch nicht sein. Wenn man sich mit dem Thema beschäftigt, würde ich einfach davon absehen das Readme des AndyGrants hier als Basislektüre zu sehr in die Pflicht zu nehmen.  
Parent - - By Peter Martan Date 2018-09-08 16:49 Edited 2018-09-08 17:15
Roland del Rio schrieb:

Ist ein Standard UCI Parameter, der im Grunde nichts mit der Engine zu tun hat. Die Angaben im Readme sind genauso richtig oder falsch wie die tausend anderen Empfehlungen hierzu, die in den Foren kursieren. Hängt einfach vom jeweiligen System ab.

Danke, Roland, hab's mittlerweile auch gefunden.

https://github.com/AndyGrant/Ethereal/blob/master/README.md

Aber obwohl Andrew Grant in seiner Readme schreibt, dass man den Wert erhöhen soll, wenn man langsame Festplatten hat, scheint sich Ethereal halt immer wieder mal nicht wirklich um einen Maximalwert von 127 zu kümmern, jedenfalls greift sie da bei mir in manchen Mittelspielstellung immer noch sehr fleißig zu.

Was das mit der cardinality der jeweiligen Position und der der tbs- Stellung heißen soll, ist mir vollends unklar.
Zitat:
although this depth is ignored when a position with a cardinality less than the size of the given table bases is reached

Vielleicht ist ja das der Schlüssel dazu, dass sich die Engine um die Rechentiefe, die eingestellt ist, eben fallweise nicht zu kümmern scheint.

Es einfach mit Mächtigkeit zu übersetzen, hilft nicht, und was der mathematische Begriff der Kardinalität hier bedeutet, das darfst jetzt wieder du mir erklären.


Edit: Ach was, er sie es greift einfach ebenso häufig zu, wie Stockfish. Bei dem drehe ich aber halt einfach das Probe Limit auf 0, wenn ich will, dass er ohne Syzygys analysiert, das gibt's bei Ethereal eben nicht und die 127 Rechentiefe, die man maximal einstellen kann, sind im Vergleich zwischen den beiden anscheinend nicht soviel mehr als die 100 bei SF.

Bei Houdini ist aber bei 99 meistens, wenn man nicht schon direkt mit der Nase vor den Wenigsteinern steht, Schluss mit Hits.
Parent - - By Roland del Rio Date 2018-09-08 17:16
Hallo Peter.

Zitat:
although this depth is ignored when a position with a cardinality less than the size of the given table bases is reached

Er meint, dass man ab dem Unterschreiten einer bestimmten Figurenanzahl immer auf die TBs zugreift, egal, was man in dem Parameter einstellt.

Zitat:
Aber obwohl Andrew Grant in seiner Readme schreibt, dass man den Wert erhöhen soll, wenn man langsame Festplatten hat, scheint sich Ethereal halt immer wieder mal nicht wirklich um einen Maximalwert von 127 zu kümmern, jedenfalls greift sie da bei mir in manchen Mittelspielstellung immer noch sehr fleißig zu.


Warum auch nicht, der Parameter sagt ja auch nicht, dass gar nicht mehr zugegriffen wird. Wenn du es besser verstehen willst, suche einfach mal nach dem Parameterpäarchen "syzygy probe depth" und "syzygy probe limit". Bei diesen Parametern pauschal mit Werten um sich zu schmeißen ist Blödsinn. Viele Menschen nehmen nunmal Zahlen immer dankbar entgegen und scheuen sich davor, obwohl sie sich ja scheinbar für die Materie interessieren,  sich mal mit Materie auseinanderzusetzten (ungenügende Englischkenntnisse sind hier (und generell im Internet-/Leben), zugegebenermaßen ein Hindernis). Und wie definiert sich "langsame Festplatten" ? Die einzig pauschal gültige Regel  bzgl. dieser beiden TBs Parameter war und ist: So aggressiv wie möglich ohne wesentlich nps zu verlieren.
Parent - - By Peter Martan Date 2018-09-08 17:24 Edited 2018-09-08 17:26
Roland del Rio schrieb:

Wenn du es besser verstehen willst, suche einfach mal nach dem Parameterpäarchen "syzygy probe depth" und "syzygy probe limit". Bei diesen Parametern pauschal mit Werten um sich zu schmeißen ist Blödsinn. Viele Menschen nehmen nunmal Zahlen immer dankbar entgegen und scheuen sich davor, obwohl sie sich ja scheinbar für die Materie interessieren,  sich mal mit Materie auseinanderzusetzten (ungenügende Englischkenntnisse sind hier (und generell im Internet-/Leben), zugegebenermaßen ein Hindernis).

Neuerlich danke, ich hab', was das Limit angeht, während du geantwortet hast, selbst auch darauf hingewiesen, und selbst, wenn du es mir vielleicht nicht zutraust oder meinem Englisch, ich kannte den Unterschied in der Bedeutung Probe Limit und Probe Depth schon.

Aber wenn man schon mit Zahlen um sich schmeißt (und ich habe ja nicht damit angefangen), sollte man ihnen dann auch eine quantitative Bedeutung beimessen, und wenn eine Engine angibt, sie greife erst ab einer Rechentiefe von 127 auf die tbs zu, dann nehme ich zunächst mal an, na wird in Mittelspielstellungen schon nicht soo viel sein, was da an Hits herauskommt, schaue mir dann den Output an und wundere mich.
Seit ich das mit SF, bei dem ich eben immer einfach das Limit auf 0 drehe, wenn ich ihn ohne tbs- Verwendung rechnen lasse, auch mal verglichen habe bei Limit 6 und Depth 100, wundere ich mich schon wieder weniger.


Und natürlich hängt das eine auch vom anderen ab, bei full Syzgys (und Limit 6) wird natürlich mehr bei gleicher Rechentiefe herauskommen, als bei 5Steinern.
Parent - - By Roland del Rio Date 2018-09-09 15:02
Hallo Peter. Weder mit den Englischkenntnissen noch mit den den Leuten, die lieber Zahlenempfehlungen folgen, anstatt ihre eigenen Gedanken zu machen warst du gemeint! Danke fürs nicht falsch verstehen
Parent - By Peter Martan Date 2018-09-09 15:11
Parent - - By Thomas Plaschke Date 2018-09-08 19:24 Upvotes 1
Ich habe mal ein bisschen getestet.
Dieser 8-Steiner ist tot-remis: FEN: 4k3/2p5/2p5/2Pp4/3P4/3P4/4K3/8 w - - 0 1

Ethereal 10.97 mit 1 Thread und 2 GB für Hash-Tabellen rechnete bis zur Tiefe 60 Hz. In der Tabelle stehen die Anzahl der berechneten Knoten und die Anzahl der Treffer in den 6-Steiner Endspieltabellen für verschiedene Werte von SyzygyProbeDepth (=SzPD).
Code:
SzPD   Knoten  TB-Hits
0    15248514    207
8    14110799    424
40   18029196  16308
42   17245567  16641
43   17285112  16848
44   17285397  16852
45   17285397  16852
46   17285653  16850
47   17285653  16850
48   17285653  16850
59   17285653  16850
60   17285653  16850
127  17285653  16850
Aufgrund der Aussage in der Readme-Datei ("Minimum depth to start probing table bases" = "Mindesttiefe für die Abfrage der Tablebases") würde ich erwarten, dass höhere Werte für SyzygyProbeDepth weniger Zugriffe auf die Endspieltabellen bedeuten. Bei SyzygyProbeDepth=127 würde ich eigentlich gar keine Zugriffe mehr erwarten. Aber es ist genau umgekehrt. Das gleiche Verhalten zeigt Stockfish. Unerklärlich bleiben für mich auch die ermittelten Werte. SyzygyProbeDepth 44 und 45 zeigen identische Werte. Ab SyzygyProbeDepth 46 zeigen sich keine Auswirkungen mehr auf die Anzahl berechneten Knoten. - Hätte ich nicht erwartet 

Viele Grüße
Th. Plaschke
Parent - - By Michael Scheidl Date 2018-09-09 01:41 Edited 2018-09-09 01:47
Es wär halt schön wenn sich die Programmierer durchringen könnten, Klartext zu reden.

P.S. Geheimniskrämer schmeisse ich aus meiner Sammlung raus! Bye-bye Miss American Ply.
Parent - By Thomas Plaschke Date 2018-09-09 21:17
Immerhin sind die Syzygy-Funktionen nur übernommen worden. Vor Missverständnissen über die Funktionsweise oder einzelnen Parametern sind auch Programmierer nicht gefeit.
Allerdings bin ich mir nicht sicher, was peinlicher oder ehrabschneidender ist: Die Unterstellung von Geheimniskrämerei (-wo doch Jeder Zugriff auf die Quelldateien hat) oder die Überlegung, der Programmierer übernimmt eine Bibliothek in sein Programm, ohne ihre Arbeitsweise zu durchschauen. Tatsächlich wäre das mit den Syzygy-Funktionen möglich, wenn ich mich richtig an die Zeit ihres Erscheinens erinnere.

Als weitere Alternative halte ich für möglich, dass uns Anwendern der Durchblick fehlt. Immerhin zeigt auch Stockfish dieses Verhalten. In den Erläuterungen auf Github heißt es dort: "Set this option to a higher value if you experience too much slowdown (in terms of nps) due to TB probing." Also höhere Werte, um ein Abfallen der Knotenleistung auszugleichen. Müsste Stockfish konsequenterweise nicht auch von der Platte fliegen? Stockfishs Syzygy-Funktion wurde immerhin von M. Costalba gründlich überarbeitet. So einen Peer-Review hätte ein echter Fehler nicht überstanden.

Ich selbst verstehe die Funktionsweise der Syzygy-Tabellen nicht und kann daher nicht einfach aus dem Quellcode die Funktionsweise dieses Parameters überprüfen.
Da ich den Parameter nicht brauche (SSD für Tablebases), gehört die Angelegenheit bei mir in die Kategorie "Kurioses" - bis ich eine Erklärung dafür bekomme 

Viele Grüße
Th. Plaschke
Parent - - By Roland del Rio Date 2018-09-09 15:16 Edited 2018-09-09 15:37
Hallo Thomas. Hattest du in deinem TBs-Pfad auch die 5-4-3-Steiner Dateien?
Parent - - By Thomas Plaschke Date 2018-09-09 20:45
Ja, das Programm hatte Zugriff auf alle 510 Tablebases.

Viele Grüße
Th. Plaschke
Parent - - By Roland del Rio Date 2018-09-10 09:01
Zitat:
Ja, das Programm hatte Zugriff auf alle 510 Tablebases.


Das habe ich beim Versuch deine Zahlen zu interpretieren schon vermutet.

Zitat:
Ethereal 10.97 mit 1 Thread und 2 GB für Hash-Tabellen rechnete bis zur Tiefe 60 Hz. In der Tabelle stehen die Anzahl der berechneten Knoten und die Anzahl der Treffer in den 6-Steiner Endspieltabellen für verschiedene Werte von SyzygyProbeDepth (=SzPD).
Code:
SzPD   Knoten  TB-Hits
0    15248514    207
8    14110799    424
40   18029196  16308
42   17245567  16641
43   17285112  16848
44   17285397  16852
45   17285397  16852
46   17285653  16850
47   17285653  16850
48   17285653  16850
59   17285653  16850
60   17285653  16850
127  17285653  16850


Das Experiment hat eine sehr unglücklichen Setup. Einmal ist die Stellung sehr speziell und vermutlich für unerwünschte, auf den ersten Blick unreklärliche Effekte verantwortlich. Das existieren der 5-4-3-Steiner TBs im Zugriffspfad macht die Zahlen nochmals schwerer bewertbar, denn die GUI-Ausgabe unterscheidet nicht zwischen einem Zugriff auf einer 6-Steiner-Datei oder einer 5-4-3-Steiner-Datei. Somit sind die Werte in deiner Spalte TB-Hits nicht "die Anzahl der Treffer in den 6-Steiner Endspieltabellen", sondern die Anzahl der Treffer in 3-4-5- und 6-Steiner TBs insgesamt.
Parent - - By Thomas Plaschke Date 2018-09-10 12:35
Ich wusste nicht, dass es sinnvoll sein könnte, 6-Steiner-Endspieltabellen ohne 5-, 4- und 3-Steiner-Endspieltabellen zu benutzen. Deswegen bedeuteten für mich "6-Steiner-Endspieltabellen" synonym immer "6-, 5-, 4- und 3-Steiner-Endspieltabellen", "5-Steiner-Endspieltabellen" immer "5-, 4- und 3-Steiner-Endspieltabellen" etc. Tut mir leid für dieses Missverständnis. Ich weiß daher auch nicht, ob für die Suche in einem 8-Steiner die 6-Steiner-Endspieltabellen allein bereits ausreichen, weil die nötigen Information zur Sieg, Niederlage oder Remis schon vorliegen.

Ausgangspunkt war die Interpretation der Beschreibung des Parameters "SyzygyProbeDepth" und nachfolgend das als widersprüchlich erscheinende Suchverhalten bezogen auf die Endspieltabellenzugriffe bei fixer Rechentiefe (und übrigens identischer Hauptvariante). Unerklärlich bleibt für mich und wahrscheinlich auch einige andere interessierte Foristen, wie höhere Werte für einen Parameter, die zu einem Sinken der Zahl der Endspieltabellenzugriffe führen sollten, den gegenteiligen Effekt haben. Sicher könnte es an der Stellung liegen. Mir ist aber nicht klar, welche diesbezügliche Besonderheiten die verwendete Stellung aufweist.

Vorstellbar ist, dass die Remis-Stellungen viel früher im Suchbaum erscheinen und für niedrige Parameterwerte bereits wenige Endspieltabellenzugriffe ausreichen, um die entscheidenden Varianten zu finden und die Hashtabellen entsprechend so zu füllen, sodass die Ergebnisse der Endspieltabellenzugriffe im Suchbaum "hoch gereicht" werden. Bei höheren Parameterwerten ist der Suchbaum dagegen bereits größer und breiter, sodass in den (vielen) Ästen mehr (erstmalige) Endspieltabellenzugriffe erfolgen. Diese Erklärung würde aber für jede Stellung gelten, kann also eigentlich nicht die gesuchte Erklärung sein.

Eine andere Erklärung könnte sein, dass durch das "Hinaufschieben" der Endspieltabellenzugriffe in höhere Rechentiefen auch Stellungen mit 5-, 4- oder 3-Steinen geprüft werden (dann ist die Suche "mittendrin"), statt ausschließlich 6-Steiner (bei SyzygyProbeDepth=0). Allerdings dauert es in der Teststellung einige Züge, bis solche Stellungen mit weniger als 6 Steinen im Suchbaum auftauchen. Damit wären höhere Werte für diesen Parameter im Endspiel grundsätzlich schädlich und eigentlich nur im späten Mittelspiel mit schon deutlich reduziertem Material sinnvoll. Bis zu dieser Phase würden ohnehin noch nicht so viele Zugriffe erfolgen. Eine sinnvolle Anwendung gäbe es für diesen Parameter meines Erachtens dann nicht.

Für andere Stellungen habe ich es nunmal nicht ausprobiert. Daher schließe ich nicht aus, dass der Parameter in anderen Stellungen so funktioniert, wie er beschrieben wird. Da mir aber nicht klar ist, warum die verwendete Stellung eine Ausnahme sein soll, kann ich keine andere Stellung komponieren, die nicht wieder diesen oder einen anderen von mir unerkannten Fehler enthält.

Viele Grüße
Th. Plaschke
Parent - - By Roland del Rio Date 2018-09-10 13:40
Hallo Thomas. Wenn ich deine Antwort so lese, bin ich mir nicht ganz sicher, ob du den Parameter, den du untersuchen willst, in seiner Wirkungsweise 100% verstanden hast. Es liest sich, als würdest du denken mit deinen eingestellten SyzygyProbeDepth-Werten von 0 bis 127, irgend einen Einfluss auf die Zugriffe der bei dir im Pfad liegenden 5-, 4- und 3-Steiner TBs zu haben. Ist dir klar, dass dem nicht so ist? (korrekte Implementierung seitens der Engine-Authors vorausgesetzt)
Parent - - By Thomas Plaschke Date 2018-09-10 15:52
Hallo Roland,

>Es liest sich, als würdest du denken mit deinen eingestellten SyzygyProbeDepth-Werten von 0 bis 127, irgend einen Einfluss auf die Zugriffe der bei dir im Pfad liegenden 5-, 4- und 3-Steiner TBs zu haben.


Dass der Parameter Einfluss auf die TB-Zugriffe hat (Gibt es einen Grund, warum Du die 6-Steiner nicht in der Aufzählung hast?), ist offensichtlich, weil ich es so beobachtet habe. Unverständnis löst bei mir und anderen aus, dass die Erhöhung des Parameterwertes zu weniger Zugriffen führen sollte. Zumindest lässt die Erläuterung des Parameters in der Readme-Datei dies erwarten. Alternativ könnte die Ausgangsstellung atypisch sein oder einige Anwender haben die Beschreibung falsch verstanden, dann muss man darüber nicht weiter reden.

>Ist dir klar, dass dem nicht so ist?


Es wäre für mich erkenntnisreicher, wenn Du nicht solche Fragen stellen würdest, sondern, da Du anscheinend über die Bedeutung des Parameters Bescheid weißt, auch gleich Antwort und Erklärung gibst 

Viele Grüße
Thomas Plaschke
Parent - - By Roland del Rio Date 2018-09-10 16:03
Zitat:
Gibt es einen Grund, warum Du die 6-Steiner nicht in der Aufzählung hast?
Ja, den gibt es natürlich. Ich habe dir in meinem anderen Post mal eine Quelle für die Bedeutung der Parameter geschickt.
Zitat:
s wäre für mich erkenntnisreicher, wenn Du nicht solche Fragen stellen würdest, sondern, da Du anscheinend über die Bedeutung des Parameters Bescheid weißt, auch gleich Antwort und Erklärung gibst 
Das ich ihn nicht erklärt habe liegt daran, dass ich davon ausgegangen bist, du kennst die Funktionsweise. Aber ok, ganz kurz: Der Parameter SyzygyProbeDepth wirkt NUR auf die mit SyzygyProbeLimit eingestellte TB-Ebene (im Falle von Ethereal vermutlich hard-coded 6). Auf darunter liegende Ebenen (5-4-3) hat der Parameter keinen Einfluss! Jetzt kannst du nochmal versuchen deine Zahlen neu zu verstehen, oder machst, wie geschrieben, besser einen Test mit einer anderen Stellung, bzw. nimmst die Ergebnisse von Peter.
Parent - - By Thomas Plaschke Date 2018-09-10 16:28
Schönen Dank!

Das entspricht dem, was ich für höhere SyzygyProbeDepth-Werte so
Code:
Eine andere Erklärung könnte sein, dass durch das "Hinaufschieben" der Endspieltabellenzugriffe in höhere Rechentiefen auch Stellungen mit 5-, 4- oder 3-Steinen geprüft werden (dann ist die Suche "mittendrin"), statt ausschließlich 6-Steiner (bei SyzygyProbeDepth=0).

als mögliche Erklärung umschrieben habe. Sehe ich das richtig?

Vermutlich dürfte für einen Remis-3-Steiner (ich habe keine Lust, die TBs nach Steinen zu sortieren) meine Beobachtung nicht mehr möglich sein.

Viele Grüße
Th. Plaschke
Parent - By Michael Scheidl Date 2018-09-10 18:51
Ich reimte mir das schon vor längerer Zeit (z.B. Hiarcs) folgendermaßen zusammen: Vermutlich handelt es sich um die Resttiefe, ab der nicht mehr zugegriffen wird. Also ginge beispielsweise die aktuelle Iteration bis Tiefe 24, und der Parameter wäre 4, so wird nur bis Tiefe 20 zugegriffen. Beschwören kann ich das aber nicht.

Bei Houdini 6 wird das so beschrieben:
Zitat:
The frequency of the probing is influenced by the EGTB Probe Depth parameter. You can decrease this parameter to force Houdini to use the EGTB more frequently, or increase it to have Houdini use the EGTB less frequently. The default value of 1 is appropriate for systems with the table bases on SSD. If the table bases are on a slower, mechanical hard disk you should consider increasing this value to reduce the frequency of probing.

http://www.cruxis.com/chess/manual/index.html?end_game_table_base_support.htm
Parent - - By Peter Martan Date 2018-09-10 14:07 Edited 2018-09-10 14:09
Hallo Thomas!

Thomas Plaschke schrieb:

Für andere Stellungen habe ich es nunmal nicht ausprobiert. Daher schließe ich nicht aus, dass der Parameter in anderen Stellungen so funktioniert, wie er beschrieben wird. Da mir aber nicht klar ist, warum die verwendete Stellung eine Ausnahme sein soll, kann ich keine andere Stellung komponieren, die nicht wieder diesen oder einen anderen von mir unerkannten Fehler enthält.


Zunächst mal danke, dass du dich bemühst, der Sache auf den Grund zu gehen.
An deiner Stellung scheint mir nur eines untypisch, dass sie blitzschnell bis Tiefe 127 (Max.) von SF durchgerechnet ist, das mag andere Ergebnisse erbringen, als wenn die time to depth länger ist, wie z.B. hier:

Ethereal11 mit Suchtiefe 127:

3r3k/2n2K1p/pR6/8/2p5/5p2/5p2/7R w - - 0 1

Analysis by Ethereal 11.00 (POPCNT):

1.Td1
  +-  (8.45 ++)   Tiefe: 35/63   00:03:37  6816MN, tb=25432202

Und mit 0:

3r3k/2n2K1p/pR6/8/2p5/5p2/5p2/7R w - - 0 1

Analysis by Ethereal 11.00 (POPCNT):

1.Td1
  +-  (266 ++)   Tiefe: 35/65   00:01:50  3066MN, tb=36141081

Das Verhältnis vom tbs- Suchtiefe- Parameter scheint mir in diesem Fall (auch bei SF) mit  Ethereal den Erwartungen entsprechend, je mehr Tiefe eingestellt ist, desto weniger Zugriffe.

Wenn es dich tröstet, verstehe ich Roland mit seinen Einwänden betreffs 3er, 4er, 5er tbs auch nicht.

Ich hätte angenommen, dass Hits in den 6Steinern, wenn als SyzygyProbeLimit 6 eingestellt ist, sowieso nicht noch zusätzlich in der 3er, 4er, 5er tbs angezeigt werden und die nur dann relevant sind, wenn das Limit kleiner ist.

Dennoch würde ich annehmen, dass bei höheren eingestellten SyzygyProbeDepth- Werten geringere Zugriffe in Stellungen auch wie der von dir gezeigten logisch wären.
Dass dem in deiner Stellung nicht so ist, überrascht mich auch, insbesondere, weil es ein gemeinsames Verhalten von SF und Ethereal ist.
Parent - By Roland del Rio Date 2018-09-10 15:19
Zitat:
Wenn es dich tröstet, verstehe ich Roland mit seinen Einwänden betreffs 3er, 4er, 5er tbs auch nicht.
Ich hätte angenommen, dass Hits in den 6Steinern, wenn als SyzygyProbeLimit 6 eingestellt ist, sowieso nicht noch zusätzlich in der 3er, 4er, 5er tbs angezeigt werden und die nur dann relevant sind, wenn das Limit kleiner ist.


Deine Annahme ist schon richtig, wenn du meinst, dass in einer Variante die in einem 6-Steiner Hit endet unterhalb nun gar nicht mehr weiter gesucht/expandiert wird und somit auch keine Treffer in 3-4-5-Steiner TBs mehr entstehen. Treffer in den 3-4-5-Steinern entstehen jedoch unterhalb der von SyzygyProbeDepth gesetzten Grenze. Und die zählen dann im GUI pauschal als Hit, was eine Untersuchung der Hits in den 6-Steinern unkontrollierbar verfälscht.
Parent - - By Roland del Rio Date 2018-09-10 15:56
Zitat:
Für andere Stellungen habe ich es nunmal nicht ausprobiert. Daher schließe ich nicht aus, dass der Parameter in anderen Stellungen so funktioniert, wie er beschrieben wird. Da mir aber nicht klar ist, warum die verwendete Stellung eine Ausnahme sein soll, kann ich keine andere Stellung komponieren, die nicht wieder diesen oder einen anderen von mir unerkannten Fehler enthält.

Solltest du weiterhin Lust haben hier zu forschen: Anstatt von der "Interpretation der Beschreibung des Parameters SyzygyProbeDepth"  auszugehen, schau dir die genaue Bedeutung des Parameter an. Anstelle des Readme vom Ethereal-Authors. aber besser andernorts. z.B. findest du unter https://groups.google.com/forum/#!topic/fishcooking/iWGCc61G6g0  mit Ronald de Man jemanden, von dem man annehmen kann, er weiß wovon er spricht.
Zu deiner Teststellung: Was ich sicherlich als unglücklich ansehe ist deren Simplizität. Die Anzahl der nach AB-pruning zu untersuchenden Stellungen ist sicherlich sehr gering, folglich der Suchbaum sehr klein. Zur Untersuchung eines Parameters der mit Suchtiefen von 0 bis 127 in einem B-Tree spielt, wäre ein entsprechend tiefer Baum natürlich "hilfreich". Konstante Knotenanzahl zwischen den unterschiedlichen Setups wie in deinem Beispiel, würden mich auch ins rübeln kommen lassen.
Parent - - By Thomas Plaschke Date 2018-09-10 16:39
RdM ist natürlich die Autorität in dieser Thematik. Aber nachdem ich erstmal eine plausible Erklärung habe, ist meine Neugier fürs erste gestillt.

Die Sinnhaftigkeit dieses Parameters für Werte >0 leuchtet mir dagegen nicht ein. Es sei denn TB-Zugriff hat in Eröffnung und Mittelspiel größeren Nutzen für die Spielstärke als im Endspiel, sodass die Zunahme der Zugriffe letztlich kompensiert wird.

Viele Grüße
Th. Plaschke
Parent - - By Roland del Rio Date 2018-09-10 17:02
Auch wenn du schreibst dass deine Neugier fürs erste gestillt ist hätte ich mich gefreut, wenn du den Link, den ich dir rausgesucht habe, wenigstens mal verfolgt hättest. Die Postings hätten dir dann auch die Sinnhaftigkeit des Parameters, nach der du fragst, erklärt. Aber vielleicht findest du ja jemanden hier, der sich der Frage annimmt.
Viele Grüße
Parent - By Thomas Plaschke Date 2018-09-10 18:42
Natürlich bin ich dem Link gefolgt und habe das Licht gesehen.
Schon damals fragte man sich, welchen Nutzen Anwender aus diesen Parametern ziehen könnten.

Ich verstehe den Parameter jetzt so:
Code:
Der Zugriff auf die mit SyzygyProbeLimit=x festgelegten x-Steiner findet erst ab der mit SyzygyProbeDepth festgelegten Tiefe statt. Der Zugriff auf die (x-1)-Steiner findet dagegen immer statt und wird durch SyzygyProbeDepth nicht beeinflusst.
Das war's, hoffe ich.

Viele Grüße und schönen Dank für den Link
Th. Plaschke
Parent - By Thorsten Czub Date 2018-09-07 21:13
Also ich ponder auch immer wenn ich Schach spiele
Parent - - By Thorsten Czub Date 2018-09-07 21:14
Warum sollte man dieses Programm denn benutzen ??
Parent - By Michael Scheidl Date 2018-09-08 03:18
Es rief Interesse hervor, da es noch relativ neu (2016) aber bereits sehr stark geworden ist.
Parent - - By Michael Scheidl Date 2018-10-09 16:23
Parent - By Heiko Krauß Date 2018-10-09 17:02
Danke für den Link
Parent - - By Thomas Lagershausen Date 2018-10-09 20:04
@Michael

I love it. 

Ich wähle Dich hiermit zum wichtigsten Mann des Computerschachs in 2018 nach Andrew Grant.

Bei jeder neuen Version spürt man den Elozuwachs bereits in den Fingern.

Der Mann hat echt Talent und ich glaube daran das Ethereal zu den großen Drei aufschließen kann in den nächsten 3 Jahren.

Dank, Gruß und bitte denke weiter an uns.
Parent - By Stefan Pohl Date 2018-10-15 14:38
Thomas Lagershausen schrieb:

Bei jeder neuen Version spürt man den Elozuwachs bereits in den Fingern.

Der Mann hat echt Talent und ich glaube daran das Ethereal zu den großen Drei aufschließen kann in den nächsten 3 Jahren.


Und nebem dem Talent hat er das Testen seiner Patches vom Stockfish-Framework 1:1 übernommen, was sicher nicht der schlechteste Plan ist.
Auszug von letzten Patch 11.12 von der Ethereal-Github Seite:

Tune king to passer distance arrays  …
ELO   | 1.74 +- 1.19 (95%)
SPRT  | 10.0+0.1s Threads=1 Hash=8MB
LLR   | 2.96 (-2.94, 2.94) [0.00, 4.00]
Games | N: 139130 W: 29751 L: 29054 D: 80325

ELO   | 2.11 +- 1.70 (95%)
SPRT  | 60.0+0.6s Threads=1 Hash=64MB
LLR   | 2.95 (-2.94, 2.94) [0.00, 4.00]
Games | N: 53370 W: 9038 L: 8714 D: 35618
Parent - - By Thomas Lagershausen Date 2018-10-10 09:30
Hallo Michael

Es scheint sogar schon eine Version 11.12 von Ethereal zu geben.

Kommst Du da vielleicht auch dran?

Gruß
Parent - By Michael Scheidl Date 2018-10-10 12:19
Leider nein, den 11.11-Link hatte ich zufällig im Chat aufgeschnappt. Die Homepage unter
https://github.com/AndyGrant/Ethereal/releases
steht noch bei 11.00.
Up Topic Hauptforen / CSS-Forum / Ethereal 11 erschienen
1 2 Previous Next  

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill