TCEC Stockfish verliert auf zeit

By Benno Hartwig Date 2015-10-11 10:32 Edited 2015-10-11 10:41 Upvotes 1

Andererseits legen die TCEC-Regeln fest:

Critical Engine Bugs
 In the case of a serious, play-limiting bug (like crashing or interface communication problems) not discovered during the pre-Season testing, the engine can be updated once per Stage to fix this/these bug/bugs only. If this update still doesn't fix the problem(s) or if there is no update available, the engine might have the number of cores reduced, have the hash size reduced or have the tablebase access disabled - these changes will remain for the rest of the Stage.

Sollte da jetzt nicht doch eine SF-Korrektur erlaubt sein? Manche werden "ja" und andere "nein" sagen. Grenzwertig!
Und auch ein Reduzieren der internen SF-Zeit könnte ausreichend auf einer Linie liegen mit der Verminderung der Thread-Anzahl und der Hash-Größe. Und damit eben auch statthaft sein.

Benno

By Thomas Müller Date 2015-10-11 10:50 Upvotes 1

Bug beheben, engine austauschen und weiter spielen.
Alles andere macht keinen sinn meiner meinung nach und verfälscht das ganze turnier.
Reduzierung von threads oder hash wird den bug nicht beheben.
Schade, aber bei der season8 ist der wurm drin.
Aber alles nicht so "verbissen" sehen....da geht es um nix

gruß
thomas

By Jörg Oster Date 2015-10-11 11:00 Upvotes 1

Thomas Müller schrieb:

Bug beheben, engine austauschen und weiter spielen.
Alles andere macht keinen sinn meiner meinung nach und verfälscht das ganze turnier.
Reduzierung von threads oder hash wird den bug nicht beheben.
Schade, aber bei der season8 ist der wurm drin.
Aber alles nicht so "verbissen" sehen....da geht es um nix

gruß
thomas

Das muss noch nicht mal sein.
Es reicht, eine UCI-Option zu ändern (Move Overhead).

Und in der Tat, ich könnte auch gut damit weiterleben,
wenn Martin das nicht machen möchte und Stockfish
sich nicht für das Finale qualifiziert. Ces't la vie!

Gruß und einen schönen Sonntag allerseits
Jörg.

By Benno Hartwig Date 2015-10-11 11:47

Weiterleben sicher.
Aber das Finale empfänd ich recht uninteressant, wenn Komodo da irgendeine seit langem nicht mehr weiterentwickelte Engine in den Boden stampft.
Berge von Online- und Rechenzeit für den Kampf zweier Engines mit ca. 100 Elo Differenz.
Enttäuschend fänd ich solch ein Ende schon.

Benno

By Dithyrambus Date 2015-10-11 19:19

Die ausschreibung für ein solches turnier darf doch aber bitte auch nicht lauten:

1. Für die drei vorrunden können maximal 30 engines von ihren programmierern oder authorisierten betatestern gemeldet werden.
2.
3.
4.
.
.
.
14. Das finale bestreiten die beiden jeweils aktuellen versionen von Komodo und Stockfish.

Gruß
Horst

By Benno Hartwig Date 2015-10-11 21:35 Edited 2015-10-11 21:37

Sicher.
Aber trotzdem nehme ich mir die Freiheit, z.B. ein Finale Crafty vs. Ginko nicht wirklich spannend zu finden.
Wie interessant und spannend ein Finale ist hängt auch davon aber, wer die Teilnehmer dieses Finales sind.
Benno

By Dithyrambus Date 2015-10-11 22:39

Du schriebst:
Aber das Finale empfänd ich recht uninteressant, wenn Komodo da irgendeine seit langem nicht mehr weiterentwickelte Engine in den Boden stampft.

Aber das heißt doch im klartext, dass man in deinen augen gleich mit dem finale Komodo - Stockfish, also meiner regel 14, hätte beginnen können.
Alles andere war für dich bisher kalter kaffee.

By Benno Hartwig Date 2015-10-11 23:27 Edited 2015-10-11 23:32

Du darfst dein persönliches "Klartext-Verständnis" so bunt und unsachlich publizieren, wie es dir gefällt.
Ich meinte genau das, was ich sagte.
Und die Intensität meines Interesses am Finale hängt in der Tat auch von den Teilnehmern ab.
Du darfst ja gern behaupten, dass dir das total unwichtig wäre.

Möchtest du? Nur zu.

Benno

Noch ein Geständnis:
Mein Interesse am Endspiel bei der Fußball-WM hing auch von den Teilnehmern ab.
Was muss ich doch für ein unfairer Sportbanause sein.
SCNR

By Dithyrambus Date 2015-10-12 01:29

Unsachlich bist du jetzt geworden.
Ende gelände, jedenfalls was mich betrifft.

By Ralf Mueller Date 2015-10-11 23:42

Ich glaube, hier liegt ein Missverständnis vor.
Benno hat nur seinen persönlichen Geschmack geschildert, das ging mit keiner Forderung einher. Genauso hätte er sagen können, dass er ein Finale Junior-Hiarcs sehr schön fände, ohne dass das bedeutet, dass er dafür ist, alle anderen Engines zu disqualifizieren oder Junior und Hiarcs für das Finale zu setzen.

By Dithyrambus Date 2015-10-12 01:43

Hallo Ralf,

das habe ich genau so verstanden, wie du es noch einmal hervorhebst.
Aber der reiz eines turniers besteht doch gerade darin, dass es sich nicht um eine rangliste aus x-tausend partien handelt, sondern dass das unerwartete passieren kann.
So wie Dänemark 1992 und Griechenland 2004 fußball-europameister wurden.

Die verantwortlichen im Stockfish-team haben wahrscheinlich hoch gepokert, Martin spricht von "gambling", und das ist schief gegangen.

So what?
Eine geschichte, über die insider noch in zehn jahren debattieren werden, wie über das Wembleytor?
Wohl eher nicht!

Viele grüße
Horst

By Ralf Mueller Date 2015-10-12 02:12

Sehe ich genauso wie du. Das Stockfish-Team hatte eine riskante Entscheidung getroffen und dazu gehört eben auch, dass man mit den negativen Konsequenzen leben muss.
Dennoch spielen die Engines natürlich nicht nur für sich selber, sondern in erster Linie für das Publikum. Was nützt die größte Regeltreue, wenn der Großteil des Publikums die Regel schlecht findet?
Für die Fans ist es einfach keine schöne Unterhaltung, wenn Partien durch Programmierbugs entschieden werden. Weswegen sollten die Fans mehrere Stunden eine Partie verfolgen, wenn sie wissen, dass in 50% der Fälle wahrscheinlich die Partie durch einen Bug verloren wird.
Ich denke, mit dem Zurücksetzen auf die alte Stockfish-Version (womit das Stockfish-Team immer noch einen Nachteil hat, weil es im Gegensatz zu Komodo nicht updaten konnte) und der Einwilligung aller Programmierer in Stage 3 zu dieser Entscheidung ist eine ausgewogene Lösung gefunden worden.

By Thomas Plaschke Date 2015-10-11 21:06

> Es reicht, eine UCI-Option zu ändern (Move Overhead).

Das ist ja doppelt bitter. "Nur" ein UCI-Parameter. Und als Patch reicht schon die Änderung des Standardwertes für diesen Parameter.

Im Chat sagte Mark Lefler, er wünschte sich, Komodo würde sich etwas mehr Zeit nehmen.

In diesem Augenblick - 37. Zug - hat Komodo 85 Minuten und Stockfish 34. So hat jeder sein Päckchen zu tragen.

Viele Grüße
Th. Plaschke

By ? Date 2015-10-11 10:53

Hallo Benno,

und weil es grenzwertig ist, gibt es wohl im Laufe des Tages ein TCEC Board Meeting.

Aber wie auch immer man entscheidet, es wird falsch sein. Schade eigentlich. Weil in dem nach der Entscheidung die Foren durchbrausendem Tsunami das (Computer-)schachliche untergehen wird.

Viele Grüße
Tobias

By Tom Paul Date 2015-10-11 11:02

Im übrigen, dem Chat zufolge hätte Stockfish nur noch seinen Zug ausführen müssen, damit die TCEC Gewinnregel greift

Angeblich sollen die TCEC Hardware Einstellungen dafür verantwortlich sein, weil nicht alle Prozesse schnell genug bearbeitet werden können, deshalb sollte man immer auf 19 Kernen spielen und einen Kern für OS usw. frei lassen.

Warum wurde das Problem nicht im Framework entdeckt?

Von den über 1300 Zuschauern gestern waren einige wenige dabei die einen 64 Kerne Rechner besitzen und meinten, sie haben das gleiche Problem.
Einer meinte sogar er habe Zugriff auf 128 Kerne.

Für die Zukunft sollte das Stockfish Team schon mindestens einen Rechner mit 64 Kernen haben um solche Unfälle zu vermeiden.
Man muss sich nur mal vorstellen was passieren würde, wenn ein ähnlicher Bug aufgetreten wäre den aber keiner bemerkt, weil die Rechenpower fehlt oder die Einstellungen anders sind.
Und erst ein halbes Jahr später fängt TCEC an und der Bug wird entdeckt, da weis dann auch keiner mehr welche der 1000 neuen Stockfish Devs dafür verantwortlich ist.

By Clemens Keck Date 2015-10-11 12:35

welcher Intel-rechner bietet denn "mind." 64 echte Kerne , Tom Paul ??

Tom Paul schrieb:

Im übrigen, dem Chat zufolge hätte Stockfish nur noch seinen Zug ausführen müssen, damit die TCEC Gewinnregel greift

Angeblich sollen die TCEC Hardware Einstellungen dafür verantwortlich sein, weil nicht alle Prozesse schnell genug bearbeitet werden können, deshalb sollte man immer auf 19 Kernen spielen und einen Kern für OS usw. frei lassen.

Warum wurde das Problem nicht im Framework entdeckt?

Von den über 1300 Zuschauern gestern waren einige wenige dabei die einen 64 Kerne Rechner besitzen und meinten, sie haben das gleiche Problem.
Einer meinte sogar er habe Zugriff auf 128 Kerne.

Für die Zukunft sollte das Stockfish Team schon mindestens einen Rechner mit 64 Kernen haben um solche Unfälle zu vermeiden.
Man muss sich nur mal vorstellen was passieren würde, wenn ein ähnlicher Bug aufgetreten wäre den aber keiner bemerkt, weil die Rechenpower fehlt oder die Einstellungen anders sind.
Und erst ein halbes Jahr später fängt TCEC an und der Bug wird entdeckt, da weis dann auch keiner mehr welche der 1000 neuen Stockfish Devs dafür verantwortlich ist.

By Tom Paul Date 2015-10-11 13:14

Clemens Keck schrieb:

welcher Intel-rechner bietet denn "mind." 64 echte Kerne , Tom Paul ??

Tom Paul schrieb:

Im übrigen, dem Chat zufolge hätte Stockfish nur noch seinen Zug ausführen müssen, damit die TCEC Gewinnregel greift

Angeblich sollen die TCEC Hardware Einstellungen dafür verantwortlich sein, weil nicht alle Prozesse schnell genug bearbeitet werden können, deshalb sollte man immer auf 19 Kernen spielen und einen Kern für OS usw. frei lassen.

Warum wurde das Problem nicht im Framework entdeckt?

Von den über 1300 Zuschauern gestern waren einige wenige dabei die einen 64 Kerne Rechner besitzen und meinten, sie haben das gleiche Problem.
Einer meinte sogar er habe Zugriff auf 128 Kerne.

Für die Zukunft sollte das Stockfish Team schon mindestens einen Rechner mit 64 Kernen haben um solche Unfälle zu vermeiden.
Man muss sich nur mal vorstellen was passieren würde, wenn ein ähnlicher Bug aufgetreten wäre den aber keiner bemerkt, weil die Rechenpower fehlt oder die Einstellungen anders sind.
Und erst ein halbes Jahr später fängt TCEC an und der Bug wird entdeckt, da weis dann auch keiner mehr welche der 1000 neuen Stockfish Devs dafür verantwortlich ist.

Wer hat denn von einem Intel Rechner mit 64 Kernen gesprochen???

Mal davon abgesehen:
http://ark.intel.com/de/search/advanced?s=t&FamilyText=Intel%C2%AE%20Xeon%C2%AE%20Processor%20E7%20v3%20Family
http://www.heise.de/newsticker/meldung/AMD-Prozessoren-Opteron-ist-tot-es-lebe-Opteron-MCM-2777258.html
http://www.3dcenter.org/news/amd-zen
http://www.3dcenter.org/news/zen-details-vier-integer-einheiten-und-vier-128-bit-fliesskomma-einheiten-pro-cpu-kern

By Clemens Keck Date 2015-10-11 14:25

soll das heisen Du meintest 64 AMD Kerne?

Tom Paul schrieb:

Clemens Keck schrieb:

welcher Intel-rechner bietet denn "mind." 64 echte Kerne , Tom Paul ??

Tom Paul schrieb:

Im übrigen, dem Chat zufolge hätte Stockfish nur noch seinen Zug ausführen müssen, damit die TCEC Gewinnregel greift

Angeblich sollen die TCEC Hardware Einstellungen dafür verantwortlich sein, weil nicht alle Prozesse schnell genug bearbeitet werden können, deshalb sollte man immer auf 19 Kernen spielen und einen Kern für OS usw. frei lassen.

Warum wurde das Problem nicht im Framework entdeckt?

Von den über 1300 Zuschauern gestern waren einige wenige dabei die einen 64 Kerne Rechner besitzen und meinten, sie haben das gleiche Problem.
Einer meinte sogar er habe Zugriff auf 128 Kerne.

Für die Zukunft sollte das Stockfish Team schon mindestens einen Rechner mit 64 Kernen haben um solche Unfälle zu vermeiden.
Man muss sich nur mal vorstellen was passieren würde, wenn ein ähnlicher Bug aufgetreten wäre den aber keiner bemerkt, weil die Rechenpower fehlt oder die Einstellungen anders sind.
Und erst ein halbes Jahr später fängt TCEC an und der Bug wird entdeckt, da weis dann auch keiner mehr welche der 1000 neuen Stockfish Devs dafür verantwortlich ist.

Wer hat denn von einem Intel Rechner mit 64 Kernen gesprochen???

Mal davon abgesehen:
<a class='ura' href='http://ark.intel.com/de/search/advanced?s=t&FamilyText=Intel%C2%AE%20Xeon%C2%AE%20Processor%20E7%20v3%20Family'>http://ark.intel.com/de/search/advanced?s=t&FamilyText=Intel%C2%AE%20Xeon%C2%AE%20Processor%20E7%20v3%20Family</a>
<a class='ura' href='http://www.heise.de/newsticker/meldung/AMD-Prozessoren-Opteron-ist-tot-es-lebe-Opteron-MCM-2777258.html'>http://www.heise.de/newsticker/meldung/AMD-Prozessoren-Opteron-ist-tot-es-lebe-Opteron-MCM-2777258.html</a>
<a class='ura' href='http://www.3dcenter.org/news/amd-zen'>http://www.3dcenter.org/news/amd-zen</a>
<a class='ura' href='http://www.3dcenter.org/news/zen-details-vier-integer-einheiten-und-vier-128-bit-fliesskomma-einheiten-pro-cpu-kern'>http://www.3dcenter.org/news/zen-details-vier-integer-einheiten-und-vier-128-bit-fliesskomma-einheiten-pro-cpu-kern</a>

By Benno Hartwig Date 2015-10-12 14:20

> deshalb sollte man immer auf 19 Kernen spielen und einen Kern für OS usw. frei lassen.

Mein i5 (4 Kerne, kein Hyperthreading) reagiert schon etwas zäh, wenn hier 4 Threads voll für Schach werkeln.
Da mag es auch zu Problemchen kommen, wenn ein Thread so wahnwitzig schnell eine Reaktion der CPU braucht und gleichzeitig irgendeine Störung durch einen weiteren Prozess kommt.

Mein i3 (2 Kerne, Hyperthreading) läuft hingegen supergeschmeidig, auch wenn beide Kerne voll werkeln.

Ist ggf. Hyperthreading die Technik, die einem gefahrlos ermöglicht, auf allen Kernen einen Engine-Thread laufen zu lassen?

Benno

By Thomas Plaschke Date 2015-10-12 19:50 Upvotes 1

Ich habe nie, wirklich _nie_ Probleme gewärtigen müssen, wenn Engines alle cores nutzen. - Verwendete Multi-core-CPUs i5-3570, Q9650 und Q6600. Außerdem i3 (mit HT) im Subnotebook.

Wenn man ein ungutes Gefühl hat, kann man in den GUIs Arena und denen von CB zur Beruhigung noch die Priorität auf /BELOWNORMAL setzen. Dann können sich "normale" Prozesse ihre Rechenzeit holen, ohne mit den Engines zu konkurrieren. Aber was soll schon passieren. Wenn ich Turniere spielen lasse, nutze ich den PC nicht anderweitig. Es laufen auch keine anderen Programme im Hintergrund, die eine dauernde Rechenlast erzeugen.

Einen Kern fürs Betriebssystem halte ich deswegen für Verschwendung, weil es überflüssig ist. Was soll das Betriebssystem auch großartig rechnen wollen? - Für die Peripherie gibt es Spezialchips (Grafik, Netzwerk, HD, sonstige I/O), die die Arbeit machen! Hin und wieder die Ergebnisdatei vollschreiben, die eigenen Protokolle führen. Jedenfalls nichts aufregendes.

Wenn man einen 4-Kern-PC nach einem Tag Engineturnier auf im Taskmanager kontrolliert und da stehen dann für "Betriebssystem-Programme" kumulativ und verteilt über den ganzen Tag bspw. 14:21 min CPU-Zeit (nach meiner Erfahrung schon recht hoch gegriffen), mache ich mir nicht die Hosen voll, weil bei einer 4-Kern-CPU dagegen 5745:39 min Engine-Last stehen. Im Beispiel fehlen den Programmen über den Tag 2,5 Promille der gesamten Rechenkapazität der CPU. Ich bin mir recht sicher, dass keine Engine darunter leiden müsste. Im Übrigen wäre die "Zusatzlast" vom BS vermutlich auf alle cores verteilt... Bei 20 cores! -Mal ernsthaft... Und selbst bei 4 cores...
Aber ich kenne das Gefühl. Man glaubt, der PC wäre irgendwie blockiert, wenn man ihm nicht explizit etwas Rechenkapazität opfert. Aber in Single-Core-Zeiten haben wir das ja auch nicht gemacht - weil wir's auch gar nicht gekonnt hätten. Hatte damals jemand das Gefühl, was falsch zu machen?

Viele Grüße
Th. Plaschke

By Anonymous Date 2015-10-11 11:05

Es ist aber kein "play-limiting" bug, denn stocki spielt ja quasi bis zum Ende durch.
(Der Bug wird dann auffällig, wenn nur noch die 30 s vorhanden sind, stocki sich aber 30.01 s in Anspruch nimmt.)
Bei den beiden anderen Partien, welche von Stockfish gewonnen wurden, waren ja noch jeweils mehrere Minuten vorhanden.
Also dürfte - streng sehen - kein binary-update erlaubt sein.

Und für die nur "UCI-Paramter-Änderung" sind halt bislang nur "threads-minderung", "hash-minderung" und "no-tb" vorgesehen.
Also wenn man es ganz streng sieht, die ("MaxTime") auch nicht infrage kommen kann.
Durch den lazy-patch wird schlechte Zeiteinteilung (2. bug) noch verstärkt, so dass man - wenn jetzt gar nichts gemacht wird - wieder in die "increment-Zeitnot" gerät und dadurch das superfinal - sehr wahrscheinlich - verpassen wird.

By Clemens Keck Date 2015-10-11 10:49

Vielen Dank Dirk !!

dieser wichtige thread zum Thema ist mir leider völlig entgangen.

Gruß, Clemens

Dirk Triebel schrieb:

Hallo Clemens,

dazu gibt es bereits einen Thread:

<a class='ura' href='http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?tid=8595'>http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?tid=8595</a>

Erweitert kann ich nur dazu sagen, dass es von den Stockfish team sehr riskant war einen solchen umstrittenen Patch im TCEC spielen zu lassen. Ich habe gestern von Martin rausgelesen, dass es eine Lösung geben soll, eine Entscheidung gibt es aber noch nicht. Es wurde auch diskutiert eine neue Version einzusetzen. Larry fand das nicht so toll, da es ja beispielsweise bei Ginko auch nicht gemacht wurde und andere engines sogar ausgeschlossen wurden. Soweit ich weiß, ist es laut Regelwerk nicht erlaubt.

ICh könnte mir vorstellen, dass der Hash zurückgesetzt wird. Ob das dann hilft und fürs Finale reicht, weiß ich nicht.

Gruß,
Dirk

By Jörg Oster Date 2015-10-11 10:56

Dirk Triebel schrieb:

Hallo Clemens,

dazu gibt es bereits einen Thread:

<a class='ura' href='http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?tid=8595'>http://forum.computerschach.de/cgi-bin/mwf/topic_show.pl?tid=8595</a>

Erweitert kann ich nur dazu sagen, dass es von den Stockfish team sehr riskant war einen solchen umstrittenen Patch im TCEC spielen zu lassen. Ich habe gestern von Martin rausgelesen, dass es eine Lösung geben soll, eine Entscheidung gibt es aber noch nicht. Es wurde auch diskutiert eine neue Version einzusetzen. Larry fand das nicht so toll, da es ja beispielsweise bei Ginko auch nicht gemacht wurde und andere engines sogar ausgeschlossen wurden. Soweit ich weiß, ist es laut Regelwerk nicht erlaubt.

ICh könnte mir vorstellen, dass der Hash zurückgesetzt wird. Ob das dann hilft und fürs Finale reicht, weiß ich nicht.

Gruß,
Dirk

Ich aber, die Größe des Hashs hat damit nichts zu tun.

By Benno Hartwig Date 2015-10-11 12:19 Edited 2015-10-11 12:27

Eine Engine-Korrektur ist laut TCEC-Statuten auch während einer Stage möglich, wenn es sich um einen "serious, play-limiting bug" handelt.
Und das ist dann wohl zu entscheiden.

Ich hoffe und vermute, dass wir in Stage 3 noch einen bugbereinigten SF sehen werden!
Oder wir werden sehen, dass SF fortan mit kleinerem persönlichen Zeitkonto in die Partien geht.
Beides geben die Regeln dem Geist nach meiner Meinung nach her!
SF hat dann auch noch gute Chancen auf das Finale!
Denke ich mal so.

Benno

By Ralf Mueller Date 2015-10-11 13:01

Weswegen wurde aber dann den vielen ausgeschlossenen Engines in diesem Turnier nicht so ein Update gestattet?

By Tom Paul Date 2015-10-11 13:15

Weil sie sowieso den kürzeren gezogen hätten.
Und weil keiner Lust auf Alfil usw. Partien hatte.

By Benno Hartwig Date 2015-10-11 13:33

Wurde denn bei diesen Engines seitens der Entwickler ein spezieller Update für die aufgetretenen Probleme angeboten?
Die hätten dann wohl schon unbedingt akzeptiert werden müssen.
Ich hörte davon aber nicht! Weißt du den von derartigen konkreten, angepassten Engine-Angeboten?

Benno

By Ralf Mueller Date 2015-10-11 15:24 Edited 2015-10-11 15:28

Es wurde noch während der laufenden Stufe 2 (also bevor überhaupt definitiv klar war, welche Engines das alles betreffen würde) beschlossen, alle Engines, die mehr als drei Zeitverluste hatten, aus dem Turnier zu nehmen. Die Engineautoren hatten gar keine Gelegenheit, hier zwischen den Stufen nachzubessern.

By Benno Hartwig Date 2015-10-11 15:34

Stimmt einerseits,
andererseits hörte ich nicht von irgendwelchen Reaktionen der Entwickler auf die wiederholten Abstürze ihrer Engines.

Wir sehen, dass sich Martin durchaus auch zur Laufzeit seines Events Gestaltungsspielräume nimmt.
Meines Erachtens hat er sie auch vernünftig genutzt.
Ich vertraue darauf, dass er auch jetzt einen Weg beschreitet, der sich nicht sklavisch an den Buchstaben sondern an der Idee seines Regelwerkes orientiert.
Und da gibt es ja recht plausible Möglichkeiten.

Benno

By Ralf Mueller Date 2015-10-11 16:18

Hast du irgendwelche Reaktionen der Stockfish-Entwickler (M. Costalba) mitbekommen? Ich finde, hier wird mit zweierlei Maß gemessen.
Das ganze war eine riskante Entscheidung der SF-Entwickler, diesen Patch nicht ausreichend getestet zu verwenden (Martin nannte es in seinem Videostatement "gambling") und zu einer riskanten Entscheidung gehört eben das Risiko, dass es schiefgeht. Und das ist hier passiert.
Ich fände es unfair, jetzt die Regeln zu beugen, damit wir das Finale haben, was wir haben wollen. Das hat dann nichts mehr mit gleichen Chancen und Wettbewerb zu tun.

By Ludwig Buergin Date 2015-10-11 17:27

Martin könnte , wenn es seine Regularien erlauben, Stockfish mit einem kleineren Hash von etwa 1024 oder 1535 fahren.Bei so langen Spielzeiten ergibt sich dadurch kaum eine nennenswerte Schwächung der Spielstärke.Es wäre ein Versuch,schlechter kann es dadurch für Stockfish auch nicht werden.

Gruß Ludwig

By Benno Hartwig Date 2015-10-11 21:20

Stimmt schon, ich weiß nichts von der Kommunikation zu irgendeinem Entwickler.
Ich vermute aber sehr stark(!), dass für SF liebend gern eine korrigierte Version zur Verfügung gestellt würde
und da ausdrücklich eine Engine-Korrektur in den Regeln als möglich beschrieben wurde und ich nicht von solch einem Angebot hörte, vermute(!) ich, dass es kein Angebot einer korrigierten Engine nach den Abstürzen der anderen Engines gab. Solch eine Korrektur stelle ich mir auch durchaus schwierig vor.
Sei ganz sicher: wir würden sonst sicher noch von solch einer Peinlichkeit hören (wenn die Engine regelwidrig abgelehnt worden wäre, meine ich)
Insofern messe ich meiner Meinung nach nicht mit verschiedenerlei Maß.

Es wäre auch keine Regelbeugung für SF (meiner Meinung nach), wenn für SF eine andere Version oder kürzere Zeiten akzeptiert würden. Es entspräche sogar sehr gut dem Geist des aktuellen Regelwerks, finde ich.

Benno

By Ralf Mueller Date 2015-10-11 21:47 Edited 2015-10-11 22:06

Zitat:

Es wäre auch keine Regelbeugung für SF (meiner Meinung nach), wenn für SF eine andere Version oder kürzere Zeiten akzeptiert würden. Es entspräche sogar sehr gut dem Geist des aktuellen Regelwerks, finde ich.

Nach Martins Auslegung in seinem Statement ist es kein play-game limiting bug. Insofern ist es eine Regelbeugung.

Aber ich finde das Urteil, wie es jetzt gekommen ist (dass Stockfish auf die letzte Version zurückgesetzt wurde und alle anderen Teilnehmer für Zustimmung befragt wurden), auch gut. Dann sollte man aber die Regeln auch dementsprechend ändern. Denn reichlich unfair ist es jetzt natürlich gegenüber den ausgeschlossenen Engines, die im Gegensatz zu Stockfish tatsächlich einen play-limiting bug hatten und nicht einfach auf die letzte unter TCEC-Bedingungen stabil gelaufene Version zurückgesetzt wurden (bspw. Junior) - noch nicht mal nach Abschluss der gesamten Stage, während es Stockfish während der Stage gestattet ist.

By Gysi Date 2015-10-11 19:33

Eine sehr gute Entscheidung, wie ich finde.
Es hat sich wieder einmal bewahrheitet: impatientia malus consultor.

By Ralf Winterfeld Date 2015-10-11 21:00

Sollte das Finale Komodo vs Gull oder H4 oder ähnliches herauskommen so gibt es kein Kaufanreiz für Komodo, denn Komdo wird das Finala dann sowieso gewinnen.

Ein Kaufanreiz für Komodo sehe ich nur wenn es im Finale gegen SF spielt und gewinnt.

Ich hoffe dass mit Frizt15 ( Rajlich engine) und dem neuen Shredder zwei neue Kandidaten an die Spitze gelangen so dass zukünftig bei TCEC dann 4 Engines Kopf an Kopf liegen. Aber ich fürchte diese beiden neuen Engines werden ca. 70 ELO oder mehr unterhalb SF und Komodo liegen

By Benno Hartwig Date 2015-10-12 12:38

Auf 70 Elo an SF und K heranzukommen wäre aus meiner Sicht für Fritz (am 30. Oktober, sagt Amazon) und Shredder (ich hoffte irgendwie auf den Herbst, las aber noch nirgends was Konkretes) ein Riesenerfolg.
Dafür müssten Rybka und Shredder12 doch gewaltig dazulernen.
Ich zweifle an solchen Sprüngen.

Das hängt auch davon ab, ob Stefan und Vas wieder so richtig engagiert an ihren Engines arbeiten oder ob sie mehr beiläufig eine neue Version rausbringen möchten.
Aber mal sehen...

Benno

By Tom Paul Date 2015-10-12 12:58

Wieso? Da könnte Vas doch einfach (für ihn) Houdini und Rybka fusionieren und somit die Schwächen der jeweils anderen Engine ausbügeln.

By Ralf Mueller Date 2015-10-12 13:00 Edited 2015-10-12 13:02

Klar! Oder am besten einfach noch mit Stockfish fusionieren. Also weniger als ein Plus von 100 Elo zu Stockfish wären schon echt stümperhaft, eine absolute Blamage.

By Benno Hartwig Date 2015-10-11 21:27 Edited 2015-10-11 21:29

Ein "Bravo!" für TCEC und diese Entscheidung!
Und ein "Bravo!" für die Konkurrenten in Stage 3, die sportlich fair und einhellig diesem Vorgehen zugestimmt haben!

Benno

PS
Und der mahnende Unterton an das SF-Team
"but the championship is not a testing and debugging ground. This is an important point to make clear."
ist sicher auch angekommen