Articulo original : https://www.freesoft.org/software/hoffman/13Sep2018/reference.pdf
Por : Brent Baccala
Septiembre 13, 2018
Hoffman es un programa para resolver finales de ajedrez usando análisis retrógrado, que es muy diferente de los programas convencionales de ajedrez por computadora. El análisis retrógrado solo es útil en el final, funciona muy lentamente y produce enormes cantidades de datos. Su gran ventaja radica en su capacidad para resolver completamente el final. En un sentido muy real, un motor retrógrado no tiene un "horizonte de movimiento" como un motor de ajedrez convencional. Lo ve todo. Para aquellos que no estén al tanto de la cultura estadounidense, el programa lleva el nombre de Trevor Hoffman, un lanzador de béisbol All Star que se especializa en "cerrar" juegos. Fue escrito específicamente para el juego The World vs. Arno Nickel.
Hoffman usa XML extensivamente tanto para configurar su operación como para etiquetar las bases de datos resultantes. De hecho, una base de datos Hoffman completa (típicamente en un archivo .htb) es solo un archivo comprimido con gzip que contiene un prefijo XML seguido de datos binarios de la base de datos (en un formato especificado por el XML). Básicamente, para operar Hoffman, se escribe un archivo XML que especifica el análisis que se quiere hacer, y luego se lo alimenta al programa. Como salida, produce una versión modificada del XML de entrada que incluye datos binarios de la base de datos añadidos al final.
1 Procesamiento Paralelo con Hoffman
Un análisis de Hoffman puede ser bastante intensivo en computación. El programa se puede compilar para usar hilos POSIX (si están disponibles), con el número de hilos especificado en tiempo de ejecución usando la opción -t. El programa también está diseñado para usar múltiples computadoras en paralelo, todas trabajando simultáneamente en un análisis. Esto se logra dividiendo el análisis en piezas más pequeñas, cada una con su propio archivo de configuración XML.
2 Tablas de propagación
Un análisis de Hoffman también puede ser bastante intensivo en espacio. Dado que su patrón de utilización de memoria es básicamente aleatorio, Hoffman comenzará a intercambiar dramáticamente y sufrirá una caída desastrosa en el rendimiento una vez que el tamaño de su conjunto de trabajo exceda la memoria disponible de la máquina. Para aliviar esto, el programa se puede operar en un modo en el que llena una serie de tablas de propagación, escribiendo cada una en disco cuando está llena, y luego las lee secuencialmente durante la siguiente pasada. Aunque menos eficiente que cuando el conjunto de trabajo puede contenerse en la memoria, las tablas de propagación permiten al programa construir bases de datos de tamaño esencialmente ilimitado sin intercambio y con una utilización razonable de la CPU. Este modo se activa en tiempo de ejecución especificando el tamaño de las tablas de propagación (en MB) con el interruptor -P. Los archivos temporales se escribirán en el directorio actual.
Por ejemplo, el comando hoffman -g -t 2 -P 1024 kqqkqq.xml activará una ejecución de generación de Hoffman con dos hilos, utilizando un gigabyte (1024 megabytes) de memoria.
3 Sintaxis XML
El elemento XML raíz en una base de datos Hoffman es siempre <tablebase>. Su único atributo (offset) es añadido por el programa, no debe ser suministrado por el usuario, e indica un desplazamiento de bytes hexadecimal en el archivo donde comienzan los datos binarios de la base de datos.
Dentro de un <tablebase> pueden ocurrir los siguientes elementos en el orden listado (los elementos y atributos obsoletos no están documentados):
3.1 <prune-enable color="white|black" type="concede|discard"/>
Especifica qué tipos de elementos de poda se permitirán en esta base de datos y en sus futuras bases. Ambos atributos son requeridos. concede significa que se pueden conceder victorias al color nombrado; discard significa que los movimientos del color nombrado pueden ser descartados. Se puede especificar como máximo un prune-enable para cada color. Sin embargo, no se requiere ningún elemento prune-enable, pero no se permiten elementos prune sin uno y las futuras bases no pueden tener elementos prune-enable adicionales más allá de los especificados para la base de datos actual.
3.2 <variant name="normal|suicide"/>
El elemento opcional <variant> especifica qué versión de las reglas de ajedrez se aplica a esta base de datos.
Predeterminado: normal
3.3 <index type="naive|naive2|simple|compact|no-en-passant|combinadic|combinadic2|combinadic3|combinadic4|pawngen" symmetry="1|2|4|8"/>
El elemento <index> especifica el algoritmo que se utilizará para calcular los números de índice en la base de datos; es decir, el algoritmo que convertirá las posiciones del tablero en desplazamientos de la base de datos y viceversa. Normalmente no es especificado por el usuario (pero puede serlo).
naive utiliza 26n+1 índices para almacenar posiciones para n piezas. Asigna un solo bit para la bandera de turno de juego, luego asigna 6 bits a cada pieza, que se usa para codificar un número de 0 a 63, indicando la posición de la pieza en el tablero.
naive2 Difiere de naive en su manejo de múltiples piezas idénticas, que almacena como una base y un desplazamiento, ahorrando así un solo bit. Actualmente, solo se manejan pares de piezas idénticas; se producirá un error fatal si hay más de dos piezas idénticas.
simple Como naive, pero solo asigna números a los cuadrados que son legales para una pieza en particular. Más lento de calcular que naive, pero más compacto para las bases de datos con muchas restricciones de movimiento en las piezas.
compact Una combinación de la codificación delta utilizada para piezas idénticas en naive2, la codificación de piezas restringidas utilizada en simple, más una codificación emparejada de los reyes para que nunca puedan ser adyacentes.
no-en-passant Una mejora de compact que utiliza el esquema de codificación emparejado para peones restringidos al mismo archivo. Como nunca pueden pasarse entre sí, podemos codificarlos como si fueran un par idéntico, y luego asignar sus colores en el mismo orden en que fueron especificados originalmente. En passant complica esto significativamente y no puede ser manejado con este esquema.
combinadic Una mejora de naive2 que puede codificar más de dos piezas idénticas y superpuestas utilizando un esquema de codificación combinatoria (ver la página de wikipedia "Sistema de números combinatorios").
combinadic2 Como combinadic, pero las piezas posteriores completamente contenidas en el rango semilegal de las piezas anteriores se codifican utilizando menos posiciones. El orden de las piezas es significativo. No se realiza ningún intento de reducir la codificación de los peones.
combinadic3 Como combinadic2, pero las codificaciones de peones también se reducen, reduciendo su valor de codificación (con en-passant incluido), mientras que se usa su posición en el tablero para reducir otras piezas.
combinadic4 Como combinadic3, pero las bases de datos simétricas de color, aquellas invariantes al intercambiar colores, se optimizan eliminando la bandera de turno de juego, reduciendo el tamaño de la base de datos a la mitad. (por ejemplo, kqkq es simétrico de color, pero kqkr no lo es)
pawngen Como combinadic4, pero los peones se manejan por separado construyendo una tabla de todas las posibles posiciones de peones que pueden resultar de una configuración inicial de peones dada.
El atributo opcional symmetry se puede usar para codificar múltiples posiciones usando una sola entrada, pero su utilidad depende del análisis exacto que se esté realizando. Una base de datos sin peones y sin restricciones de movimiento se puede codificar con simetría de 8 vías, ya que el tablero se puede rotar alrededor de un eje horizontal, vertical o diagonal sin afectar el comportamiento de las piezas. Una base de datos con peones puede utilizar una simetría de 2 vías como máximo, ya que solo un reflejo sobre un eje vertical preserva el comportamiento de las piezas. Una base de datos con restricciones en las posiciones de las piezas (por ejemplo, peones congelados) no puede usar ninguna simetría en absoluto. No todas las simetrías son compatibles con todos los tipos de índice; por ejemplo, la simetría de 8 vías no se puede utilizar con los tipos de índice naive o naive2.
Predeterminado: combinadic4 con simetría seleccionada automáticamente, a menos que haya un elemento pawngen presente en el XML, lo que activa pawngen.
3.4 Formato de base de datos
Los siguientes tres elementos especifican el formato de las entradas de la base de datos. Como máximo se puede especificar uno de ellos.
<dtm bits=integer/> especifica una métrica de distancia al mate. Se utiliza cero para los empates, -1 para las posiciones en las que el lado en movimiento está en jaque mate, y 1 para las posiciones en las que el lado en movimiento puede capturar al rey contrario, por lo que un campo dtm de ocho bits puede registrar distancias al mate de hasta 126. Si no se especifica un tamaño de campo, se selecciona automáticamente.
<dtc bits=integer/> especifica una métrica de distancia a la conversión, que es el número de movimientos necesarios antes de alcanzar una base de datos diferente. Se utiliza cero para los empates, -1 para las posiciones en las que el lado en movimiento está en jaque mate, y 1 para las posiciones en las que el lado en movimiento puede capturar al rey contrario, por lo que un campo dtm de ocho bits puede registrar distancias de hasta 126. Si no se especifica un tamaño de campo, se selecciona automáticamente.
<basic/> especifica una bitbase donde se utilizan dos bits para cada posición, y no se almacena información de distancia, solo una indicación del resultado final (ganar, perder o empatar). Tal formato es más compacto y requiere menos tiempo para generar, pero requiere más esfuerzo de usar, ya que se debe tener cuidado de evitar bucles al seguir líneas ganadoras.
<flag type="white-wins|white-draws"/> especifica una bitbase donde solo se usa un bit para cada posición. white-draws incluye tanto las posiciones ganadoras como las de empate para las blancas, por lo que esencialmente se da la situacion: NOT Black-wins.
Predeterminado: DTM con tamaño de campo seleccionado automáticamente.
3.5 <piece color="white|black" type="king|queen|rook|bishop|knight|pawn"location="string"/>
Los elementos piece se utilizan para especificar las piezas de ajedrez presentes en la base de datos. El color y el tipo son requeridos y deben ser obvios. El orden de los elementos de piece es significativo ya que afecta directamente al algoritmo de indexación, pero no hay ningún efecto visible para el usuario en el orden.
El atributo opcional location restringe las posiciones del tablero disponibles para esta pieza. Debe ser una lista de cuadrados, en notación algebraica, en los que se permite que esté la pieza. Un solo cuadrado resulta en una pieza completamente congelada. Además, los peones pueden usar una sintaxis adicional que consiste en un solo cuadrado inicial seguido de un signo más, lo que indica que el peón puede moverse hacia adelante lo más lejos posible. Esto se puede usar, por ejemplo, para ubicar un peón negro en "a7+" y un peón blanco en "a2+", indicando que ambos pueden moverse hacia adelante, pero no pueden "pasarse" el uno al otro.
3.6 <pawngen white-pawn-locations="string" black-pawn-locations="string"
white-pawns-required="number" black-pawns-required="number"
white-queens-required="number" black-queens-required="number"
white-captures-allowed="number" black-captures-allowed="number"/>
Las configuraciones de peones se pueden especificar utilizando un elemento pawngen en lugar del elemento piece. Se especifica un conjunto de ubicaciones iniciales de peones para cada color utilizando los atributos *-pawn-locations, y se calculan todos los posibles movimientos de peones desde esa configuración inicial. Dado que el número y los tipos de piezas son fijos para cada ejecución del programa, los atributos *-pawns-required deben especificarse para indicar cuántos peones de cada color están permitidos. Opcionalmente, los atributos *-queens-required pueden especificarse para forzar la consideración de posiciones donde cierto número de peones se han convertido en reinas, y los atributos *-captures-allowed incluyen la consideración de posiciones donde cierto número de piezas que no son peones han sido capturadas (las capturas de peones ya se consideran).
El script Perl auxiliar pawngen puede aceptar archivos de control sin atributos *-pawns-required, y genera nuevos archivos de control interconectados con los atributos requeridos añadidos.
3.7 <futurebase filename="string" colors="invert"/>
Se puede especificar una o más futuras bases con este elemento. Se debe especificar un comando filename para localizar una futura base, que debe ser otra base de datos, ya sea en formato Hoffman, Nalimov o Syzygy. La ruta a una base de datos Nalimov se ignora; debe estar en el directorio especificado en la línea de comandos usando la opción -N.
La futura base debe estar relacionada con la base de datos actual de una de las siguientes maneras:
Tiene exactamente la misma configuración de piezas que la base de datos actual, y corresponde al movimiento de una de las piezas restringidas, es decir, la base de datos actual tiene un peón blanco congelado en e4 y la futura base tiene un peón blanco congelado en e5.
Tiene exactamente la misma configuración de piezas que la base de datos actual excepto que falta una sola pieza, es decir, ocurrió una captura.
Tiene exactamente la misma configuración de piezas que la base de datos actual excepto que un solo peón ha sido reemplazado por un caballo, alfil, torre o reina, es decir, un peón promovido.
Tiene exactamente la misma configuración de piezas que la base de datos actual excepto que un solo peón ha sido reemplazado por un caballo, alfil, torre o reina, y se ha eliminado una sola pieza no peón del color opuesto, es decir, un peón capturado y promovido en el mismo movimiento.
El atributo opcional colors="invert" puede especificarse para indicar que los colores de las piezas de la futura base deben invertirse a medida que se procesa. Esto evita la necesidad de calcular, por ejemplo, una base de datos con una reina blanca y una torre negra, así como una base de datos con una reina negra y una torre blanca. La primera puede ser utilizada (con esta opción) como una futura base para calcular una base de datos con dos torres blancas y una reina negra.
Nota: Cualquier elemento prune-enable de la futura base debe ser un subconjunto de los elementos prune-enable de la base de datos actual.
3.8 <prune color="white|black" move="string" type="concede|discard"/>
Los movimientos futuros no manejados especificando futuras bases deben ser podados usando uno o más de estos elementos, o se producirá un error. La accion move se especifica usando sintaxis de expresión regular para hacer coincidir un movimiento en un subconjunto de notación algebraica estándar. Todas las siguientes cadenas son ejemplos de cadenas de movimientos legales en un elemento prune: Pe5, P=Q, RxQ, PxR=Q. Las siguientes expresiones regulares coincidirían con Kd4: Kd?, K?4, K[a-d]4, K*. El atributo type especifica qué se debe hacer con los movimientos coincidentes: tratarlos como victorias para el lado en movimiento en este caso; (concede), o ignorarlos completamente con(discard). Si múltiples elementos prune coinciden con un movimiento particular, es una advertencia avisara si son del mismo type, o un error fatal saltara si sus types difieren.
Se puede especificar un solo elemento prune con move="stalemate" y type="concede". En este caso, el atributo color indica a qué lado se deben conceder los empates como victorias.
Nota: los elementos prune no afectan los movimientos dentro de una base de datos. Especificar un elemento prune que solo coincida con movimientos dentro de una base de datos no hará nada.
Nota: Si se especifica un elemento prune para un futuro movimiento manejado por una futura base, entonces la futura base tiene prioridad. Sin embargo, este caso se maneja rastreando cada futuro movimiento en cada posición, por lo que es posible especificar futuras bases que manejen un subconjunto de los posibles movimientos futuros, y luego usar elementos prune para manejar el resto por defecto.
Nota: los elementos prune solo están permitidos si coinciden con un elemento prune-enable. Si no se especificaron elementos prune-enable, entonces no se permitirán elementos prune.
Nota: Las versiones anteriores de Hoffman permitían un atributo pawngen-condition que ya no es compatible.
3.9 Controles de generación
Estos elementos son todos opcionales, pero siempre que output no sea especificada, se debe especificar un nombre de archivo de salida output en la línea de comandos usando el interruptor -o.
3.9.1 <output filename="string"/>
Como máximo debe utilizarse un único elemento de output para especificar dónde debe escribirse la base de datos terminada.
3.10 <tablebase-statistics> ... </tablebase-statistics>
Este elemento es añadido por el programa y no debe ser especificado en la entrada. Contiene estadísticas relacionadas con la base de datos terminada.
3.11 <generation-statistics> ... </generation-statistics>
Este elemento es añadido por el programa y no debe ser especificado en la entrada. Contiene estadísticas relacionadas con la ejecución del programa que generó la base de datos.
4 Algunos mensajes de error confusos
4.1 Las futuras bases no pueden ser menos simétricas que la base de datos en construcción
Las bases de datos simétricas colapsan múltiples posiciones en una, por lo que las futuras bases deben tener la misma simetría (al menos), o la futura base podría manejar de manera diferente dos posiciones que la base de datos más simétrica trata como una.
4.2 Los peones doblados deben (actualmente) aparecer en orden de tablero en la lista de piezas
Actualmente, los peones doblados que usan ubicaciones "más" (por ejemplo, location="a2+") en el mismo archivo deben tener los elementos de piece listados en el XML en el orden en que los peones aparecen en el tablero, contando en notación algebraica de la fila 1 a la fila 8. Quiero decir, de la fila 2 a la fila 7.
4.3 Restricciones de piezas no permitidas con índices simétricos (todavía)
No se puede especificar un atributo de caracter index symetry sin también especificar atributos piece location, incluso si las restricciones en las ubicaciones de las piezas pudieran ser compatibles con la simetría solicitada.
4.4 Restricciones de piezas superpuestas no idénticas no permitidas con este tipo de índice
Para los tipos de índice naive, naive2 y simple, no se pueden especificar dos piezas idénticas con diferentes restricciones del tipo location a menos que esas restricciones sean completamente distintas. Por ejemplo, no puedes tener una torre blanca libre y otra torre blanca restringida al archivo a. Si lo piensas bien, esta situación permitiría que las torres "cambiaran de lugar": ambas podrían moverse al archivo a y luego cualquiera de las dos podría moverse. Los tipos de índice más simples no pueden manejar esta situación. Sin embargo, podrías tener una torre blanca restringida al archivo a y otra restringida al archivo d (o usar un tipo de índice más sofisticado, como compact).
4.5 La futura base no coincide con los prune-enables!
Recuerde que los elementos prune-enable de la futura base deben ser un subconjunto de los prune-enables de la base de datos actual.
4.6 No hay futura base o poda para ...
Movimientos futuros no manejados ...
Si uno o más movimientos futuros no se manejan especificando una futura base o una declaración de poda, se producirá un error fatal inmediatamente o después de la pasada de inicialización. Para ayudar en el diagnóstico, el mensaje de error incluye el FEN de la posición infractora.
4.7 pawngen no admite elementos de salida en los controles de generación
El script pawngen genera automáticamente todos sus nombres de archivo. Elimine el elemento de salida. Después de la generación, todos los archivos htb resultantes se pueden cargar juntos en el modo de sonda de Hoffman.
