Du kennst es nicht nur nicht, du hast auch die viele Mühe, die ich mir gab, es zu erklären, nicht wirklich gewürdigt.

Es gab ab Rybka 3.x (wenn es nicht erst eine 4er Version war, müsste ich jetzt nachforschen, spielt aber keine Rolle), eine Rybka- Version, die über chessbase unter diesem Namen verkauft wurde, mit der begann es möglich zu werden, Rybka als EngineA und als EngineB zu laden über einen eigenen GUI- Befehl, von dem die eine Partition single thread lief und die andere SMP, die eine konnte man bei der Analyse so wie jede chessbase- Engine "sperren", sodass sie auf der Brettstellung weiterrechnete, auch bei Eingabe von Zügen übers GUI in die andere.
Beide "Engines" hatten einen gemeinsamen Hash (also echten shared hash) und man konnte beim Analysieren zuschauen, wie sich durch Eingabe von Zügen mit der einen Engine der Output der anderen änderte. Das geht immer noch mit Fritz 15, der die das ja auch eine Rybka 4.x- Engine ist, auch wenn Fritz 15 ebenso wie Rybka keine nativen chessbase- Engines sind oder waren, sie taten und tun nur so. Du kannst sie ja auch in anderen GUIs als UCI- Engines installieren, was du mit nativen nicht kannst.

Und ja, es handelt sich um shared hash nur einer einzigen Engine, die aber in 2 Settings gestartet wird und jetzt kannst du damit über das "Anfüttern von Hash" mit der einen Partition derselben Engine den gemeinsamen anders, gezielter, interaktiver füllen (lassen), als mit einer allein.

Nucleus tut etwas ähnliches, wenn du z.B. SF als Slave2 und als Master lädst, dann Slave1 (z.B Ceres) (automatisch) seinen bestimmten einstellbaren Zeitanteil lang gerechnet hat, SF in der Folge ebenso, derselbe SF als Master noch einmal dran kommt und (nur, wenn sich die beiden Zugvorschläge unterscheiden) den einen (und den anderen) zwangsweise ebenfalls als primary line, weil schon "am Brett ausgeführt" (nur in der internen Berechnung und Bewertung) neuerlich, wieder eine vordefinierte Zeit lang weiterberechnet in Hinblick auf den besten Gegenzug.
So wird von der Master- Engine der eine mit dem anderen Zug in der Bewertung "nach dem Ausführen" an der Gegenzug- Stellung neu bewertet und in der Sortierung bzw. der Reihung und der Eval dann erst entschieden.

Alles klar?
Nichts anderes hätte ich (jetzt zunächst mal) gerne weiter entwickelt. Nucleus 0.0.1 hat momentan nur folgende Schwachpunkte als Analyse- Engine für mich: go inifinite wird nicht unterstützt, und es können "nur" maximal je 2G hash für die einzelnen Engines zugeteilt werden.

Wenn's dich wirklich interessiert, worum's in diesem Thread geht oder hätte gehen sollen, lies dir die Links durch, die ich am Anfang gesetzt hatte zur Berschreibung von Nucleus.
Dann danke für dein Interesse und lass uns gerne weiter drüber reden, wenn du nur anmerken wolltest, dass es das alles nicht gibt, und es ohnehin keinen Sinn hätte, wenn's es gäbe, habe ich das jetzt auch schon verstanden und bin dir auch nicht weiter böse.

Richtig, Jörg, danke.
Aber wie gesagt, ich wäre schon mit der besseren Nutzung zweier Hashtable- Speicher (oder eines NN-Cache und eines Hash- Speichers) über eine indirekte Kommunikations- Schnittstelle einer GUI- Funktion zufrieden. Eigentlich ist das, was Nucleus macht, ja auch mehr eine GUI- Aufgabe als die einer Engine selbst.

Marco Costalba hatte mal so etwas als Batch- Datei für SF, um ihn (für SF) besonders schwierige Stellungen besser lösen zu lassen, bzw. die Teststellungen als besonders schwer (für SF) zu filtern.

Das gab einfach nach einer bestimmten Standrechenzeit den Lösungszug der Engine vor und danach wurde noch einmal eine Weile gerechnet.
Seine Testsuite hieß übrigens Poor Fish.

http://talkchess.com/forum3/viewtopic.php?f=2&t=61526&hilit=poor+fish+costalba&sid=682c3dcf9c332bd33b295c76ae78929a&start=10

Da gab's sogar eine github- site von ihm eigens dazu, ist nicht mehr aktiv:

http://talkchess.com/forum3/viewtopic.php?p=687439#p687439

Das Tool, das Marco dafür erstellte, nannte er double blind test:

http://talkchess.com/forum3/viewtopic.php?p=687518&sid=682c3dcf9c332bd33b295c76ae78929a#p687518

Die typische Erfüllung des Lehrsatzes "Der Stellungstest testet die Teststellungen". Das wurde in grauer Vorzeit von den Teststellungs- und Stellungstest- Phobikern gerne als Totschlagargument gegen die verwendet, die über Teststellungen auch nur zu schreiben wagten. Dass sie nur ihre eigens (Des)interesse damit totgeschlagen haben, ist Vielen vielleicht immer noch nicht aufgefallen. Muss ja keiner Stellungstests machen und muss sich ja keiner mit Teststellungen befassen, aber womit man sich im Schach als Mensch dann überhaupt befassen soll, wenn nicht mit Stellungen, das frag' ich mich halt auch immer wieder. Ja, mit Plänen, Partien, von mir aus Zügen. Aber ohne Stellungen, von denen man ausgeht?
Natürlich testet der Stellungstest die Teststellungen, ich fand das immer ausgesprochen gut, wenn's denn so war und sich dabei dann herausstellte, dass es gute Teststellungen für gute Stellungstests waren. Und herauszufinden, dass schlechte Teststellungen schlechte Stellungstests ergeben, wäre vielleicht auch für Leute gut, die schlechte Eröffnungsstellungen für schlechte Engine- Matches verwenden und sich wundern, anstelle sich klar zu machen, dass es auch nur ausgespielte Stellungstests waren und sind, von Eröffnungsteststellungen ausspielen zu lassen.
So what?

Immer nur von der Grundstellung aus spielen Lassen und nicht einmal mehr Zuschauen, weil man eh bei den kurzen TCs, um Partiezahlen zu bekommen, sowieso nichts mehr mitbekommt, was am Brett vorgeht, je besser die Engines werden, umso weniger. Ist es wirklich das, was das Computerschach ausmacht?
All diese Dinge bringe ich auch deshalb mal wieder in Erinnerung, um die Stellungstest- Phobiker ein bisschen mit Leuten, denen man wirklich nicht vorwerfen kann, sie kennten den Unterschied zwischen "Stellungstests", und "praktischer Spielstärke" nicht.

Marco Costalba hat das SF- Framework auf die Beine gestellt, dass sich der trotzdem nicht zu gut war, sich mit Teststellungen und Stellungstests zu befassen, sollte man sich mal auf der Zunge zergehen lassen, bevor man sich wieder einmal aus einem alten Schützengraben eines alten Lagerdenkens hervortut.
Ich kann mich noch gut an Statements von Gerhard Sonnabend und Ingo Bauer (schade, dass beide nicht mehr hier schreiben) erinnern, wenn sie einander zuprosteten hier, es würden immer wieder mal die Stellungstester aus ihren Löchern hervorkommen und sie meinten damit, sie würden in den Foren dann schon dafür sorgen, dass sich diese "Anderen" möglichst bald wieder verstecken müssten.

Inzwischen meint sogar Prof. Althöfer, beim Elobolzen im heutigen Computerschach fehlten der Messung Parameter. Beim Stellungstest hätte man gleich mal beliebig viele Vergleichsparameter, vorausgesetzt, man macht nicht denselben Fehler wie beim Eng-Eng, sich auf die ganzen und halben Punkte allein zu beschränken.
Die Teststellungen als solche geben soviel mehr her, natürlich muss man immer jede einzelne in Hinblick auf Output- Lines betrachten, und ja, das macht Arbeit am Brett, und nein, man muss es nicht so machen, wie der Nachbar oder die- oder derjenige, der's einem gerade in einem Forum vorschreibt. Dafür braucht man aber eigentlich auch wirklich nicht mehr darum zu streiten, ob's überhaupt Sinn macht, Teststellungen als solche zu betrachten.

Das ist übrigens der härteste Kampf unter den "Lagern" im Computerschach seit grauer Vorzeit, und jetzt erst recht, wo's die Elo auch nicht mehr als Argument für sich hergeben. Das "Testmonopol" möchte ich es nennen, oder die "Testhoheit". Mehr als die Programmierer untereinander waren einander von Anfang an die Tester um die Programme neidig, die sie auf ihre ureigenste und unbestreitbarste Art testen durften, heutzutage wären die Profitester froh, wenn sie mit den Versionsentwicklungen und den Netzen und der der Hardware- Entwicklung überhaupt noch halbwegs mitkämen.
Heute ist der Kampf deshalb noch eine Nummer verbissener, weil die User, an die die Tests delegiert werden, damit sie Hardware- Zeit zur Verfügung stellen, (was wäre SF und LC0 und Ceres denn heute ohne solche Bots auf Hardware von Usern?) von den Entwicklern und deren in Patch- Verantwortung stehenden Testern bei der Stange, sprich einem bestimmten Framework, gehalten werden müssen.

Ich würde ja in solchen Zusämmenhängen immer lieber nur von den einzelnen Teststellungen selbst reden, nur um solche geht's immer, egal, ob es taktische single best moves sind oder Eröffnungsstellungen.

Die Eröffnungstestsets zum Ausspielen Lassen mit weniger Remisquote sind für mich überhaupt ein Zwischending zwischen ausgespielten Stellungstests und "purem" Eng-Eng, das die "praktische Spielstärke" ja heutzutage auch schon absolut nicht mehr absolut abbildet, sondern auch nur mehr streng relativiert gesehen im Zusammenhang mit Hardware- TC, Teilnehmerfeld und eben Eröffnunsstellungen, jedes noch so breite und kurze Buch ist eine Testsuite für sich. Transitivität lässt grüßen und verabschiedet sich auch gleich wieder vollends.
Ich beginne wieder etwas in die Gebetmühle zu verfallen, sorry...