Páginas

miércoles, 13 de junio de 2012

Módulos en la nube

"Optimice sus análisis con módulos en la nube de Chessbase".

Con este sugerente título nos anuncia Chessbase la última versión de uno de sus buques insignia: Deep Fritz 13. La filosofía que subyace detrás de esta idea no es otra que poder utilizar los ordenadores que otros usuarios hayan puesto a disposición de la nube de Chessbase para analizar partidas y posiciones propias.

Aparentemente, parece una buena idea poner a disposición de otros usuarios los recursos informáticos infrautilizados, mediante un modelo de pago concreto. Desde hace muchos años se ha contemplado la posibilidad de análisis informático distribuido y descentralizado aplicado a problemas con alto índice de consumo de recursos como el ajedrez y, sin duda, esta podría ser una de las primeras piedras.




Sin embargo, son muchas las dudas que asaltan este modelo propuesto por Chessbase, principalmente de tipo legal.

¿Es lícito que un usuario alquile Houdini, Rybka o cualquier otro módulo funcionando en su ordenador, cuando solamente fue licenciado a autorizar dicho software, no para dstribuirlo mediante su venta o alquiler?

¿Cuál es la responsabilidad de Chessbase sobre el hecho anterior por el mero hecho de poner a disposición de los usuarios la tecnlogía necesaria?

¿Está garantizada la privacidad de los análisis?

Hipotéticamente hablando, ¿se puede llegar a ganar dinero con este modelo de negocio, cubriendo costes como el consumo eléctrico, manteimiento del hardware, etc.?

¿Se puede acceder mediante este modelo al todopoderoso y deseado Rybka Cluster?

Poco a poco, iremos desgranando las respuestas a estas preguntas...

Queda abierto el debate.


lunes, 11 de junio de 2012

Estado del arte en software de ajedrez, Parte II - Bases de datos

Como su propio nombre indica se trata de una base dedatos de partidas de ajedrez, donde lo principal es el número de partidas que contiene (tamaño de la base de datos) y su calidad. La calidad de la base de datos se puede medir de muchas formas, pero existen una serie de parámetros críticos: origen de las partidas, por un lado, y partidas no duplicadas, por otro. Las bases de datos se van generando tras un permanente proceso de búsqueda en internet en los principales sitios que recopilan partidas humanas y partidas entre módulos informáticos. Adicionalmente a esto, existe también la posibilidad de comprar algunas de las bases de datos que se comercializan en el marcado, como Chessbase, Hugebase, Opening Master, etc.

Lo más importante es la frencuencia y modo de actualización del contenido de la base de datos, así como la disponibilidad de esta información para sus usuarios, es decir, el modo de acceso a la base de datos. Dado que la capactidad de los discos duros modernos ya no es un problema, el tamaño de la base de datos ha dejado también de serlo. El futuro está en las bases de datos en la nube (cloud) y en poder transferir la información a cuantos dispositivos móviles del usuario sea posible, por lo tanto el problema ya no es de capacidad de almacenamiento, sino de capacidad y velocidad de transferencia de la información así como del tamaño del archivo a transferir con la información solicitada. Cuanto más pequeño, mejor. Y ese es el principal problema. Cualquiera de las bases de datos antes mencionadas tienen más de 8 millones de partidas actualmente y su transmisión online es prácticamente imposible, sea cual sea el formato. Por lo tanto, las soluciones de futuro parece que pasan por bases de datos en servidores en la nube, mejorando la tecnología para transferir la información necesaria a los dispositivos que solicitan esta información. De nuevo, aparece el problema de los bits comentados en el post anterior. Si buscas una posición y aparecen 15000 partidas en la base de datos con dicha posició, ¿cómo transfieres todo esto al dispositivo cliente?

Hasta el momento, las bases de datos de ajedrez se han considerado prácticamente programas de ordenador en sí mismos (excepto para las actualizaciones de partidas), con todas sus debilidades; por supuesto, el hardware influye decisivamente en el rendimiento de cualquier proceso de la base de datos realizado por estos programas, por ejemplo, la búsqueda de una partida o posición, ordenar conjuntos de registros basándose en criterios concretos, eliminar partidas duplicadas, etc. Para que un sistema de este tipo pudiera funcionar online con cierta eficacia y rendimiento, se necesitaría un superordenador terriblemente caro como tecnlogía en el servidor. Esta es precisamente una de las mayores debilidades en la situación actual: los sistemas gestores de bases de datos existentes son muchísimo más potentes que las bases de datos de partidas en sí mismas que, de por sí, no pueden funcionar eficientemente en entornos cliente - servidor. Sin embargo, no se están utilizando ninguna de estas tecnlogías para almacenar partidas de una forma eficiente.

domingo, 3 de junio de 2012

Estado del arte en el software de ajedrez - parte I, La partida de ajedrez

Como punto de partida para analizar dónde nos encontramos en la actualidad en lo que a software de ajedrez se refiere, definiremos en primer lugar algunos conceptos básicos que iré desglosando en los próximos posts.

Tenemos:

a) partida de ajedrez
b) base de datos de partidas, por ejemplo: Chessbase, Opening Master, Hugebase
c) programa de base de datos, por ejemplo: Chessbase, ChessAssistant, SCID
d) módulos de ajedrez, o motor; por ejemplo: Houdini, Rybka, Stockfish
e) interfaz de usuario o, lo que generalizadamente se ha entendido como programa de ajedrez. Esto es lo más extendido entre la mayoría de los aficionados, pues son entornos gráficos donde se permite jugar contra el ordenador, analizar posiciones y partidas, examinar bases de datos y, en muchas ocasiones permiten acceso a las plataformas de juego online; por ejemplo: Fritz, Aquarium, Chess King, etc.

La partida de ajedrez
Consiste en un conjunto de información que contiene principalmente dos tipos de datos: los datos relativos a los movimientos en sí mismos y los datos relativos a la identificación de la partida: quién la ha jugado, cuándo, el resultado, el lugar y otros parámetros útiles para clasificarla y localizarla posteriormente. Las partidas comenzaron a divulgarse en formato PGN, posteriormente aparecieron otros como .cbf, .cdp, .cbh. Estos últimos formatos son mucho más eficientes que el estándar PGN, pero son formatos propietarios, es decir el estándar no es abierto y para trabajar sobre ellos se necesitará normalmente acceder desde programas de la misma marca propietaria. No es posible, en principio, crear un desarrollo propio con acceso a tales formatos.
Todos estos formatos fueron inventados hace cierto tiempo, y la mayoría de sus intrucciones no fueron optimizadas al máximo para el manejo de grandes volúmenes de información; concretamente, no llegaron al nivel de bits sino al nivel byte, desperdiciando por lo tanto espacio de almacenamiento y velocidad del tratamiento de la información.
Pongamos un ejemplo: el resultado de una partida podría almacenarse como victoria, derrota, tablas, o indefinido. Por lo tanto, estos cuatro estados podrían representarse como la combinación de dos de los ocho bits de un byte:
- victoria: 1 0 - 000000
- derrota: 0 1 - 000000
- tablas: 1 1 - 000000
- indefinido: 0 0 - 000000
Esto quiere decir que los 6 bits restantes están libres para almacenar información. Llegamos a la conclusión que si cogemos el formato más eficiente en la actualidad (.cdp), aún podríamos ahorrar hasta un 50% en términos de eficacia en el almacenamiento y rendimiento en el tratamiento de esta información.