Motor de ajedrez DanaȘah

Compatible Winboard y UCI

DanaSah y DanaSah LimitStrength

------------------------------------------------------

DanaSah es un motor de ajedrez compatible con los protocolos xboard y uci. Su nombre viene de las palabras Daniela y Sah que significa ajedrez en rumano. Puede jugar sobre Windows en interfaces (GUI) como Fritz, Shredder, Arena, Winboard o ChessGUI. En Linux sobre interfaces como Arena o Xboard. En Android sobre interfaces como Droidfish, Chess for Android, Acid Ape Chess o Hawnk Chess. Incluso hay una versión antigua para jugar en un Pocket PC sobre Mobile Thinkerboard. Su Elo en la lista CCRL es aproximadamente 2600 puntos.

DanaSah LimitStrength es una versión que juega con una fuerza reducida y que está orientada principalmente para jugar contra humanos o para enfrentarlos a máquinas dedicadas u otros motores más débiles.

Configurando DanaSah y DanaSah LimitStrength con protocolo xboard

----------------------------------------------------------------------------------------------------------------

Para configurar el motor en la GUI, debemos seleccionar el archivo necesario según el sistema operativo que vayamos a utilizar (por ejemplo "danasah___.exe" en Windows), el mismo archivo se utiliza tanto para el protocolo xboard como para el protocolo uci, únicamente tendremos que indicar a la GUI el protocolo que vamos a usar en caso que nos pida.

En Windows podemos utilizar la versión xboard con Arena, Winboard, ChessGUI o incluso Chessmaster, sobre Linux podríamos usar Arena y Xboard, en Android podemos usar el protocolo xboard con Chess for Android pero en este caso es recomendable utilizar la versión uci para poder instalar el motor en la carpeta preferida y no en una dada y así no depender del archivo de configuración.

El motor iniciará con una serie de parámetros por defecto, dichos parámetros se podrán cambiar con la ayuda del bloc de notas o un editor abriendo el archivo de configuración "danacfg.txt" que se encuentra en la misma carpeta que el ejecutable. Posteriormente en este documento se explicarán dichos parámetros. Importante: si dichos parámetros se cambian es necesario para aplicar los cambios guardar el archivo e iniciar o reiniciar el motor, ya que de lo contrario el motor no se entera.

Configurando DanaSah y DanaSah LimitStrength con protocolo uci

---------------------------------------------------------------------------------------------------------

La configuración del motor en modo uci se realiza de forma parecida a xboard, tendremos que indicar a la GUI que el protocolo utilizado es el uci en caso de que nos lo pida.

En Windows podemos utilizar la versión uci por ejemplo sobre Fritz, Shredder, chessGUI o Arena, la versión Linux sobre Arena y en Android sobre cualquier interfaz que soporte motores.

Con el protocolo uci no existe un archivo de configuración, los parámetros de configuración normalmente se modifican dentro de la propia interfaz. La actualización de los valores de los parámetros suele ser instantánea salvo en el caso de Arena. De todos modos recomiendo reiniciar el motor o empezar una nueva partida para estar seguros que los cambios son efectuados correctamente.

Algunas gui viejas no envían en el protocolo uci el comando "ucinewgame", en este caso para que el motor no tenga problemas en comenzar un nuevo juego es necesario seleccionar en la configuración el parámetro "GUI Has Ucinewgame Command". Hasta ahora la única GUI en la que he visto necesario utilizarlo es en la vieja GUI Fritz 9.

Parámetros del motor

-----------------------------------

Ya sea cambiando los parámetros del motor desde el archivo "danacfg.txt" en una GUI con protocolo xboard o cambiando los parámetros del motor desde la ventana de configuración en una GUI uci, tenemos:

* Regulación Elo del motor (solo en DanaSah LimitStrenght).

- limitstrength: puede tomar 2 valores; true o false para activar o no la regulación. En la versión uci se activa dicho parámetro marcando la casilla de selección, puede ocurrir que la gui no muestre dicha opción en la configuración y la maneje desde un menú especial como ocurre por ejemplo en Arena.

- elo: ajustar su valor entre 500 y 2500.

- elo_type (opponent): engine, computer o human. Cuando el motor juega en modo "engine" contra otro motor ajustará su Elo según la lista de la siguiente página: https://sites.google.com/site/motoresdeajedrez/motores-hispanos/elo . Elo parecido a la lista CCRL y ambas listas utilizan BayesElo para el cálculo. Cuando el motor juega en modo "computer" contra una máquina de ajedrez dedicada (chess computer) lo hará con el Elo Activo de la página:

http://www.schach-computer.info/wiki/index.php/Wiki-Elo-Liste . Si el motor juega en el modo "human" intentará ajustar su Elo de acuerdo al Elo FIDE.

- style: se puede ajustar su valor entre 1 muy pasivo a 5 muy agresivo siendo 3 el valor normal (no implementado de momento)

- diff_engine: el Elo de un motor puede diferir de una lista a otra dependiendo de la puntuación medía dada a la lista o la puntuación dada a un motor concreto para establecer el resto de valores. Si alguien considera estos valores de los motores más altos o bajos de lo debido puede probar a modificar este parámetro, un incremento de este parámetro en una unidad reduce la fuerza (no el Elo) en una unidad. Más problemático puede ser el cambio si la otra lista está utilizando Elo_stat para el cálculo.

- diff_computer_engine: utilizamos este parámetro para establecer una relación entre el Elo de la lista hispana de motores y el Elo de lista Activa de máquinas dedicadas. Por ejemplo la máquina dedicada Mephisto Roma32 en la lista Activa tiene un Elo de 2076 puntos, sin embargo en la lista de motores hispanos solo alcanzaría 1610, esto supone una diferencia de 466 puntos. Cuando el motor juega en el modo "computer" lo hará con menos fuerza para el mismo Elo que si jugase como "engine". La lista Activa se ha desarrollado con Elo_stat, esto hace que el valor de elo calculado sea más pequeño en el caso de máquinas dedicadas con menor Elo, hasta el punto que sobre el nivel de 700-1000 puntos de Elo las 2 listas tienden a igularse. DanaSah LimitStrenght hace automáticamente ese ajuste internamente.

- diff_human_computer: por diferentes encuentros entre jugadores humanos con Elo FIDE y máquinas dedicadas se ha encontrado que la lucha está igualada cuando el humano tiene unos 70 puntos más de Elo que el indicado en la lista Activa de máquinas dedicadas.

Los valores iniciales de estos parámetros son:

limitstrength            true

elo                      2000

elo_type                 human

style                    3

diff_engine              0

diff_computer_engine     466

diff_human_computer      70

Ya hemos comentado que la regulación del Elo es complicada debido a que diferentes listas dan diferentes valores, si sientes que DanaSah LimitStrength juega más flojo de lo esperado puedes ajustar el paramétro diff_computer_engine, por cada unidad que disminuimos aumenta 1 unidad su fuerza, valores entre 350 y 475 podrían ser válidos.

* Niveles (solo en DanaSah LimitStrength).

- easylevel: este parámetro puede tomar 10 valores diferentes.

0  No hay nivel fácil

1  Movimiento aleatorio

2  Recién llegado                Elo aleatorio entre 500 - 999

3  Principiante                  Elo aleatorio entre 1000 - 1199

4  Jugador débil de club         Elo aleatorio entre 1200 - 1399

5  Jugador medio de club         Elo aleatorio entre 1400 - 1699

6  Jugador fuerte de club        Elo aleatorio entre 1700 - 1999

7  Experto                       Elo aleatorio entre 2000 - 2199

8  Candidato a Maestro (CM)      Elo aleatorio entre 2200 - 2299

9  Maestro FIDE (FM)             Elo aleatorio entre 2300 - 2399

10 Maestro Internacional (IM)    Elo aleatorio entre 2400 - 2499

El valor inicial de este parámetro es:

easylevel 0

Si easylevel toma un valor diferente de 0, este parámetro tendrá en cuenta los valores de los parametros "type_elo" (opponent) y los distintos diff para ajustar el Elo definitivo. No es necesario activar "limitstrength" y no se tendrá en cuenta el valor del parámetro "elo".

* Libros de apertura.

DanaSah y DanaSah LimitStrength puede utilizar cualquier libro de apertura en el formato de PolyGlot. En la distribución va incluido el libro del motor Rebel/Prodeo en dicho formato. Es aconsejable que el libro esté en la misma carpeta que el motor, esto facilita la configuración ya que bastará solo con indicar el nombre y no dar la ruta completa. Si queremos utilizar este libro es necesario que la GUI no tenga activado el suyo propio.

En DanaSah LimitStrength, la profundidad del libro viene determinada por el nivel de Elo con el que juguemos, el número de plys (medio movimientos) viene determinado por la fórmula elo/100 menos el valor de los diferentes "diff". Por ejemplo jugando con 2000 puntos de Elo en modo humano jugaría unos 7 ó 8 movimientos de libro.

- ownbook: puede tomar 2 valores; true o false para activar o no el libro propio del motor. En el protocolo uci lo activaríamos con la casilla de selección pero podría ocurrir que no viesemos dicha opción en la configuración, por ejemplo en Arena la opción está en el apartado uci.

- book: indica la ruta o path donde está situado el libro, si está en la misma carpeta del motor basta con dar el nombre del archivo, salvo en Android que es necesario dar la ruta completa (ej. /storage/sdcard1/book/book.bin)

El valor inicial de estos parámetros son:

ownbook true

book ../book/book.bin

* Tablas Hash.

- hash: Valores de 8-16 Mb (bullet), 32-64-128 Mb (blitz) y 256-512-1024 Mb (estándar) han sido probado sin problema. Generalmente cuanta más memoria RAM dediquemos a las tablas hash, más tiempo tardarán estas en llenarse y el motor ganará algo de fuerza, pero es posible que no más de 10 puntos de Elo.

El valor inicial de este parámetro es:

hash 256

* Bitbases para finales.

DanaSah y DanaSahLimitStrenght pueden jugar de una manera más inteligente los finales de partida con la ayuda de las bitbases de Scorpio.

Las bitbases dan información sobre una posición cuando en el tablero quedan 6 o menos piezas (contando los 2 reyes), indican si la posición está ganada, es tablas o perdida, pero no indican la distancia que hay al mate por lo que puede ocurrir que en incluso con dicha información el motor no sea capaz de dar un mate debido a la regla de los 50 movimientos, por ejemplo podría ocurrir que para hacer mate con rey-alfil-caballo contra rey necesite más de 50 movimientos, por lo cual dicha tabla de finales no es perfecta.

Para tener los finales de 6 piezas scorpio necesitamos casi 50 Gbyte de disco duro, es posible utilizar 5 piezas con un tamaño de unos 200 Mbytes y las de 3 y 4 piezas ocupan menos de 5 Mbytes. Es necesario que en la carpeta de las bitbases estén los archivos "dll" y "so" correspondientes y a poder ser en última versión (Egbbprobe 4.1).

- egbb_path: es la ruta donde están almacenadas las bitbases.

- egbb_cache_size: indica al motor el número de piezas que están instaladas de las bitbases o el número de piezas que queremos jugar.

- egbb_cache_size: es el tamaño de memoria RAM utilizada para accelerar el proceso de búsqueda cuando se accede a los archivos de las bitbases, si vamos a comprobar con 4 piezas un tamaño de 4 Mb es suficiente, si vamos a comprobar 5 piezas sería recomendable aumentar dicho tamaño a 16 Mb y con 6 piezas a 64 Mb.

- egbb_load_type: carga en memoria los archivos necesarios para acceder a las bitbases, esto es lo más rápido, si el valor es 0 no carga ningún archivo, si el valor es 1 carga los archivos hasta 4 piezas y ocupa unos 10 Mb de memoria, si el valor es 3 carga los archivos de 5 piezas y necesita alrededor de unos 250 Mb, hoy en día los ordenadores no suelen tener problemas con esta cantidad de memoria pero puede ocurrir que la iniciación del motor lleve varias decenas de segundos y que esto ocasione problemas al jugar match contra otros motores.

- use_egbb: un valor de 1 activa las bitbases y un valor de 0 las desactiva. En el protocolo uci no tenemos dicho parámetro si no que debemos escoger en Endgames Tablebases la opción Scorpio.

Los valores predefinidos para estos parámetros son:

egbb_path        ../egbb/

egbb_men         4

egbb_cache_size  4

egbb_load_type   1

use_egbb         1

* Tablebases para finales.

DanaSah y DanaSahLimitStrenght pueden jugar de una manera más inteligente los finales de partida con la ayuda de las tablebases de Gaviota.

A diferencia de las bitbases, las tablebases no solo indican si la posición está perdida, ganada o es tablas, además indican la distancia al mate si lo hay. La consecuencia de esto es que las tablebases ocupan mucho más espacio en disco duro, de momento solo están disponibles tablebases Gaviota para 5 piezas (incluidos los 2 reyes) y el espacio ocupado es de más de 5 Gbytes. Sería posible utilizar solo 3 y 4 piezas con un espacio de unos 30 Mbytes.

- egtb_path: es la ruta donde están almacenadas las tablebases.

- egtb_cache_size: es el tamaño de memoria RAM utilizada para accelerar el proceso de búsqueda cuando se accede a los archivos de las tabletbases, para 5 piezas es necesario utilizar unos 16 Mb y si podemos más.

- use_egtb: un valor de 1 activa las tablebases y un valor de 0 las desactiva. En el protocolo uci no tenemos dicho parámetro si no que debemos escoger en Endgames Tablebases la opción Gaviota.

Los valores predefinidos para estos parámetros son:

egtb_path          ../gtb/gtb4/

egtb_cache_size    16

use_egtb           1

Al dar más información las tablebases es mejor utilizar éstas frente a las bitbases, también tenemos la opción combinada de utilizar a la vez las 6 piezas de scorpio y cuando hay menos las tablebases.

* Noise.

- noise: A veces imprimir la variante principal en cada iteración de la profundidad hace que el motor sea algo más lento y pierda algo de fuerza por eso algunos motores no la imprimen en bajas profundidades cuando juegan en el modo bullet (juegos de menos de 1 minuto). Podemos indicar un número de nodos hasta el cual no se imprime. Esta opción solo está disponible para el protocolo xboard. En el protocolo uci se limita la información impresa hasta que no pasa al menos 1 segundo.

En DanaSah LimitStrenght no tiene mucho sentido este parámetro ya que el motor pasa normalmente la mayoría de su tiempo dormido, por lo que no le afecta si mostramos más o menos información.

noise 0

* Ajedrez960 o Fischer Random Chess.

DanaSah y DanaSah LimitStrength puede jugar la variante de ajedrez Fischer Random Chess (FRC) o Ajedrez960, para ello necesitamos una gui que soporte dicha variante.

El motor conoce el formato de posiciones xFEN(KQkq) y ShredderFEN(HAha) por lo que podrá jugar en cualquier gui que tenga soporte para la variante y tanto con el protocolo xboard como uci. En Windows podemos utilizar Fritz, Shredder, Arena, Winboard, ChessGUI, etc. En Linux no ha sido probado pero debería funcionar tanto en Arena como Xboard. En Android se puede utilizar Acid Ape Chess.

En el protocolo uci es necesario seleccionar la casilla correspondiente para activar la variante, seleccionar UCI_chess960. En el protocolo xboard no es necesario seleccionar nada.

Características del motor

----------------------------------------

• Representación del tablero: cadena de 64 elementos, basado en Firstchess (Pham Hong Nguyen).
• Búsqueda con profundidad iterativa y con ventanas reducidas para el alpha-beta.
• Funciones de búsqueda PVS y horizonte (quiesce). Gracias a Bruce Moreland por su página web.
• Ordenación de movimientos (hash, sigue_pv, capturas, promociones, movimientos killer, heuristic historia).
• Tablas de transposición. Gracias a Miguel Izquierdo (Popochin).
• Movimiento nulo agresivo con valor de R entre 2 y 5.
• Profundidad iterativa interna (IID) para ordenación de movimientos.
• Extensiones de búsqueda (jaque, peón en séptima, recaptura, final de peones).
• Corte del árbol por futility prunning y razoring.
• Reducción del árbol cuando se han probado ya los mejores movimientos (LMR).
• Modo editar (setboard), Mover ahora, Ponder (pensamiento en tiempo del contrario) y Analizar.
• Evaluación con salida rápida, tablas de piezas para valorar la situación de las piezas, movilidad, valoración de la estructura de peones, seguridad y ataque al rey ...

Créditos

-------------

(c) Pedro Castro. País Vasco. España (Octubre 2019). Licencia del software GNU GPL3.

Gracias a Jeroen Nomen y Ed Shroeder (motor Rebel/Prodeo) por la utilización de su libro de aperturas en formato PolyGlot.

Gracias a Daniel Shawul (motor Scorpio) por la utilización de sus bitbases y código de acceso.

Gracias a Miguel Ballicora (motor Gaviota) por la utilización de sus tablas de finales y código de acceso.

Y en general gracias a todos los autores de motores que mostraron sus códigos fuentes o compartieron sus ideas, gracias también a los testadores y organizadores de torneos.