Idea para programadores?
3 participantes
Foro SiliconChess - Programas de Ajedrez y Actualidad :: GENERAL, Sobre Ajedrez :: AJEDREZ INFORMATICO (Máxima actualidad de los programas de ajedrez pc windows mac os linux).
Página 1 de 1.
Idea para programadores?
8/8/4k2p/p3p1pP/Pp1pPpP1/1PpP1P2/2P1K3/4Q3 w - -
Este problema y todos los de esta clase que son difíciles de ver para los motores coinciden en un punto.
Primero que nada la evaluación se estanca mucho rato sin variaciones. Esto tendría que ser tenido en cuenta por los programadores para que coloquen en sus programas una sentencia que luego de X tiempo con la evaluación sin cambios, entonces el programa comience en segundo plano a buscar posiciones con sacrificios.
Todos sabemos que las personas buscamos sacrificios cuando no vemos progresos por la via standart y nos vamos a los sacrificios, porque los programas no lo incorporan de una buena vez?
Este problema y todos los de esta clase que son difíciles de ver para los motores coinciden en un punto.
Primero que nada la evaluación se estanca mucho rato sin variaciones. Esto tendría que ser tenido en cuenta por los programadores para que coloquen en sus programas una sentencia que luego de X tiempo con la evaluación sin cambios, entonces el programa comience en segundo plano a buscar posiciones con sacrificios.
Todos sabemos que las personas buscamos sacrificios cuando no vemos progresos por la via standart y nos vamos a los sacrificios, porque los programas no lo incorporan de una buena vez?
Re: Idea para programadores?
Imagino que será complicado por el famoso efecto horizonte. Aunque parezca extraño, yo creo que las máquinas no están pensando en el mate como objetivo final de la partida, sino que su posición tenga los "máximos puntos" a su favor posibles, según los algoritmos que tienen introducidos. Entonces... ¿para qué se van a complicar la vida en esta posición, cuando disfrutan de la ventaja de +13?
ociomatic- Mensajes : 205
Fecha de inscripción : 09/11/2011
Edad : 52
Re: Idea para programadores?
Justamente yo digo que se agregue un parámetro que indique por ejemplo si la valoración se estanca durante X tiempo, entonces buscar sacrificios. Osea que es una idea para justamente intentar saltearse el efecto horizonte, ya que se elijen segundos movimientos o movimientos de menor envergadura.
Imaginemos que en este problema a un programa que no lo puede resolver, se le agrega la capacidad para que busque hacer sacrificios. Si esto tal cual lo digo es muy difícil de programar, digamoslo así. Si la evaluación se estanca en un numero X durante mas de 30 segundos, entonces a la posición que se esta evaluando se le resta 1 centipeon cada 10 segundos. De esta manera, a mas adelante siga el proceso de búsqueda estancado, menos vale esa posición y por tanto mas posibilidades tiene el motor de buscar otras con menor valoración inicial, aunque con mas posibilidades de evolución.
Yo ciertamente no se como programar o incorporar este parámetro, pero creo que tiene que estar basado en el tiempo en que una valoración permanece estancada y que por cada segundo adicional que siga estancada la misma debe valer menos. Osea, si en 1 minuto y en 10 la valoración es la misma, podemos suponer que se trata tablas a la larga, aunque la valoración sea +9.00
Tampoco digo desviar toda la fuerza del motor en una posición posiblemente mala, sino una pequeña parte de su tiempo (un 10% por ejemplo), aunque la valoración de la posición sea positiva para el motor. Osea, un estancamiento el motor lo debería ver como algo tan negativo como unos peones doblados, una pareja de alfiles o una torre en la 7ma fila e incluso mucho más a medida que el tiempo se incremente.
Imaginemos que en este problema a un programa que no lo puede resolver, se le agrega la capacidad para que busque hacer sacrificios. Si esto tal cual lo digo es muy difícil de programar, digamoslo así. Si la evaluación se estanca en un numero X durante mas de 30 segundos, entonces a la posición que se esta evaluando se le resta 1 centipeon cada 10 segundos. De esta manera, a mas adelante siga el proceso de búsqueda estancado, menos vale esa posición y por tanto mas posibilidades tiene el motor de buscar otras con menor valoración inicial, aunque con mas posibilidades de evolución.
Yo ciertamente no se como programar o incorporar este parámetro, pero creo que tiene que estar basado en el tiempo en que una valoración permanece estancada y que por cada segundo adicional que siga estancada la misma debe valer menos. Osea, si en 1 minuto y en 10 la valoración es la misma, podemos suponer que se trata tablas a la larga, aunque la valoración sea +9.00
Tampoco digo desviar toda la fuerza del motor en una posición posiblemente mala, sino una pequeña parte de su tiempo (un 10% por ejemplo), aunque la valoración de la posición sea positiva para el motor. Osea, un estancamiento el motor lo debería ver como algo tan negativo como unos peones doblados, una pareja de alfiles o una torre en la 7ma fila e incluso mucho más a medida que el tiempo se incremente.
Re: Idea para programadores?
Si no me equivoco con la posición presentada el problema es que los motores analizan la posición como +10 cuando en realidad son unas tablas, aquí las blancas no pueden ganar ni aunque sacrifiquen la dama.
El problema para los motores puede estar relacionado con la profundidad que alcanzan y también está relacionado con la regla de los 50 movimientos. Un motor sabe que si no hay captura o movimiento de peón en 50 movimientos la partida terminará en tablas. Para saber que esta posición es tablas el motor desde esta posición debería alcanzar un nivel de profundidad o ply (un ply es medio movimiento) de 100. En un tiempo razonable de 3 minutos es difícil que un motor llegue a los 40 plys de profundidad, hasta 100 queda una barbaridad y por mucho tiempo que le dejemos no alcanzará esa profundidad.
Algunos motores tratan de adelantarse a la regla de los 50 movimientos, por ejemplo si cuando llegamos a los 40 movimientos y no estamos avanzando entonces divide la evaluación entre 2 y la evaluación será más real y se puede reducir progresivamente hasta llegar a cero en los 50 movimientos. Supongo que es importante determinar tras que movimiento podemos ir reduciendo la evaluación ya que si nos precipitamos también afectará negativamente al juego.
Pero incluso de esta forma seguimos teniendo un problema ya que el motor seguirá sin llegar a la profundidad 80.
No es cierto que los motores en esta situación no examine movimientos de sacrificios, en su búsqueda el motor genera todos los movimientos incluidos todos los sacrificios, simplemente con el nivel de profundidad alcanzado no ve que ningún sacrificio sirva para ganar. Algunos algoritmos de corte o reducción del árbol hará que quizás incluso sea más complicado ver los sacrificios, pero si se alcanzase la profundidad adecuada se verían esos sacrificios.
Quizás se podría pensar que es buena idea entonces extender aquellos movimientos que hacen un sacrificio si la evaluación se estanca, el problema es que en cuanto lo hagamos lo que vamos a conseguir es que el nivel de profundidad alcanzado se estanque porque hemos hecho crecer el árbol exponencialmente y el motor lo va a tener complicado para seguir alcanzado profundidades altas.
El problema para los motores puede estar relacionado con la profundidad que alcanzan y también está relacionado con la regla de los 50 movimientos. Un motor sabe que si no hay captura o movimiento de peón en 50 movimientos la partida terminará en tablas. Para saber que esta posición es tablas el motor desde esta posición debería alcanzar un nivel de profundidad o ply (un ply es medio movimiento) de 100. En un tiempo razonable de 3 minutos es difícil que un motor llegue a los 40 plys de profundidad, hasta 100 queda una barbaridad y por mucho tiempo que le dejemos no alcanzará esa profundidad.
Algunos motores tratan de adelantarse a la regla de los 50 movimientos, por ejemplo si cuando llegamos a los 40 movimientos y no estamos avanzando entonces divide la evaluación entre 2 y la evaluación será más real y se puede reducir progresivamente hasta llegar a cero en los 50 movimientos. Supongo que es importante determinar tras que movimiento podemos ir reduciendo la evaluación ya que si nos precipitamos también afectará negativamente al juego.
Pero incluso de esta forma seguimos teniendo un problema ya que el motor seguirá sin llegar a la profundidad 80.
No es cierto que los motores en esta situación no examine movimientos de sacrificios, en su búsqueda el motor genera todos los movimientos incluidos todos los sacrificios, simplemente con el nivel de profundidad alcanzado no ve que ningún sacrificio sirva para ganar. Algunos algoritmos de corte o reducción del árbol hará que quizás incluso sea más complicado ver los sacrificios, pero si se alcanzase la profundidad adecuada se verían esos sacrificios.
Quizás se podría pensar que es buena idea entonces extender aquellos movimientos que hacen un sacrificio si la evaluación se estanca, el problema es que en cuanto lo hagamos lo que vamos a conseguir es que el nivel de profundidad alcanzado se estanque porque hemos hecho crecer el árbol exponencialmente y el motor lo va a tener complicado para seguir alcanzado profundidades altas.
pedrox- Mensajes : 81
Fecha de inscripción : 14/11/2011
Temas similares
» Banco de pruebas para para chess-engines.
» FACIL PARA LOS ENGINES. NO TAN FACIL PARA LOS HUMANOS
» Alex54 para Master
» Elo de programas para consolas de sobremesa
» Perspectivas y prospectiva 2011- 2012 ( II)
» FACIL PARA LOS ENGINES. NO TAN FACIL PARA LOS HUMANOS
» Alex54 para Master
» Elo de programas para consolas de sobremesa
» Perspectivas y prospectiva 2011- 2012 ( II)
Foro SiliconChess - Programas de Ajedrez y Actualidad :: GENERAL, Sobre Ajedrez :: AJEDREZ INFORMATICO (Máxima actualidad de los programas de ajedrez pc windows mac os linux).
Página 1 de 1.
Permisos de este foro:
No puedes responder a temas en este foro.
|
|