Puisqu'il n'y a pas de publication complète unique, elle est basée sur le code de sondage , le générateur et diverses explications de Ronald de Man (l'auteur du générateur).
Lorsque vous testez à peu près n'importe quelle base de table (alias une énorme carte de hachage compressée):
- La position est normalisée ...
- ... mappé à un index entier.
- L'index est recherché dans une table qui identifie le "bloc" auquel il appartient.
- Le bloc est décompressé jusqu'à ce que les informations de l'index puissent être récupérées.
Ensuite, il y a généralement du code "en dehors" du sondage, au moins pour résoudre les captures en passant.
En commençant par le code extérieur pour WDL. Les tables Syzygy utilisent une optimisation basée sur l'observation suivante: Si une position a une capture qui atteint une valeur particulière (par exemple, gagne), alors la position elle-même a au moins cette valeur (par exemple, gagne). Dans ce cas, la table peut stocker une valeur arbitraire inférieure, la meilleure pour la compression, et cela peut être facilement corrigé en vérifiant les sous-tables pour les captures.
Pour obtenir un DTZ, une sonde WDL doit être effectuée en premier. Si la position est tracée, DTZ est égal à 0 et la table peut stocker tout ce qui est le mieux pour la compression. Si le meilleur mouvement était une capture (dont nous nous souvenons de la sonde WDL), alors le DTZ est de +/- 1 ou +/- 101 selon le WDL, et la table peut à nouveau stocker n'importe quoi, selon ce qui est le mieux pour la compression.
Les tables Pawnful contiennent 4 sous-tables, une pour chaque fichier du "pion principal" (après normalisation).
Les (sous-) tables WDL sont bilatérales, c'est-à-dire qu'elles contiennent essentiellement deux tables séparées pour chaque côté de la fin de partie (sauf si le matériau est symétrique).
Les tables DTZ ne stockent qu'un seul côté à déplacer. Une brève recherche à 1 pli peut donc être nécessaire pour calculer la DTZ de l'autre côté.
(1) À propos de la normalisation: Il existe plusieurs façons de procéder et il n'est pas facile de dire à l'avance laquelle conduira à la meilleure compression. Le générateur essaie simplement différentes permutations. L'ordre final des pièces est stocké dans l'en-tête du fichier de table.
(2) Quelques combinatoires. Le défi n'est pas d'avoir de grandes lacunes pour des positions impossibles. Bien que ce soit assez délicat, je ne pense pas que Syzygy fasse quelque chose de spécial ici. Conceptuellement, des pièces ou des groupes de pièces sont placés sur le plateau dans l'ordre spécifié dans l'en-tête.
(3) Les valeurs compressées sont stockées dans des blocs. La taille du bloc est spécifiée dans l'en-tête du tableau. La table mappant les index aux blocs est clairsemée, elle permet donc de sauter très près du bloc correct et nécessite ensuite un bref balayage avant ou arrière pour trouver le bloc exact. Un bloc peut stocker des valeurs pour au plus 65536 positions.
(4) Les tables Syzygy utilisent une compression personnalisée basée sur RE-PAIR . Une caractéristique importante est qu'elle permet en fait de profiter des opportunités de stockage de valeurs arbitraires identifiées ci-dessus. La décompression est très rapide et peut s'arrêter dès que la valeur de l'index souhaité est disponible.
Facultativement, les tables DTZ peuvent nécessiter une autre étape f (wdl, valeur stockée) = valeur réelle. Cette mappe DTZ supplémentaire est référencée dans l'en-tête du tableau et est elle-même un tableau avec des entrées 8 bits. (Malheureusement, cela s'est avéré insuffisant pour les finales à 7 pièces, même avec des pions, il y a donc maintenant un autre indicateur qui permet les entrées sur 16 bits).
Pour les valeurs DTZ, si le générateur a déterminé que toutes les valeurs d'une table sont inférieures à 100, un décompte précis des demi-mouvements n'est pas requis pour garantir un jeu parfait. Au lieu de cela, il définit un indicateur dans l'en-tête du tableau et arrondit les demi-mouvements en mouvements complets pour économiser de l'espace.
Il est également clair qu'il n'est pas nécessaire de stocker le signe, ou un décalage supplémentaire de +/- 100 pour les finales maudites, car cela peut être déduit de la valeur WDL.
La décompression étant très rapide, aucun cache n'est nécessaire. Au lieu de cela, les moteurs peuvent s'appuyer sur le cache de page des systèmes d'exploitation pour stocker des blocs (toujours compressés).
Les tables de 6 pièces contiennent des informations WDL et DTZ pour 3 787 154 440 440 positions uniques sur 150 gigaoctets, soit ~ 0,3 bits par position.
Dans l'ensemble, les tables Syzygy se sont améliorées par rapport aux formats de base de table précédents dans au moins 3 de ces domaines, ce qui en fait un format très compact et rapide. Étonnamment, le générateur est également assez rapide.
Et bien sûr, utiliser le DTZ50 est un choix pragmatique, car il s'agit juste de suffisamment d'informations pour progresser de manière fiable et permet un jeu parfait (résultat écrit) avec et sans la règle des 50 coups. Cependant, sur la base des modifications apportées à Cfish qui ont été publiées jusqu'à présent (RdM travaille maintenant sur les tables DTM), de nombreuses techniques s'appliqueront également au DTM.
