Entrevista para SiliconChess: Oscar Toledo

Luego de algunas idas y venidas con algunos moderadores del foro, redondeamos algunas preguntas para Oscar Toledo.

Para quienes no lo conozcan, Oscar Toledo es el programador del programa de ajedrez cuyo codigo fuente es el mas pequeño del mundo. No solo eso, sino que lo ha hecho en varios lenguajes y en diferentes sabores (con y sin captura al paso, con o sin interfaz grafica, etc).

Para quienes deseen leer mas acerca del surtido de programas, visiten el sitio de Oscar Toledo:

http://nanochess.110mb.com/
(Al momento de publicar la nota el sitio de Oscar Toledo parece caido, por lo que ofrecemos la alternativa de una imagen anterior).
http://web.archive.org/web/20110707054646/http://nanochess.110mb.com/

Aquí la entrevista:

SiliconChess>El tiempo de espera no nos preocupa. Los ajedrecistas sabemos ser pacientes ante una buena jugada.

Aprecio esto debido a mis obligaciones.

SiliconChess>Desde ya, muchas gracias.

SiliconChess>Primero que nada te agradecemos Oscar Toledo desde el foro por el tiempo concedido, vamos a la primer pregunta:

Al contrario, gracias a ustedes por su interés.

SiliconChess> ¿Oscar, como fue el proceso necesario e inspiración para realizar el programa más pequeño y funcional? Se creó previamente un motor de tamaño más grande a semejanza de otros motores (tomado ideas de los mismos) para luego ir reduciendo gradualmente el tamaño hasta llegar a lo que tiene, o ya desde el inicio el código fue pequeño y lejano a las estructuras de los demás motores de ajedrez?

La historia de mi programa de ajedrez es una combinación de varios factores
y casualidad.

Aprendí a jugar ajedrez a los 8 años, así que digamos que el ajedrez siempre
fue uno de mis hobbies.

Mi interés por escribir un programa de ajedrez comenzó también por esa edad.
Eso era a finales de la década de 1980 y llegué a escribir varios juegos de
ajedrez muy sencillos para dos jugadores y otros con respuesta aleatoria de
la computadora..

Descubrí por casualidad el International Obfuscated C Code Contest (IOCCC) a
finales de la década de 1990 y en ese momento lo consideré una curiosidad.

Escribí además un programa de ajedrez en Javascript en el año 2003.

Al fin todo esto se combinó:

1. El IOCCC empezó un nuevo concurso en 2005.
2. Como programador de lenguaje C pensé en ganar el concurso.
3. Decidí participar con un ajedrez completo.
4. Me exigí que fuera relativamente "poderoso"
5. Me basé en mi ajedrez en Javascript.
6. El reto fue que cupiera en los 2048 bytes impuestos por el concurso.

Por el punto 5 puedo afirmar que empecé con un motor grande y al mismo tiempo
sin nada que ver con otros motores.

Así que a mediados de febrero del 2005 comencé a reducir y convertir mi ajedrez
Javascript en 2 kilobytes de lenguaje C y parecía que no iba a ser posible.

Pero lo logré con un poco de esfuerzo y una vez "encajado" me puse a mejorarlo
para que pudiera realizar todas las jugadas legales (incluyendo al paso y
coronaciones menores)

El programa en cuestión me hizo ganar la categoría Best Game del 18º IOCCC en
2005 y juega razonablemente bien, explorando a 5 medios movimientos.

Reduje aún más ese programa y le añadí una interface gráfica X/Window, y así
gané la categoría Most Portable Chess Set del 19º IOCCC.

Después me di cuenta de que estaba a nada de tener el programa de ajedrez más
pequeño del mundo. Así que del núcleo de mi programa derivé Toledo Nanochess;
la versión que aparece publicada en mi sitio es la revisión o modificación 52.

La interfaz WinBoard fue la última cosa que hice con el fin de participar en
ChessWar y OpenWar. Y el programa ha permanecido estable desde entonces.

SiliconChess> ¿Cual fue el tiempo empleado para llegar a tener un motor funcional y el tiempo para conseguir el record de más pequeño?

El primer motor funcional (con el que gané el IOCCC por primera vez) me tomó
seis semanas, de febrero a marzo de 2005.

Llegar al motor más pequeño del mundo no fue nada fácil y en ese entonces me
pareció rápido. Por esta entrevista he revisitado mis historiales de desarrollo
y ya verifiqué que fue a través de tres años (2006, 2007 y 2009). Lo cual sí
es un muy largo tiempo.

SiliconChess> ¿Que parte del motor le ha resultado más complicada? ¿El generador de movimientos, búsqueda, evaluación? Quizás estaría bien que comentara algo sobre cada una de esas partes (si es que el programa las posee como tal).

Lo más complicado fue hacer que jugara con una rapidez razonable y de forma
"inteligente" para su tamaño ya que quería alcanzar el título del ajedrez más
pequeño del mundo. El tamaño fue una enorme limitante para otras
características.

Las partes de generador de movimientos, búsqueda y evaluación están finamente
entretejidas para ahorrar bytes junto con algunos trucos de lenguaje C.

La búsqueda alimenta al generador de movimientos y el generador de movimientos
calcula datos para la evaluación, así que es muy difícil verlos como partes
separadas.

No siempre jugó de forma razonable. Pero como al mismo tiempo he estado
desarrollando un ajedrez más poderoso para mi uso privado, fui descubriendo
técnicas que podía aplicar de forma efectiva en el programa pequeño.

Esas técnicas las simplifiqué de una forma que las dejó irreconocibles: como
una seudo-ordenación de movimientos para que la búsqueda no tomara horas. En
este caso unas mejoras que hice a finales de 2009 consiguieron que adelantara
casi 200 puntos ELO en el torneo Chesswar ya que le quedó más tiempo para
análisis (de hecho en el torneo XVII de Chesswar quedó en el lugar 127 de 200,
¡o sea que pese a su tamaño supera otros 73 programas!)

Otra cosa difícil fue una evaluación razonable para que consiguiera dominar el
centro y atacar. Por la limitación de tamaño tuve que dejar de lado muchos
parametros interesantes que lo hacen débil en algunos finales.

Otro detalle es que trata de alcanzar una búsqueda de tranquilidad, con lo que
consigue "escapar" de la mayoría de las "trampas" simples.

SiliconChess> ¿Que opina sobre el paradigma del tamaño vs. fuerza de juego vs. optimización? Existen otros motores de código pequeño con un nivel de juego elevado. Es el caso de PikoSzachy* donde el ejecutable final es de un tamaño de 9.5 kb y una fuerza de juego cercana a 2500 elo. También hay otros programas como el caso de Rybka, cuyos ejecutables son mucho mayores y alcanzan niveles mucho mas altos, o el caso de Houdini, el motor actual mas fuerte (2012) que se ubica en el centro de la escala. Cree que estos programas podrían beneficiarse de una programación similar a la empleada en su motor?

El tamaño del código significa poco con los procesadores actuales, pues casi
todo el núcleo puede caber en el cache. Más importante es la optimización, lo
explico:

1. Programador A puede escribir el algoritmo más pequeño pero lento.
2. Programador B puede escribir el algoritmo más rápido pero inaceptable.
3. Programador C puede escribir el algoritmo más rápido posible y razonable.

[inicia chiste] El programador B puede escribir un programa de ajedrez que
juegue de forma instantánea, sólo habría que introducir el tablero actual
como un indice en un arreglo que contiene las coordenadas de la mejor jugada
[final del chiste] . Notese que sin información adecuada muchas personas
pueden considerar que este es ¡un algoritmo practicable!

Volviendo a la realidad, en ajedrez sólo el caso 3 es útil, pero para llegar
a ese punto se necesita una experiencia bárbara. Es necesario conocer muchos
algoritmos y hallar nuevas formas de combinarlos y optimizarlos.

Eso siempre me conduce a preguntas tipo "significado del universo", ¿por qué
los programadores se atoran en cierto nivel de ELO?, ¿no debería ser un
incremento continuo de fuerza?, ¿cómo es que ciertos programas aparecen de
repente con tanto "poder" y luego mejoran muy poco a lo largo de los años?.
Sólo estas preguntas pueden llevarnos a divagaciones bastante largas. De hecho
estoy atorado en 2200 ELO con mi programa privado, ¡se que tiene que haber un
bug!, pero no he tenido el tiempo para buscarlo sigue siendo un hobby para
mí.

Respecto a las técnicas usadas en Toledo Nanochess, es posible que una u otra
pudiesen ser empleadas en un motor más grande.

Pero debido a la consideración de tamaño, en Toledo Nanochess se utilizan
muchos algoritmos demasiado lentos y se llegó a una simplificación excesiva.
Digamos que mi ajedrez tiene una evaluación tan optimizada que es desquiciada,
¿cuánto vale capturar al paso?, un punto, ¿proteger un peón?, un punto, ¿salir
adelante?, un punto, todo esto porque no había espacio para asignar diferentes
valores

Es siempre el huevo y la gallina, ¿le quito o le pongo más parametros a la
función de evaluación?, algunas cosas que parecían tan "lógicas" le restaban
fuerza a mi ajedrez o lo hacían lento, y algunas cosas que sonaban "locas" lo
mejoraron e incluso a veces lo hacen parecer "humano".

Un núcleo basado en bitboards le vendría de perlas para ser más rápido, sumado
a una función de evaluación de peones, pero ya sería sólo otro programa más de
ajedrez que probablemente rondaría los 2100 ELO y me temo que ya hay demasiados
de ese tipo en Internet.

Creo que si compactara el ejecutable de Toledo Nanochess sería interesante el
resultado, pero aún no lo he intentado.

SiliconChess> ¿Cree que existe la posibilidad de realizar un programa de ajedrez con la fuerza requerida para ganar al mejor jugador humano de ajedrez con características similares a las de Toledo Nanochess? Si ese es el caso, que tamaño especula que sería necesario para generar un programa de estas características?

Creo que Toledo Nanochess no es el núcleo que derrotaría al mejor jugador
humano de ajedrez (idem. el campeón). Sería más bien una combinación de los
algoritmos más recientes adaptados a multiprocesadores, optimizados para
"localizar" el acceso a memoria, sumado a una evaluación ajustada con finura,
más un buen libro de aperturas y un bitbase de finales.

Entonces ese programa soñado sería bastante pequeño, apróximadamente entre
medio megabyte y dos megabytes, sin contar datos/tablas. Lo cual es poco
teniendo en cuenta los tamaños de RAM que se manejan en las computadoras
actuales.

Aún así usaría una gran cantidad de memoria para contener las tablas de
transposiciones y una pequeña cantidad para otros menesteres.

Los avances en procesadores sumados a los poderosos programas que ya existen
me hacen suponer que un puñado, si no es que dos o tres jugadores, pueden
derrotar a una computadora. Es una cosa fantástica, la máquina paralela por
excelencia (el cerebro humano) contra la máquina desnaturalizada que realiza
cálculos con una eficiencia casi diabólica.

En un principio escribir programas de ajedrez era un desafío personal para
los programadores (el punto: derrotar aunque sea a la secretaria) como el
MANIAC de Los Alamos en la década de 1950, después el punto era superar a un
gran maestro (la década de 1970), más adelante ganar al campeón del mundo
(Kasparov en la década de 1990).

Estamos casi en el punto muerto donde no tendrá interés que una persona juegue
contra esos programas "aplastantes". La batalla será más que nada entre
programas de ajedrez, como ya se ve con los torneos abiertos de computadoras.

Siempre existirá el campeonato humano y en cierta forma hace falta un
campeonato "oficial" de programas, y esto me recuerda que Olivier Deville ya
no tiene tiempo para organizar el ChessWar, lo cual ciertamente es una lástima.

En mi opinión puramente personal aún faltan por descubrir técnicas que harían
que un programa de ajedrez actual jugara dos o tres veces mejor y fuera
esencialmente invencible, como ya lo son los programas de damas (aunque
recordemos que las damas son un juego más sencillo)

SiliconChess> *PikoSzachy: Motor de ajedrez cuyo codigo fuente no es publico. A diferencia de el programa Nanochess de Oscar, éste último utiliza tecnicas de comprensión sobre el ejecutable, por lo que el tamaño del codigo del mismo puede ser mucho mayor al tamaño del .exe final, siendo de esta manera un programa mucho mas complejo (http://www.kalisz.mm.pl/~pic/nanochess/).

Si, lo conozco. Cuando bauticé mi programa como Toledo Nanochess ignoraba por
completo su existencia, hasta que en Talkchess alguien me mencionó nanoSzachy
(su traducción al inglés es nanochess). Ya era demasiado tarde para cambiar
el nombre , pero como afortunadamente incluí mi apellido, fue suficiente
para diferenciar mi ajedrez

Esto me recuerda que también hice un Toledo Picochess en menos de 1K de C, con
la limitante de no incluir enroque, captura al paso y coronaciones
menores. E increíblemente no pude aplicar casi ninguna de las técnicas de mi
Nanochess en Picochess, porque cada una incrementaba el tamaño

Y después volví a Javascript, de hecho ya tenía el ajedrez más pequeño en
Java y Javascript (p4wn.sourceforge.net me cita al respecto). Casi por
curiosidad y para ver si era posible escribí una versión limitada en 1K de
Javascript que ganó segundo lugar en el concurso JS1K de 2010.

Parece que el tamaño mínimo de un juego de ajedrez con todas las reglas e
inteligencia artificial ronda 1024 a 1536 bytes para los lenguajes C y
Javascript usando la máxima compresión posible de los tokens del lenguaje.

En resumen, este hobby me ha llevado a ser un especialista en programas
pequeños y me ha dado algo de fama. Pero no lo hice ni por fama, ni por dinero.
Fue simplemente porque se podía hacer y nadie lo había hecho

Atentamente
Óscar Toledo G.

SiliconChess> Muchas gracias nuevamente por tu tiempo. Un saludo cordial de parte de todo el Foro SiliconChess.

Bueno, ciertamente luego de leer la entrevista aprendí mucho sobre lo que es posible y lo que no. Aclaro que las preguntas no fueron redactadas por mi, sino que participaron usuarios y administradores del foro y yo solo las corregí minimamente para adaptarla al nivel de todos los usuarios.
Un dato que me llamo la atención es el tamaño del código necesario para generar un programa lo suficientemente fuerte para derrotar a por ejemplo, Anand, Carlsen o Aronian de manera convincente. Por ejemplo, el código fuente de Fruit 2.1 es de medio mega y su nivel es ciertamente cercano a los 2800 elo. Creo en este punto que quizás pueda crearse un fuerte motor de ajedrez que supere a los top 5 del mundo en menos de medio mega, pero no tengo idea en cuanto menos. (Siempre hablamos del código fuente sin comprimir, ni siquiera de los ejecutables).

Parece interesante que un programita tan pequeño dé jaque a los maestros mas "grandes" del planeta...

Yo creo que es muy posible crear un motor en digamos 256 kb de código puro y duro lo suficientemente fuerte para vencer a el top 10 humano, siempre y cuando se aproveche la potencia de calculo de las maquinas actuales. Hoy por hoy hay un cierto desaprovechamiento de la fuerza de calculo en los grandes motores. Aun no han conseguido aprovechar lo suficiente la velocidad de calculo en las partidas semi-rápidas y lentas.
Lo que me encanta de el motor Toledo Nanochess es su fuerza a pesar de su tamaño. Nunca me lo puse a leer con detenimiento para intentar comprender su funcionamiento, pero supongo que podría realizar un desglose inverso, aumentando su tamaño para simplificar su lectura y de ahi comenzar a agregar algunos algoritmos de primera linea que le permitan aumentar mucho su nivel.
En principio solo con una tabla con valores posicionales se podría aumentar enormemente su fuerza de juego. Hay posiciones y estructuras sencillas que se pueden poner todas en 4 tablas de 4x4 (se espeja la información para obtener un tablero de 8x8).
Quizás en 32 Kb se podría realizar un motor con nivel de MF. Para llegar a batir al top 10, con 256 kb estoy convencido que es suficiente. Fruit se puede simplificar en pocas semanas para llegar a ese tamaño, y luego con algunos pequeños trucos tomados de los otros motores libres se puede llegar a subir su nivel lo suficiente como para batir a los mejores en un equipo lo suficientemente fuerte. Lo importante para lograrlo sería utilizar bien el multiproceso y los 64 bits de las modernas pc.

Exelente e interesnte entrevista, me quedo con la intriga y la pregunta si toledo cree que seria podria crear un motor capaz de codearse con los grandes, si depronto sus tecnicas de optimizacion pudiesen hacer que un motor jugase mejor que los motores que vemos hasta ahora, felicitaciones a los que formularon las preguntas, de verdad que contenido como este hace muy interesante el foro

Muy buena entrevista. Hace rato que no encontraba algo interesante para leer en un foro, hasta me prepare un té para saborearla mejor.

Me encantaría ser capaz de comprender algo de programación para aportar un poco mas al debate.
Me intriga conocer el motor de Oscar que cita como "privado". Acá hemos ayudado a unos cuantos programadores a mejorar sus motores solo con ideas y testeo.

Una pregunta que me hubiese gustado hacerle a Oscar, es si cree que existe la posibilidad de maximizar la cantidad de nodos por segundo que puede analizar su programa de ajedrez como para equipararla o incluso superar a los programas actuales. Cuanto codigo más se necesitaría para conseguir que un programa de ajedrez analice y pueda llegar a 12 o 14 plys en pocos segundos. Se que también tiene que ver la poda, ya que si la evaluación no es muy buena, la poda por consecuencia también será defectuosa y por esto mismo será en vano revisar con mayor profundidad, pero supongo que debe haber una forma de equilibrar todas estas cuestiones sin terminar escribiendo el Quijote nuevamente.

Oscar Toledo se ha comprometido también a responder una segunda entrevista con algunas preguntas interesantes que salgan a partir del foro mismo y de nuestros diálogos.

Creo que hay una nueva forma de ver los módulos de ajedrez. Ahora leyendo los algoritmos tan finos que se han conseguido y sin mucho esfuerzo de pensar, se termina en pocos meses con un motor de 2400 elo. Esto en parte gracias a la velocidad de las maquinas y en parte a la cantidad tan extensa de información y ejemplos que hay para comenzar un motor. Por eso cuando llega un motor con ideas nuevas es como una bocanada de aire fresco, ya que están haciendo falta nuevos enfoques.
Todavía nadie ha programado un modulo que piense como una persona en su proceso de toma de decisiones y eso deja el campo abierto a mucho aún. Un motor de ajedrez que realmente aprenda a jugar ajedrez ajustando sus propios parámetros internos sería un buen comienzo, aunque sean parámetros prefijados por su programador.

Karbunclo escribió:Yo creo que es muy posible crear un motor en digamos 256 kb de código puro y duro lo suficientemente fuerte para vencer a el top 10 humano

Esto de hecho es cierto, el motor Gull cumple con esas características e incluso las supera. Su código fuente en la versión II Beta 2 ronda los 201 Kb y supera los 3000 Elo.

Karbunclo escribió:Creo que hay una nueva forma de ver los módulos de ajedrez. Ahora leyendo los algoritmos tan finos que se han conseguido y sin mucho esfuerzo de pensar, se termina en pocos meses con un motor de 2400 elo. Esto en parte gracias a la velocidad de las maquinas y en parte a la cantidad tan extensa de información y ejemplos que hay para comenzar un motor. Por eso cuando llega un motor con ideas nuevas es como una bocanada de aire fresco, ya que están haciendo falta nuevos enfoques.
Todavía nadie ha programado un modulo que piense como una persona en su proceso de toma de decisiones y eso deja el campo abierto a mucho aún. Un motor de ajedrez que realmente aprenda a jugar ajedrez ajustando sus propios parámetros internos sería un buen comienzo, aunque sean parámetros prefijados por su programador.

"El Genial programador Ed Schroeder acaba de tener una brillante idea, ha rescatado de entre el baúl de los recuerdos nada más y nada menos que el programa de Ajedrez Campeón del mundo en Madrid 1992 (Gideon 3.1) y lo ha trasformado en un motor UCI y Winboard ( Funciona solo con 2M de Hash Tables ) ¿ y cual es la noticia si cualquier motor libre actual le da 100 vueltas en fuerza de juego? Muy sencillo, la noticia es que este motor es de la vieja escuela, es decir, cuando se programaba para que los programas de ajedrez jugaran un ajedrez muy humanizado debido fundamentalmente a los pocos recursos de hardware que había antes, este motor destaca sobremanera en el juego posicional, lo he estado probando y juega de fábula ( Lo he probado en la Interface de Fritz 10 y Fritz 13 ) y es verdaderamente entretenido intentar jugar partidas estratégicas y posiciónales con este fantástico motor de ajedrez y ver como el bicho te intenta bloquear cada una de tus estrategias intentando anticiparse, me recuerda mucho a el mejor juego de Hiarcs, un motor sencillamente impresionante, maneja los peones de un modo increíble y busca en todo momento hacerse con el control del centro del tablero, en definitiva, es un motor de ajedrez totalmente recomendable para todos aquellos que quieran mejorar su nivel de juego estratégico sin ser aniquilado por las Bestias de hoy en día como Houdini y compañía…"

"Y ahora viene la pregunta del millón ¿ y cuanto Elo tiene ? la versión Mephisto Gideon en un 486/ 66 Mhz tiene 2271 Elo según la lista SSDF del año 2000, por lo que en equipos potentes actuales debe rondar casi los 2450 - 2500 Elo, digamos que vendría a jugar como un fuerte Gran Maestro al mejor estilo posicional, lo curioso del tema es que cuando te enfrentas al motor te da la sensación de que le puedes ganar o al menos entablar si juegas con mucha precisión y cautela, pero es un programa de ajedrez con una gran habilidad de juego y que no busca las tablas, sus puntos débiles son la defensa del Rey y los finales de partida, pero como coja una buena posición en el tablero el ahogamiento progresivo del contrario esta asegurado, directamente Gideon te mata por aplastamiento…"

http://www.top-5000.nl/donationware.htm

¿Habéis probado este motor? Parece "realmente" que estás jugando con otra persona. Además el comentario que inserto entre comillas es totalmente cierto; cuando juegas contra él parece de verdad que es accesible; hasta que, por lo menos en mi caso, (unos 1750 elo) se te come y no sabes cómo ha sido. Sabe colocar muy bien las piezas, o lo que es lo mismo,es un motor bueno posicionalmente. Otro motor que es increíble, coincide mucho con las jugadas hechas por humanos y además da gusto jugar contra él, (con su fuerza convenientemente rebajada "of course", con el Fritz se hace muy bien) es Hiarcs 13.2. Saludos.

No es tan fácil que un motor simule el pensamiento humano.
Conseguir eso, sería un éxito. Pero no sólo para los motores de ajedrez, sino para el mundo de la inteligencia artificial.
Supondría conseguir, que los motores comprendan correctamente una posición al margen de los cientos de miles de variantes que han analizado, y se emocionen en una determinada situación ante el tablero, permitiéndole esta situación cometer errores. Que una máquina juegue de forma "humana" (todavía no sé bien del todo qué significa exactamente eso), supone simular el cerebro humano orgánico en una estructura de Silicio.
Las máquinas son buenas para lo que son, y se basa mayoritariamente en la velocidad de cálculo, y en una serie de algoritmos que simulan comprender una posición. Cuanto más precisos sean esos algoritmos, más fuerte será el motor. Pasar a que juegue como un humano... eso ya es otra historia, y eso no creo que se pueda basar únicamente en los algoritmos que se les haya introducido.

Claro que no señor ociomatic,no se puede comparar el tocino con la velocidad jejj,nosotros estamos hechos especialmente nuestro cerebro de una forma "perfecta" e indiscutible..la informatica está hecha por el hombre..somos imperfecto y nunca se alcanzará la perfeccion en un engine de esa manera en pensamiento humano...saludos.

Claro que no es fácil simular el pensamiento humano, me remito al test de Turing:

http://es.wikipedia.org/wiki/Test_de_Turing

Pero hay motores que se acercan más que otros.

Cuando Oscar Toledo habla de medio mega, no creo que se está refiriendo al tamaño del código fuente, creo que se está refiriendo al tamaño de la memoria RAM necesitada. Fenix ya ha comentado que Gull con 200 Kb de código podría ganar al campeón del mundo, incluso posiblemente el código de Thinker sea más pequeño, creo que Dan Corbit comentó en una ocasión que eran 120 kb. El motor español sungorus creo recordar que tenía 36 kb de código y juega en unos 2400 puntos de Elo.

Para realizar el código más pequeño posible, además de utilizar los algoritmos más sencillos y pequeños en la programación del motor, el autor utiliza el truco de sustituir un determinado texto por otro el más pequeño posible. Por ejemplo con:

#define g Generar_movimientos_capturas(cBuf)

Cada vez que en el código fuente nos encontramos con una g el compilador lo sustituye por el texto Generar_movimientos_capturas(cBuf), de esta forma en el código el carácter g es un carácter y ocupa un byte y el autor ahorra 33 bytes por no utilizar el texto completo. Este ahorro solo es a nivel de código fuente ya que cuando el enlazador o linkador crea el código objeto que es el verdadero lenguaje que entiende el micro en ese caso el tamaño del código objeto es el mismo haya utilizado el autor g o Generar_movimientos_capturas(cBuf).

Por este truco es complicado incluso para un programador experto en programación de motores de ajedrez comprender el código de Toledo sino se deshace previamente estos trucos de ahorro de caracteres.

Por eso no se debería comparar directamente el tamaño del código fuente de Toledo con el tamaño del código fuente de otro motor, ya que cualquier otro motor podría utilizar también este truco y disminuir grandemente su tamaño sin afectar a su fuerza de juego. Sería interesante ver una versión de Toledo escrita en forma de un código que no utilice ese truco para el ahorro, ese código si que se podría comparar más fácil en cuanto a tamaño, pero seguro que Oscar prefiere mantenerlo secreto (si existiese) para que nadie le copie e intente hacerlo más pequeño.

Que yo conozca hay otros 2 motores del estilo de Toledo; uno de ellos es Micro-max de HG Muller, su tamaño es inferior a 2 kb pero es más grande que el tamaño de Toledo nanochess, estoy casi seguro que su autor habrá intentando batir el record de Oscar de código más pequeño pero no ha podido, aunque el motor de Muller utiliza algún algoritmo extra que da más fuerza al motor, ambos programadores han conseguido más o menos que por cada carácter de código fuente consiguen 1 punto de Elo. Otro motor del estilo es Iota, ahora no recuerdo el nombre de su autor, éste motor utiliza el protocolo uci a diferencia de los otros 2, si no recuerdo mal lo extraordinario es que el autor dice que el código lo creó en 1 día de trabajo, aunque es creado a partir del código fuente de otro motor que había creado anteriormente el autor.

En la página https://sites.google.com/site/motoresdeajedrez/motores-hispanos/elo podéis ver el Elo del motor. El motor juega de forma estable, no tiene problemas (muchos motores débiles suelen tener errores que provocan que no termine la partida). En el control de tiempo 3+2 suele alcanzar profundidad 6 ó 7. Un defecto que tiene el motor (no se si lo conoce su autor) es que la evaluación en algunas ocasiones puede pasar de un movimiento a otro por ejemplo de 0 a +8 para volver a 0 en el siguiente movimiento, creo que esto no afecta a la fuerza del motor, quizás solo es un error de visualización. Creo que otro problema del motor es que no sabe que la partida ha terminado e intenta seguir jugando, supongo que esto si que tiene que ver con el ahorro de código para hacerlo lo más pequeño posible. Winboard Zeta tiene una opción que se llama game over detetion que detecta el final de juego y no deja seguir jugando a aquellos motores que no lo saben.

Lo que me llamó mucho la atención fue cuando el autor comentó en la entrevista como había hecho para la evaluación, como cada parámetro de la evaluación supone código extra para muchas cosas había utilizado el valor 1. Así que no podemos pedir una gran exactitud en la evaluación, a pesar de no utilizar valores más exactos la evaluación es bastante buena salvo quitando el error que antes había comentado de saltos enormes en la evaluación de +6 ó +8.

La versión que me impresionó fue una creo que era javascript en la que incluía interfaz gráfica y todo en 2kb.

Pedrox, Fenix. Muy cierto. Yo recién hoy me he puesto a ver con detenimiento a motores como Gull, pequeños y bien armados.

Yo estimo que el código de Szachy Nanochess debe rondar los 80 o 100 Kb por unos 2400 Elo. Gull tiene 201 Kb de código fuente y esta a la par del famoso Rybka 2.3 que nadie podía superar hace unos años.

Ahora bien, aquí también hay que hacer una diferencia. Una cosa es el código fuente pequeño debido a su simpleza y otra debido a técnicas que permiten reducir su tamaño a costa de tornarlo mas complejo en su programación. Creo que lo mas natural para todo programador es intentar conseguir un código limpio, prolijo y sencillo. Con algoritmos simples y brillantes. Creo que en este punto Gull tiene parte del secreto, ya que su reducido tamaño no esta pensado para ahorrar bits como el caso de los Szachy o para conseguir lo mas pequeño posible como Toledo Nanochess. Gull sabe llevar un lindo equilibrio en este punto. La claridad de código y programación vs. tamaño final resulta agradable. Quizás de los códigos mas sencillos y eficientes también se ubique Greko pero sobre todo ligado a la claridad de programación.

Obviamente sería interesante encontrar la piedra filosofal de los motores de ajedrez que sea pequeño, eficiente, rápido y al mismo tiempo entendible gracias a algoritmos sencillos. Lamentablemente eso no existe aún.

Ciertamente cuanto menos pasos tenga un algoritmo, también se debiera ejecutar a más velocidad.

Sin ser un gran programador de motores me llama mucho la atención lo pequeña que suele ser la parte del código dedicada a la poda y a la evaluación, lo que para mi entender (no programador especializado en el tema) es de lo mas importante que tiene el programa y sin embargo lo increíblemente extenso del resto del código. Que parte de los códigos aún faltan optimizar o simplificar? O es que se ha puesto tanto interés en la poda y evaluación que el grueso del trabajo de los programadores se situó en esos dos paradigmas dejando menos optimizado todo el resto?

Igualmente yo digo todo esto generalizando. A penas tengo visto algunos motores por dentro, pero suelo ver que el grueso de la tripa se lo llevan cosas que no parece que sean muy importantes en cuanto a fuerza de juego final.

Karbunclo escribió:Ciertamente cuanto menos pasos tenga un algoritmo, también se debiera ejecutar a más velocidad.

Sin ser un gran programador de motores me llama mucho la atención lo pequeña que suele ser la parte del código dedicada a la poda y a la evaluación, lo que para mi entender (no programador especializado en el tema) es de lo mas importante que tiene el programa y sin embargo lo increíblemente extenso del resto del código. Que parte de los códigos aún faltan optimizar o simplificar? O es que se ha puesto tanto interés en la poda y evaluación que el grueso del trabajo de los programadores se situó en esos dos paradigmas dejando menos optimizado todo el resto?

Igualmente yo digo todo esto generalizando. A penas tengo visto algunos motores por dentro, pero suelo ver que el grueso de la tripa se lo llevan cosas que no parece que sean muy importantes en cuanto a fuerza de juego final.

Cuando un motor está pensando en un determinada posición, lo que hace es estar creando un árbol de variantes, con fuerza bruta pensaría en todas las posibilidades, con selectividad podrá eliminar ciertos movimientos o posiciones para profundizar en la búsqueda. En este momento que se está creando el árbol tenemos que tener en cuanta cuales son las funciones que se utilizan porque son las que hay que realmente optimizar, estás funciones se están repitiendo una y otra vez, en una posición primero tendremos que generar la lista de movimientos que puede hacer el programa, por lo que es importante que el generador sea lo más rápido posible, en la búsqueda la función alfabeta se llama así misma una y otra vez por lo que es importante que también el código durante la función alfabeta sea lo más optimizado posible, esto incluye la generación de nuevos movimientos y la ordenación de los mismos de mejor a peor para salir cuanto antes de la búsqueda, al final de las ramas del árbol, en las hojas, cuando hemos terminado la búsqueda se suele comprobar que el motor no tenga el efecto horizonte, para ello es necesario comprobar las capturas hasta llegar a una situación tranquila, por tanto el generador de capturas también deberá ser rápido y por último cuando ya estamos en la posición tranquila se comprueba la evaluación para esa posición, por eso también es importante que el código en la evaluación esté optimizado.

Para saber donde optimizar se puede usar un profiler, esta herramienta nos dirá el tiempo que emplea el motor en cada función y tendremos idea de dónde suele estar más tiempo el motor, es increible pero muchas veces la búsqueda suele estar generando capturas para evitar el efecto horizonte, es una de las cosas que más tiempo consume.

Hay cierto código que no es importante si está optimizado o no, por ejemplo el código que maneja el libro de aperturas, cualquier programa con libro de aperturas responde en unos pocos milisegundos. Vamos a suponer que tu programa responde en 50 milisegundos, por mucho que intentes optimizar este código y consigas por ejemplo bajarlo a 25 milisegundos, la mejora en el juego va a ser mínima, primero porque no en todos las posiciones se utiliza el libro y segundo porque el ahorro que tienes es 25 milisegundos y con esto es imposible que consigas una nivel extra de profundidad, a no ser que se traten de partidas ultra-rapidas jugadas en milisegundos. Otro código por ejemplo que no es importante que esté optimizado, el código para configurar el tablero, es decir código para pasar por ejemplo de una posición en formato FEN al interno utilizado por el motor, tampoco es importante si está optimizado el código que comprueba si un movimiento del contrario es legal o no, esto el motor lo puede hacer en 1 ms, no parece muy importante si el motor va a pensar por ejemplo durante 5 segundos quitar un 1 ms para la búsqueda. Hay más casos.

El tamaño de la funciones de búsqueda y evaluación también depende de la fuerza del motor, normalmente suele ser más grande en aquellos motores más fuertes y puede variar mucho en tamaño frente a motores más débiles, se puede escribir una función de busqueda y evaluación en apenas 20 líneas si utlizas un alfabeta sencillo y una evaluación solo de material. Sin embargo si observas la búsqueda en programas como stockfish verás que no es precisamente pequeña y lo mismo con la evaluación por ejemplo de crafty.

Hola: yo ya me había fijado el programa Gull, lo que ocurre es que muchas veces casi todos buscamos lo mejor, lo máximo. A mi poniéndole diferentes posiciones me pareció en su día que Gull era un programa posicional fuerte, y no resolvía algunos problemas tácticos y de ataque cómo otros más avanzados. Decir también que mis conocimientos de programación son casi nulos. Aunque si ajedrecísticos, y me gusta mucho expirementar con los engines. Hace un mes que compré DeepHiarcs 14 Explorer y DeepHiarcs 14 UCI. Aunque no he tenido mucho tiempo de analizarlo a fondo. He tenido problemas para instalar la versión UCI en la GUI de DShredder12 y de Fritz12, pero en Arena 3 funciona ¡¡ ¿¿Alguien sabe algo al respecto??

Peter.

Cuando instalas un motor en Fritz, si luego cambias la carpeta de sitio no encuentra el motor. Cuando instalas Deep Hiarcs 14 en tu equipo, el motor va a parar (en Vista) a esta dirección:

C:\Program Files\HIARCS Chess\HIARCS 14 WCSC

¿Puede ser el problema que hayas puesto el motor en la carpeta donde tienes los demás y ahora Fritz no encuentre la ruta? Saludos.

Gracias Jose, revisaré por enésima vez, aunque he llegado a la conclusion que la GUI de Hiarcs Explorer produce algún conflicto en la máquina con algunas GUIs, ya que con Arena 3.0 funciona y la UCI Dhiarcs 14 tambien funciona ¡¡.......saludos

Lo interesante de Gull es que fija la meta en otro paradigma, el programa mas fuerte con menor cantidad de código.

Me gustaría ver primeramente alguna versión de este mismo mas depurada, no una Beta con su correspondientes versiones en todos los gustos (x64 y deep). Creo que estaría sin duda justo un paso por detras de komodo y critter, justo por encima de rybka 4 y mano a mano con houdini 1.5, o levemente inferior a este último. Quizás no en breve, pero si en mediano plazo. Siendo tan pequeño hay mucho que se puede agregar