Zitat:
(...) insbesondere die Nalimov-DB ihren Zweck bestens erfüllen.
Das stimmt weitestgehend, mit gewissen Einschränkungen:
1. Die 50 Züge-Regel wird ignoriert. Manche Tbs.-Gewinne scheitern in einer praktischen Partie somit an selbiger.
1a. Rochaderechte werden ignoriert, aber das ist praktisch bedeutungslos(*).
2. Keine direkte Bitbase-Funktionalität (das wird aber durch div. Caches abgemildert).
Zu 1: Mir ist erinnerlich - wenn's stimmt - daß die King-Tables die 50er-Regel berücksichtigen. Bei den anderen neuen Formaten weiß ich das nicht.
Zu 2: Beschreibungen zufolge die ich irgendwo gelesen haben, werden Gaviota-Tables u.U. wie Bitbases genutzt sobald sie geladen sind. Ob und inwiefern sich das von der Nutzung im Tbs.-Cache stehender Nalimovs unterscheidet, ist mir allerdings unklar.
Die prinzipielle Neuerung seit Einführung der Nalimovs sind jedenfalls die verschiedenen Bitbases-Formate, die anfangs komplett ins RAM geladen werden und von dort aus sehr schnell benutzt werden können, da überhaupt keine Datenträgerzugriffe mehr nötig sind. Dafür fehlt (meist oder bei allen?) die
Mattdistanz, was dazu führen kann daß eine Engine mitsamt Bitbases kein Matt zustande bringt. In meiner Praxis ist mir das jedoch noch nie aufgefallen.
Bitbases sind u.a.: Shredderbases, Scorpio-Bitbases (da wurden per Default die 5er nicht ins RAM geladen!), sowie Triplebases für Robbolito, Fire u.a. Letztere glänzen mit sehr großen Zugriffszahlen; wieviel es wirklich bringt habe ich nicht getestet.
*) Die Fritz-
GUI reagiert darauf und greift
nicht auf Nalimovs zu wenn noch Rochaderechte bestehen, auch wenn es an sich eine Tbs.-Stellung ist.