Not logged inCSS-Forum
Forum CSS-Online Help Search Login
CSS-Shop Impressum Datenschutz
Up Topic Hauptforen / CSS-Forum / Grausames Endspiel von Lc0 bei CCCC
- - By Reinhold Stibi Date 2018-09-16 17:17
Habe gerade die Partie Lc0 gegen Nemorino im Internet verfolgt. Gewonnen von Lc0 im 94. Zug.

Lc0 hätte viel schneller im Endspiel gewinnen können. Es waren fürchterlich stümperhafte Züge im Endspiel.
Kreisklassen-Niveau oder schlechter.

Was mich verwundert hat war die äußerst geringe Suchtiefe von Lc0 im Endspiel von nur 7-9.
Da muss ein Fehler vorgelegen haben.
Vielleicht lag es auch an der Einstellung von Ponder on mit dem m.E. Lc0 nicht zurecht kommt.
Parent - - By Ernest Bonnem Date 2018-09-16 17:44 Edited 2018-09-16 18:01
Eine Erklärung kann sein, dass Lc0 nicht korrekt mit den Sygyzy Tables spielt (er hat nur die wdl Tables).
Parent - - By Peter Martan Date 2018-09-16 18:17 Edited 2018-09-16 18:24
Wahrscheinlich hast du recht, Ernest. Ich frage mich nur mal wieder, warum braucht eine NN- Engine Tablebases?
Sollte sie nicht das Endspiel eigentlich noch vor der Eröffnung und vor dem Mittelspiel "gelernt" haben?
Ist doch viel einfacher mit weniger Steinen, nein?

Uups, ich lese gerade hier

http://talkchess.com/forum3/viewtopic.php?p=773890#p773890

dass Nai Lin Tun sagt, Leela nutze dort gar keine tbs:

Zitat:

Be aware that the version of Leela playing over there has
1. No TB support
2. Not the best version ( best version of 10xxx net is about +25 elo better)
3. 50 moves rules bug in almost whole training
4. Terrible Time managment with pondering on setting (not properly tested)
Parent - - By Reinhold Stibi Date 2018-09-16 18:31
Das wollte ich dir gerade mitteilen dass Lc0 bei CCCC keine tbs benutzt.

Bei dieser starken Hardware von Lc0 bei CCCC müssten die Suchtiefen im Endspiel
viel höher sein als die angezeigten 7-9.

Da muss sich ein Fehler eingeschlichen haben.

Auch kommt m.E. Lc0 nicht mit Ponder on zurecht. Bug !
Parent - By Reinhold Stibi Date 2018-09-16 18:52
Das schlechte Endspiel und die geringen Suchtiefen im Endspiel
kamen wahrscheinlich durch Überhitzung der Hardware zustande.

Die GPU bei Lc0 dürfte sich dabei fast ausgeschaltet haben.
Parent - By Achim Müller Date 2018-09-16 20:06
Reinhold Stibi schrieb:

Auch kommt m.E. Lc0 nicht mit Ponder on zurecht. Bug !


Kein Bug, sondern schlicht eine (noch) nicht in der beim cccc benutzten Version implementierte Funktion im generellen Time Management. Deshalb zieht Lc0 auch bis ins tiefe Mittelspiel so schnell.

Ciao

Achim
Parent - By Ernest Bonnem Date 2018-09-17 00:58
Peter Martan schrieb:
......
dass Nai Lin Tun sagt, Leela nutze dort gar keine tbs:

Naja,
http://talkchess.com/forum3/viewtopic.php?p=773277#p773277
(früher) sagte "ungefähr" das Gegenteil...  

Schade, dass CCCC nicht selbst die Engine Info gibt.
Parent - - By Achim Müller Date 2018-09-16 20:17 Edited 2018-09-16 20:32
Reinhold Stibi schrieb:

Habe gerade die Partie Lc0 gegen Nemorino im Internet verfolgt. Gewonnen von Lc0 im 94. Zug.

Lc0 hätte viel schneller im Endspiel gewinnen können. Es waren fürchterlich stümperhafte Züge im Endspiel.
Kreisklassen-Niveau oder schlechter.


Stümperhaft im Sinne von »hätte wesentlich schneller gewinnen können« oder im Sinne von »zwischendurch zum theoretschen Remis verdorben«? Hab die Partie nicht gesehen.

Wenn ersteres, das hängt mit der Natur des Netzes bzw. der aktuellen Funktion zusammen, nach der Lc0 einen Zug auswählt. Laienhaft ausgedrückt, es wird nicht der beste/schnellste Gewinn gesucht, sondern der »sicherste«. Leider kommt es deswegen zur Zeit auch zu solch Pannen wie gegen Komodo, wo Lc0 eine klar gewonnene Partie gleich mehrfach zum Remis verdorben hat.

Besserung scheint in Sicht, es werden aktuell auch Versuche unternommen, ein Netz mit maximal 12 Steinen auf dem Brett anhand der TB zu trainieren. Laut Lc0-Forum bei Google scheint das Ding gute Fortschritte zu machen: Edit: falsche Zwischenablage: Link

Ciao

Achim

Ps Hier der Link zum Netz
Parent - - By Reinhold Stibi Date 2018-09-17 18:00
55.f4  = Matt in 23 Zügen  

95 Züge hat Lc0 gebraucht,  also 17 Züge zuviel.

Lc0 kann die Syzygy-tbs nutzen. Einstellung bei mir Deep Fritz 15 GUI  Engine-Parameter - List of Syzygy tablebase.

Habe dies kurz ausprobiert, nur scheint mir dass Lc0 die Syzygy-tbs nicht optimal nutzt.
Parent - - By Achim Müller Date 2018-09-17 19:31
Reinhold Stibi schrieb:

Habe dies kurz ausprobiert, nur scheint mir dass Lc0 die Syzygy-tbs nicht optimal nutzt.


Lc0 nutzt zur Zeit nur die wdl (windrawloss), nicht die dtz(distancetozero).

Ciao

Achim
Parent - By Michael Scheidl Date 2018-09-17 20:49
Diese verschiedenen Metriken von Endspieltabellen sind mir ein Graus. Je mehr ich darüber lerne, bzw. lernen will desto weniger verstehe ich. Die Thompson-Tables waren beispielsweise DTC = distance to conversion, also wann zu einem anderen Materialstand übergegangen wird, und konnten glasklare Mattankündigungen liefern. Wieso kann DTZ das nicht?

Was ich für die Benutzer unbequem finde ist, daß selbst wenn schon Tablebasematerial auf dem Brett steht, eine Engine immer noch rechnen muß. Bei den Nalimovs (DTM) gibts das nicht und es kann direkt aus den Tables abgewickelt werden. Das geht dann zack-zack-zack-peng Ende ohne Bedenkzeit. In Fritz lasse ich das sogar die GUI erledigen, es sei denn ich wollte das späte Endspielkönnen von Engines testen.

Ideal für User wäre meines Erachtens DTM50, aber in einem Chat hat man mir unlängst gesagt, das bräuchte den größten Speicherplatz. Doch Maximum ist nicht Optimum; hier mein Subset der 5er-Nalimovs:

Verzeichnis von c:\Tables\Nalimovs-345

[.]              [..]             all-3-men.md5    all-32.md5       all-32p.md5      all-33.md5       all-33p.md5
all-4-men.md5    all-41.md5       all-41p.md5      all-42.md5       all-42p.md5      kbbk.nbb.emd     kbbk.nbw.emd
kbk.nbb.emd      kbk.nbw.emd      kbkb.nbb.emd     kbkb.nbw.emd     kbkn.nbb.emd     kbkn.nbw.emd     kbkp.nbb.emd
kbkp.nbw.emd     kbnk.nbb.emd     kbnk.nbw.emd     kbpk.nbb.emd     kbpk.nbw.emd     knk.nbb.emd      knk.nbw.emd
knkn.nbb.emd     knkn.nbw.emd     knkp.nbb.emd     knkp.nbw.emd     knnk.nbb.emd     knnk.nbw.emd     knnkb.nbb.emd
knnkb.nbw.emd    knnkn.nbb.emd    knnkn.nbw.emd    knnkp.nbb.emd    knnkp.nbw.emd    knnkq.nbb.emd    knnkq.nbw.emd
knnkr.nbb.emd    knnkr.nbw.emd    knpk.nbb.emd     knpk.nbw.emd     kpk.nbb.emd      kpk.nbw.emd      kpkp.nbb.emd
kpkp.nbw.emd     kppk.nbb.emd     kppk.nbw.emd     kqbk.nbb.emd     kqbk.nbw.emd     kqbkq.nbb.emd    kqbkq.nbw.emd
kqk.nbb.emd      kqk.nbw.emd      kqkb.nbb.emd     kqkb.nbw.emd     kqkn.nbb.emd     kqkn.nbw.emd     kqkp.nbb.emd
kqkp.nbw.emd     kqkq.nbb.emd     kqkq.nbw.emd     kqkr.nbb.emd     kqkr.nbw.emd     kqnk.nbb.emd     kqnk.nbw.emd
kqnkq.nbb.emd    kqnkq.nbw.emd    kqpk.nbb.emd     kqpk.nbw.emd     kqpkq.nbb.emd    kqpkq.nbw.emd    kqqk.nbb.emd
kqqk.nbw.emd     kqqkq.nbb.emd    kqqkq.nbw.emd    kqrk.nbb.emd     kqrk.nbw.emd     kqrkq.nbb.emd    kqrkq.nbw.emd
kqrkr.nbb.emd    kqrkr.nbw.emd    krbk.nbb.emd     krbk.nbw.emd     krbkr.nbb.emd    krbkr.nbw.emd    krk.nbb.emd
krk.nbw.emd      krkb.nbb.emd     krkb.nbw.emd     krkn.nbb.emd     krkn.nbw.emd     krkp.nbb.emd     krkp.nbw.emd
krkr.nbb.emd     krkr.nbw.emd     krnk.nbb.emd     krnk.nbw.emd     krnkr.nbb.emd    krnkr.nbw.emd    krpk.nbb.emd
krpk.nbw.emd     krpkr.nbb.emd    krpkr.nbw.emd    krrk.nbb.emd     krrk.nbw.emd     krrkr.nbb.emd    krrkr.nbw.emd
Md5Checker.exe   readme.txt
             112 Datei(en),    726 252 926 Bytes


726 MB und alles praxisrelevante an 5ern ist vorhanden Die kompletten Syz-5er haben zwar auch nur 939 MB, aber wie gesagt, mir passen die Eigenschaften nicht. Das ist offenbar für Engineturniere effizient, aber nicht für einen Privatgebrauch von Schachprogrammen.
Parent - By Tom Paul Date 2018-09-19 08:56
Reinhold Stibi schrieb:

Habe gerade die Partie Lc0 gegen Nemorino im Internet verfolgt. Gewonnen von Lc0 im 94. Zug.

Lc0 hätte viel schneller im Endspiel gewinnen können. Es waren fürchterlich stümperhafte Züge im Endspiel.
Kreisklassen-Niveau oder schlechter.

Was mich verwundert hat war die äußerst geringe Suchtiefe von Lc0 im Endspiel von nur 7-9.
Da muss ein Fehler vorgelegen haben.
Vielleicht lag es auch an der Einstellung von Ponder on mit dem m.E. Lc0 nicht zurecht kommt.


Da musst du nur auf die nächsten beiden größeren Netze warten.
Parent - By Peter Martan Date 2018-09-19 10:06 Edited 2018-09-19 10:09
Hallo Reinhold!

Ich hoffe, es macht dir nichts aus, wenn ich mich an deinen Thread anhänge, auch wenn's nicht um deine, sondern eine weitere Partie aus dem Rapid Rumble Stage2 geht.

Nr. 7, LC0- Andscacs 1-0.

Event:
Ort:
Datum:

Weiss:
Schwarz:

Ergebnis
Board

Bei 25... ist das ...Lc3 ein avoid move, auf den mit leerem Hash alle 3 Großen mehr oder weniger lang reinfallen, SF am kürzesten, gefolgt von H6, der ein bisschen hin und her schwankt, bevor er das nächst bessere ...Lh8 endgültig wählt, komodo bleibt am längsten auf ...Lc3.
Die Partie ist schon aus dem Gleichgewicht, und ob sie nicht schon ohnehin verloren ist, weiß ich nicht, game changing dürfte der am aber doch noch irgendwie gewesen sein, weil danach ist eigentlich keine Hoffnung mehr für Schwarz.

Bei 29. setzt übringens LC0 mit Kg2 den Angriff zwar erfolgreich fort, 29.Txe6 wäre allerdings noch schöner gewesen, finde ich.
Die Kommentare "CF" heißen CFish.
Up Topic Hauptforen / CSS-Forum / Grausames Endspiel von Lc0 bei CCCC

Powered by mwForum 2.29.3 © 1999-2014 Markus Wichitill