Lista de motores xboard y uci por programadores hispanos

Un foro especial para los amigos de lengua Hispana!

Moderator: Fernando

pedrox
Member
Posts: 43
Joined: Wed Sep 26, 2007 7:53 am

Post by pedrox »

Dylan Sharp wrote:¡Ajaja! No, es posible que en tu programa si funcionen, mi punto era que hay evaluaciones que aunque parescan buenas o funcionen en otros programas pueden ser contraproducentes. ;)

Saludos.
Si, totalmente cierto, también ocurre lo mismo con las diferentes técnicas de búsqueda.

Saludos
User avatar
Andres Valverde
Member
Posts: 3
Joined: Wed Dec 10, 2008 7:24 pm
Contact:

Post by Andres Valverde »

IA wrote:Hola Pedrox , estos son los parámetros más importantes para programar un motor de ajedrez ¿sabes si hay alguna otra estructura de juego interesante que se use frecuentemente en la programación actual?


Ventaja Material
Estructura de peones
Peones Aislados y retrasados.
Control relativo del centro.
Peones en color opuesto al alfil propio.
Peones pasados
Posición de las piezas.
Caballos avanzados, protegidos o atacados.
Torres en columnas abiertas o semiabiertas.
Torres en séptima fila.
Torres dobladas.
Posibilidades de ataque.
Piezas que protegen a otras piezas.
Ataques sobre otras piezas.
Ataques sobre casillas adyacentes al rey enemigo.
Clavadas.
Movilidad, medida por el número de movimientos legales posibles.




Gracias Pedrox….
Creo que si implementas todas estas cosas, y las armonizas bien tienes...Hiarcs o Rybka :-)

Ya en serio, mi pequeña experiencia en evaluación, a la que me dedico casi en exclusiva en Dirty, me dice que muchas de las caracteristicas que has expuesto se solapan, y es realmente difícil armonizar todas ellas. Por ejemplo , "Posicion de las piezas" supongo que te refieres al uso de Tablas-Pieza-Casilla (Piece Square Tables). Esto tiene mucho que ver con la movilidad, y hay que armonizarlos bien, pues puedes obtener valores exagerados o incluso contradictorios. Otro ejemplo son las torres en septima, muchas veces se solapan con la seguridad del rey etc.etc.

Para mi parecer, hay tres cosas que un programa debe evaluar bien antes de introducir más :

1. Valor de las piezas segun el estado de la partida
2. Movilidad-espacio
3. Peones pasados

Si empezara de cero, intentaría optimizar estos tres parámetros, pues en la práctica son los que proporcionan gran parte de los puntos.

Luego pasaría a seguridad del rey, debilidades, etc.

Pasa mucho que los parámetros que hacen que el programa juegue "bonito" a nuestros ojos humanos, luego lo hacen en realidad más debil en el juego real. (Un ejemplo : lo que comentabais del alfil en d3 con peón en d2). En fin... el tema da para mucho..
Saludos, Andres
User avatar
Dylan Sharp
Senior Member
Posts: 2431
Joined: Fri Aug 10, 2007 12:07 am

Post by Dylan Sharp »

Andres Valverde wrote:Pasa mucho que los parámetros que hacen que el programa juegue "bonito" a nuestros ojos humanos, luego lo hacen en realidad más debil en el juego real.
Lo que hizo Lance Perkins, el programador de Thinker, fue sacar dos versiones, la "bonita" (Active) y la "fea" (Passive), y la bonita también estaba especializada en jugar contra humanos.

Más tarde Passive (Pasiva) jubaba, irónicamente, un juego extremadamente agresivo, y los nombres que se les dió originalmente a estas versiones ya no cuadraban, pero así se les dejó (luego sacó la version "Inert" (inerte) que es la más fuerte de todas.)

Así, que el programa puede tener varias versiones aunque sus nombres no les queden. :)

Saludos.
User avatar
Fernando
Admiral of the Fleet
Posts: 3059
Joined: Tue Jul 31, 2007 4:35 pm
Location: Santiago de Chile

Post by Fernando »

pedrox wrote:
Dylan Sharp wrote:
pedrox wrote: También como parte de ese desarrollo, aunque esto se puede evaluar hasta la fase final del juego, sería controlar que los peones centrales no estén bloqueados por piezas propias. Por ejemplo si tenemos un peón en e4 no jugar el alfil a d3 bloqueando el peón de d2.
Creo que este es uno de los conocimientos que Larry Kaufman, el programador de evaluación de Rybka, reveló que Rybka no tiene, y que al tratarlo de añadir Rybka jugaba más débil.

Parece que es una de las ideas humanas que no funcionan en los programas, y que a veces el mejor movimiento es bloquear tus peones centrales con tus piezas y programas se pierden del mejor movimiento por este fragmento de evaluación erronea, que creo que ha sido removido de algunos programas de última generación, pues siento haber visto estos movimientos "feos" más frecuentemente.
Hola Dylan,

Yo me refería a evitar movimientos como el último jugado en la siguiente posición por el alfil blanco, en este caso el alfil bloquea el peón de d2 que a su vez bloquea el alfil en c1. Creo que este es un mal movimiento, que va a afectar al desarrollo del blanco y que el motor debería evitar. Además la comprobación de ese bloqueo no es nada costosa y no debería influir en la velocidad del programa. Por otra parte también es verdad que evitar ese movimiento seguramente dará 0 puntos de ELO ya que con un libro de aperturas es posible que el programa no juegue eso, incluso jugándolo no significa que vaya a perder, si el motor es muy superior al contrario a pesar de que ese movimiento no debería jugarlo seguramente terminará ganando.

Quizás un GM humano podría aprovecharse mejor de ese movimiento que un motor, bueno esto es algo que no lo se.

[fen]r1bqkbnr/pppp1ppp/2n5/4p3/8/3B1N2/PPPP1PPP/RNBQK2R b KQkq - 0 1[/fen]

¿Te referías a este tipo de bloqueo?
Dylan Sharp wrote: Otro termino humano que parece no funcionar (al menos en Rybka) es el concepto de "Islas de peones", que hay programas que penalizan mientras más islas de peones se tengan, pero parece que es otro termino erroneo.
Creo recordar que esto lo vi en el foro de Rybka.

Según la definición de islas de peones, estas engloban a los peones aislados.

¿Esto significa que Rybka ahora no valora los peones aislados?

Normalmente los motores dan una pequeña penalización a los peones aislados, algo así como 7% del valor de un peón, quizás un poco más para los peones centrales ya que muchas veces los peones centrales son los que más fácil son de atacar y que podemos ganar.
Dylan Sharp wrote: Yo recomiendo añadir cosa por cosa y ver qué funciona en tu programa y que no, a veces un termino diferente ya cubre algún termino que estás tratando de añadir que se vuelve redundante y vuelve al programa más lento.
Es cierto que hay que introducir las cosas en los programas de una en una, en cuanto introduces 2 ya no sabes si una funciona o no, lo malo es que muchas veces los cambios en la evaluación son muy complicados de comprobar si son buenos o malos, cambiando un pequeño valor por ejemplo el valor de los peones doblados, vamos a suponer que damos una penalización inicial al peón doblado de un 20% del valor de un peon, si esto lo cambiamos por ejemplo por 15%, necesitaremos miles de partidas para saber si un valor es mejor o lo es el otro. Y salvo personas como el Dr Hyatt que disponen de un cluster y pueden jugar varios miles de partidas en una hora, los demás no podemos hacer muchas comprobaciones de esas.

Saludos

Pedro
Quizás un modo más genérico de resolver algnos de estos problemas en vez de dar bonos o sanciones a tals o cuales jugadas o situaciones es buscar el facto comun que hace de tals o cuales movidas algo malo. Ese factor cmún es, quizás, la cantidad de casillas bajo control NO inmediataente como resultado del movimiento, sino las que pueden potencialmente controlarse en el siguiente.
En el caso del alfil a dama tres, el alfil, al salir de su casilla, agrega casillas de control n el momento presente, PERO claramente al bloquear el peon disminuye el numero potencial de casillas controlables en la proxima jugada que si no se hiciese.
La idea es que el control del tablero es algo que debe evaluarse en un contxto istórico de jugadas , digamos dos, tres o cinco, no solo al momento presente.
Quizás este breve analisis sirva de algo...
Fernando
Festina Lente
pedrox
Member
Posts: 43
Joined: Wed Sep 26, 2007 7:53 am

Post by pedrox »

Fernando wrote:
pedrox wrote:
Dylan Sharp wrote:
pedrox wrote: También como parte de ese desarrollo, aunque esto se puede evaluar hasta la fase final del juego, sería controlar que los peones centrales no estén bloqueados por piezas propias. Por ejemplo si tenemos un peón en e4 no jugar el alfil a d3 bloqueando el peón de d2.
Creo que este es uno de los conocimientos que Larry Kaufman, el programador de evaluación de Rybka, reveló que Rybka no tiene, y que al tratarlo de añadir Rybka jugaba más débil.

Parece que es una de las ideas humanas que no funcionan en los programas, y que a veces el mejor movimiento es bloquear tus peones centrales con tus piezas y programas se pierden del mejor movimiento por este fragmento de evaluación erronea, que creo que ha sido removido de algunos programas de última generación, pues siento haber visto estos movimientos "feos" más frecuentemente.
Hola Dylan,

Yo me refería a evitar movimientos como el último jugado en la siguiente posición por el alfil blanco, en este caso el alfil bloquea el peón de d2 que a su vez bloquea el alfil en c1. Creo que este es un mal movimiento, que va a afectar al desarrollo del blanco y que el motor debería evitar. Además la comprobación de ese bloqueo no es nada costosa y no debería influir en la velocidad del programa. Por otra parte también es verdad que evitar ese movimiento seguramente dará 0 puntos de ELO ya que con un libro de aperturas es posible que el programa no juegue eso, incluso jugándolo no significa que vaya a perder, si el motor es muy superior al contrario a pesar de que ese movimiento no debería jugarlo seguramente terminará ganando.

Quizás un GM humano podría aprovecharse mejor de ese movimiento que un motor, bueno esto es algo que no lo se.

[fen]r1bqkbnr/pppp1ppp/2n5/4p3/8/3B1N2/PPPP1PPP/RNBQK2R b KQkq - 0 1[/fen]

¿Te referías a este tipo de bloqueo?
Dylan Sharp wrote: Otro termino humano que parece no funcionar (al menos en Rybka) es el concepto de "Islas de peones", que hay programas que penalizan mientras más islas de peones se tengan, pero parece que es otro termino erroneo.
Creo recordar que esto lo vi en el foro de Rybka.

Según la definición de islas de peones, estas engloban a los peones aislados.

¿Esto significa que Rybka ahora no valora los peones aislados?

Normalmente los motores dan una pequeña penalización a los peones aislados, algo así como 7% del valor de un peón, quizás un poco más para los peones centrales ya que muchas veces los peones centrales son los que más fácil son de atacar y que podemos ganar.
Dylan Sharp wrote: Yo recomiendo añadir cosa por cosa y ver qué funciona en tu programa y que no, a veces un termino diferente ya cubre algún termino que estás tratando de añadir que se vuelve redundante y vuelve al programa más lento.
Es cierto que hay que introducir las cosas en los programas de una en una, en cuanto introduces 2 ya no sabes si una funciona o no, lo malo es que muchas veces los cambios en la evaluación son muy complicados de comprobar si son buenos o malos, cambiando un pequeño valor por ejemplo el valor de los peones doblados, vamos a suponer que damos una penalización inicial al peón doblado de un 20% del valor de un peon, si esto lo cambiamos por ejemplo por 15%, necesitaremos miles de partidas para saber si un valor es mejor o lo es el otro. Y salvo personas como el Dr Hyatt que disponen de un cluster y pueden jugar varios miles de partidas en una hora, los demás no podemos hacer muchas comprobaciones de esas.

Saludos

Pedro
Quizás un modo más genérico de resolver algnos de estos problemas en vez de dar bonos o sanciones a tals o cuales jugadas o situaciones es buscar el facto comun que hace de tals o cuales movidas algo malo. Ese factor cmún es, quizás, la cantidad de casillas bajo control NO inmediataente como resultado del movimiento, sino las que pueden potencialmente controlarse en el siguiente.
En el caso del alfil a dama tres, el alfil, al salir de su casilla, agrega casillas de control n el momento presente, PERO claramente al bloquear el peon disminuye el numero potencial de casillas controlables en la proxima jugada que si no se hiciese.
La idea es que el control del tablero es algo que debe evaluarse en un contxto istórico de jugadas , digamos dos, tres o cinco, no solo al momento presente.
Quizás este breve analisis sirva de algo...
Fernando
La gran mayoría de programas miden el número de casillas que controla cada pieza, esto es la movilidad y es una parte importante de la evaluación, hacer este control hace el programa más lento pero lo hace jugar mucho mejor y seguramente esto dará más de 100 puntos de ELO.

Prácticamente también la totalidad de programas hacen la busqueda por niveles de profundidad, empiezan en profundidad 1, luego pasan a 2, de esa forma los programas evaluan no solo la movilidad en la jugada presente, sino la evaluarán también después de x niveles.

En la posición anterior, si controlamos la movilidad, seguramente el programa podría calcular que el alfil blanco está mejor en la casilla c4, de esta forma luego podría mover el peón de d2 a d3 y así el afil que está en c1 estaría controlando esa diagonal. Quizás el programa también podría calcular que es posible hacer b3 y sacar el alfil por fiancheto y quizás el número de casillas controladas sea igual.

Pero además de ese control de casillas por parte de cada una de las piezas, necesitamos también enseñar más cosas al programa, por ejemplo aunque podamos sacar el alfil de c1 por fiancheto, el peón de d2 quedará sin poder desarrollarse, y de todos es sabido que la ocupación del centro suele ser importante, el peon de de d2 estará mucho mejor en d3 evitando que las negras avancen su peón a e4.

Así que no es incompatible ese control de casillas con el hecho de dar bonos o penalizaciones en algunas situaciones. Por ejemplo, a pesar de que los programas juegan muy profundos, es increible ver como los alfiles se quedan atrapados en casillas como a2, h2, a7 y h7, comen el peon y no se dan cuenta que el contrario puede adelantar el peon y que este a su vez está protegido con otro peón y dejando al alfil atrapado y a la larga comerse el alfil o tener que cambiarlo por un segundo peon. Dar una penalización de un peon y medio por comer el alfil uno de esos peones resuelve el problema.

Lo que si que hay que tener cuidado, como creo que comentó anteriormente Dylan, es que no se junten varios terminos a la vez que hagan lo mismo y que demos una penalización o bonus mayor de lo debido, el programa también jugará mal. Igualmente si nos quedamos cortos.

Pedro
User avatar
Andres Valverde
Member
Posts: 3
Joined: Wed Dec 10, 2008 7:24 pm
Contact:

Post by Andres Valverde »

Como resumen, con mi experiencia "tuneando" funciones de evaluación:

La función de evaluación es una heurística que *no* debe reemplazar a la búsqueda, sino ayudarla a definir el valor de la posición más lejana que ésta pueda alcanzar. Cualquier valor dado a una característica de la posición, de forma heurística, puede ser refutado por el desarrollo táctico de la partida, y así sucede a menudo.

Si nuestra búsqueda es media o deficiente, la función de evaluación debe asumir mas "riesgos" y frecuentemente dar valores a situciones como las que comenta Pedro, de piezas mal situadas, peones pasados peligrosos etc. Algunas de estas cosas no las ven ni las búsquedas más avanzadas.

No tiene sentido evaluar cosas que la búsqueda puede resolver por si misma en unos pocos movimientos, esto sólo va a entorpecer el rendimiento general del motor, y esto es un poco lo que propone Fernando. De todas formas, para motores con una busqueda limitada, este tipo de cosas pueden hacerlos jugar mejor en general, sobre todo contra motores potentes, aun a riesgo de perder partidas contra adversarios en teoría más débiles.

De todas formas, este es el "meollo" del funcionamiento de un motor de ajedrez, y hay tema para largo :-)

Saludos, Andres
Saludos, Andres
User avatar
IA
Member
Posts: 433
Joined: Wed Sep 10, 2008 1:12 pm
Location: Spain

Post by IA »

Hola Pedrox , tengo una curiosidad con respecto a el fabuloso programa de ajedrez de Frans Morch que hizo a principio de los 90 , me refiero a el programa que tiene la Saitek GK-2000 y sus derivados......... este programita de tan solo 16k funciona en un Chip H8 Risc de tan solo 10 Mhz y obtiene un Elo de +1900 Elos , como programador me gustaría saber que tipo de programación básica crees que introdujo en tan poco espacio para que obtuviera un nivel de juego tan alto , me refiero a que tipo de estrategias se pueden poner en tan poco espacio para ser tan efectivas.

Según tengo entendido tenia un estilo de programación especial donde solo analizaba 2 movimientos por cada pieza que lo hacia muy rápido , aparte de esto ¿que tipo de conocimientos ajedrecisticos cres que tiene dentro para obtener este nivel tan alto de fuerza?

Saludos...........
pedrox
Member
Posts: 43
Joined: Wed Sep 26, 2007 7:53 am

Post by pedrox »

Sería mejor preguntar a un experto como Ed Shroeder que algunas veces frecuenta este foro para preguntar sobre programación de estas máquinas.

Para que un programa gane a un jugador de 1900 puntos de ELO no se necesita que el programa tenga grandes conocimientos.

Mira Micro-max 4.8 de H.G. es un programa de 2k
http://home.hccnet.nl/h.g.muller/max-src2.html

Los conocimientos que tiene el programa son:
- material
- dar un bonus para que las piezas estén en el centro (importante sobre todo para caballos y alfiles, basta una sencilla tabla)
- que el rey no vaya al centro en la apertura y medio juego, en cambio si en el final
- peones pasados

EL ELO de este programa es de unos 2050 puntos. Su fuerza no está en los conocimientos ajedrecisticos, más bien en su búsqueda combinado con la velocidad que tienen hoy en día los ordenadores.

El programa de la Saitek Gk-2000 me imagino que tendrá más evaluación pero una búsqueda más lenta, en gran parte porque cuenta con un procesador de pocos MHz y en parte porque también las técnicas de busqueda han evoluacionado desde entonces, micro-max es un programa reciente.

He visto alguna partida de esta máquina y está claro que además del material y las tipicas tablas de piezas y posiciones tiene conocimiento por ejemplo sobre columnas abiertas para las torres (un término muy importante). Es posible que también cuente con algún bonus para el enroque. Parece valorar más los alfiles que caballos.

Entre sus defectos está una mala seguridad del rey aunque en su búsqueda extiende los jaques y puede dar en unos segundos con un mate por ejemplo en 7. Es posible que juegue prematuramente la dama.

Quizás del estudio de partidas se podría sacar más información.

Creo que se puede ver la profundidad en la que juega el programa, en una partida de 5 minutos por ejemplo cual es la profundidad que alcanza?, en una partida de 2 horas?

Para un jugador de 1900 puntos jugar ya a una profundidad de 6-8 es complicado, quizás esta máquina puede alcanzar esta pronfundidad en partidas, si la conoces dímelo.

Mi opinión es que el secreto de esta máquina es posible que esté en su búsqueda más profunda que otras, más que en su evaluación. Si no recuerdo mal Frans Morsch es uno de los inventores del movimiento nulo, una de las técnicas de más éxito en la búsqueda y creo que fue inventando más o menos por esa época.

Un saludo,

Pedro
Post Reply