Dies hat sich - DeepL sei dank - inzwischen ziemlich geändert ( deepl.com ). Nachfolgend ein Vergleich zwischen dem Google Translator und DeepL.

Englisches Original (Teil der Beschreibung eines NNUEs):
The network should have relatively low amount of non-zero inputs.
The inputs should change as little as possible between subsequent evaluations.
The principle 1. means that when the network is scaled in size the inputs must become sparse. Current best architectures have input sparsity in the order of 0.1%. Small amount of non-zero inputs places a low upper bound on the time required to evaluate the network in cases where it has to be evaluated in its entirety. This is the primary reason why NNUE networks can be large while still being very fast to evaluate.
The principle 2. means that in most turn based games it can take advantage from the fact that a single move changes the board state only slightly. This is of lower importance than the first principle and completely optional for the implementations to take advantage of, but nevertheless gives a measurable improvement in implementations that do care to utilize this assumption.

Google Translator:
Das Netzwerk sollte eine relativ geringe Menge an Nicht-Null-Eingängen haben.
Die Eingaben sollten sich zwischen aufeinanderfolgenden Auswertungen so wenig wie möglich ändern.
Das Prinzip 1. bedeutet, dass die Eingaben spärlich werden müssen, wenn das Netzwerk in der Größe skaliert wird. Gegenwärtig beste Architekturen haben eine Eingabespärlichkeit in der Größenordnung von 0,1 %. Eine kleine Menge von Eingaben ungleich Null legt eine niedrige Obergrenze für die Zeit fest, die erforderlich ist, um das Netzwerk in Fällen zu bewerten, in denen es in seiner Gesamtheit bewertet werden muss. Dies ist der Hauptgrund, warum NNUE-Netzwerke groß und dennoch sehr schnell auszuwerten sind.
Das Prinzip 2. bedeutet, dass es in den meisten rundenbasierten Spielen davon profitieren kann, dass ein einzelner Zug den Brettzustand nur geringfügig ändert. Dies ist von geringerer Bedeutung als das erste Prinzip und für die Implementierungen völlig optional, um davon zu profitieren, ergibt aber nichtsdestotrotz eine messbare Verbesserung bei Implementierungen, die darauf achten, diese Annahme zu verwenden.

DeepL:
Das Netzwerk sollte eine relativ geringe Anzahl von Eingaben haben, die nicht Null sind.
Die Eingaben sollten sich zwischen aufeinanderfolgenden Auswertungen so wenig wie möglich ändern.
Der Grundsatz 1. bedeutet, dass die Eingaben spärlich werden müssen, wenn das Netz in der Größe skaliert wird. Die derzeit besten Architekturen haben eine Eingabedichte in der Größenordnung von 0,1 %. Eine geringe Anzahl von Eingaben, die nicht Null sind, setzt eine niedrige Obergrenze für die Zeit, die für die Bewertung des Netzes in Fällen benötigt wird, in denen es in seiner Gesamtheit bewertet werden muss. Dies ist der Hauptgrund, warum NNUE-Netze groß sein können und dennoch sehr schnell ausgewertet werden können.
Das Prinzip 2. bedeutet, dass es in den meisten rundenbasierten Spielen die Tatsache ausnutzen kann, dass ein einzelner Zug den Zustand des Brettes nur geringfügig verändert. Dies ist von geringerer Bedeutung als das erste Prinzip und es ist den Implementierungen völlig freigestellt, diesen Vorteil zu nutzen, führt aber dennoch zu einer messbaren Verbesserung bei Implementierungen, die diese Annahme nutzen wollen.
Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Das ist ein schlagkräftiges Argument.

Hallo Benno,

ob es nun anderen begegnet weiß ich nicht.
Fällt z. B. fast allen Listenbetreibern nicht auf da fast alle mit Aufgabefaktor spielen lassen.
Glaube FCGR läßt auch ohne Aufgabefaktor spielen.

Beim FCP Tourney-2020 musste ich die Endspieldatenbanken bei Fritz 16 deaktivieren.
Danach gab es keine Hänger unter der Shredder 12 GUI.

Bei den vorherigen Test-Turniere bzw. auch späteren Test-Turnieren hatte ich die Probleme mit Fritz 16.
Dachte auch erst es liegt an defekte Dateien bei den Endspieldatenbanken aber dem war nicht so.

Wie gesagt, dass ich ein typisches Problem so einiger Engines.
z. B. hatte Minic das Problem auch eine längere Zeit, musste die Engine gar aus dem Turnier nehmen und der Programmierer konnte zunächst nicht nachvollziehen.
Bei neueren Minic Versionen gelöst.

4.x Versionen von Chiron (hier aber seltener).
Bei neueren Chrion Versionen gelöst.

Habe die Programmierer mit Infos zu dem Fehler versorgt.

Hannibal Versionen (hier auch seltener).

Bis zurück in Winboard Zeiten waren es so einige Engines.

Da ich nicht täglich auf die Rechner im Netzwerk achte ist das unangenehm wenn ein Match hängt.

Viele Grüße
Frank

Läßt Du denn auch tausende von Partien auf Deinen Rechner ohne Aufgabefaktor laufen?
Ich meine wenn Du so gezielt schreibst das Du diesen Fehler nicht kennst.
Oder schreibst Du das nur weil Du vielleicht "Rybka" gut findest?