Author: martin fierz
Date: 15:36:52 04/04/02
Go up one level in this thread
On April 04, 2002 at 03:05:30, Alvaro Jose Povoa Cardoso wrote:
>Hi Martin,
>I red the Chinook team article on EGTB ("Solving Large Retrograde Analysis
>Problems").
>In my mind I was picturing an EGTB entry as a byte with 2 bits for position
>classification (win, loss, draw, unkown) and 6 bits for a distance to win/loss
>metric.
>But in the article they mention the use of only 2 bits, leaving out the distance
>to win/loss information.
>My question is: using only 2 bits how can the engine make progress?
>How can he find the shortest win or the longest loss without those 6 bits of
>information?
>
>Best regards,
>Alvaro Cardoso
good question! chinook (and most checkers programs, with one exception) only
save the win/loss/draw information in their database to save space. so once they
are in a winning position, they will see lots of winning variations, but are in
danger of just repeating moves.
the solution is to use a value scheme about like this:
[-MATE,...,database losses,...,really bad position,0,..,database wins, MATE].
this ensures that the program will go for a mate when it has the choice of mate
or database win. the section "database losses" is not one value, but also a
section of many values. here, you can use a simple evaluation function to
evaluate the position you know is winning. like this, the program will for
instance rather take a database win with 1 piece up than a database win with
equal number of pieces. it will rather take a win in the 6-piece database than
one in the 8-piece database. it will go and advance men and crown them to kings.
and it will occupy the center with it's kings and restrict the mobility of the
opponents pieces. all this while it still stays in the database win. like this,
under normal circumstances, you will be able to win any winning position. the
deeper you can search, the greater the probability of finding a conversion to a
smaller database gets. this technique will eventually find a win, given enough
time. but i do not doubt that you can find positions which my program can not
solve on low levels/slow computers!
aloha
martin
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.