Page 1 of 1

An experimental draw recognizer function

Posted: Wed Mar 14, 2012 3:56 pm
by ethanara
Hi
When I was walking around, i got this idea for engines to better recognise whether or not a position is draw due to the 50 move rule. The idea is based on the fact that if you cant get a better position/win material et cetera within 50 moves, the game is a draw. Here it is in pseudo-code (in the search function):

Code: Select all

if position_is_endgame && saved_before_flag == false then
first_eval_in_endgame = score
saved_before_flag = true
first_eval_in_endgame_depth = depth
and later in search, in a further depth

Code: Select all

score = evaluate()
eval_difference = first_eval_in_endgame - score
if saved_before_flag == true && eval_difference > Table[depth_difference] then
return draw
So, it is basically saying that if you or your opponent don't improve your position with x centipawns in y depth, then it is quite surely a draw.
Table should be something like this:

Code: Select all

Table[64] = "5, 7, 10, 13, 15, 17, 20" // and so on....
Of course, if you're over a special margin (1½ pawn or so), it will be completely dumb to do this.
The only problems remaining is having good values in table and a good endgame knowledge.
I will test this with doublecheck
Regards
Ethan

Re: An experimental draw recognizer function

Posted: Wed Mar 14, 2012 4:50 pm
by lucasart
ethanara wrote:Hi

Code: Select all

if position_is_endgame && saved_before_flag == false then
first_eval_in_endgame = score
saved_before_flag = true
first_eval_in_endgame_depth = depth
and later in search, in a further depth

Code: Select all

score = evaluate()
eval_difference = first_eval_in_endgame - score
if saved_before_flag == true && eval_difference > Table[depth_difference] then
return draw
So, it is basically saying that if you or your opponent don't improve your position with x centipawns in y depth, then it is quite surely a draw.
Table should be something like this:

Code: Select all

Table[64] = "5, 7, 10, 13, 15, 17, 20" // and so on....
Of course, if you're over a special margin (1½ pawn or so), it will be completely dumb to do this.
The only problems remaining is having good values in table and a good endgame knowledge.
I will test this with doublecheck
Regards
Ethan
I don't really understand your pseudo-code. Probably better to write real code and test it.

I'm glad someone is playing around with the code of DoubleCheck :D

Don't hesitate to pm me if there is anything in the code that isn't clear. I'm currently doing some non functional code cleanup, mostly adding comments and renaming a few things to make them more self explanatory.

Re: An experimental draw recognizer function

Posted: Thu Mar 15, 2012 3:10 pm
by bob
ethanara wrote:Hi
When I was walking around, i got this idea for engines to better recognise whether or not a position is draw due to the 50 move rule. The idea is based on the fact that if you cant get a better position/win material et cetera within 50 moves, the game is a draw. Here it is in pseudo-code (in the search function):

Code: Select all

if position_is_endgame && saved_before_flag == false then
first_eval_in_endgame = score
saved_before_flag = true
first_eval_in_endgame_depth = depth
and later in search, in a further depth

Code: Select all

score = evaluate()
eval_difference = first_eval_in_endgame - score
if saved_before_flag == true && eval_difference > Table[depth_difference] then
return draw
So, it is basically saying that if you or your opponent don't improve your position with x centipawns in y depth, then it is quite surely a draw.
Table should be something like this:

Code: Select all

Table[64] = "5, 7, 10, 13, 15, 17, 20" // and so on....
Of course, if you're over a special margin (1½ pawn or so), it will be completely dumb to do this.
The only problems remaining is having good values in table and a good endgame knowledge.
I will test this with doublecheck
Regards
Ethan
There are other approaches as well. In Crafty, once we start to approach the 50 move rule, I start to pull the score back toward zero. This makes any sort of move that produces progress to look better if it resets the 50 move counter.

There is a danger, of course. You can try so hard to avoid a draw, that you lose, if your eval is not really accurate.

Re: An experimental draw recognizer function

Posted: Sat Mar 17, 2012 2:30 pm
by diep
Ethan, where you want to apply your code, in root of search or something?
and with 'endgame' you mean, getting to the position with the same material and pawn structure?

Re: An experimental draw recognizer function

Posted: Sat Mar 17, 2012 5:14 pm
by bob
bob wrote:
ethanara wrote:Hi
When I was walking around, i got this idea for engines to better recognise whether or not a position is draw due to the 50 move rule. The idea is based on the fact that if you cant get a better position/win material et cetera within 50 moves, the game is a draw. Here it is in pseudo-code (in the search function):

Code: Select all

if position_is_endgame && saved_before_flag == false then
first_eval_in_endgame = score
saved_before_flag = true
first_eval_in_endgame_depth = depth
and later in search, in a further depth

Code: Select all

score = evaluate()
eval_difference = first_eval_in_endgame - score
if saved_before_flag == true && eval_difference > Table[depth_difference] then
return draw
So, it is basically saying that if you or your opponent don't improve your position with x centipawns in y depth, then it is quite surely a draw.
Table should be something like this:

Code: Select all

Table[64] = "5, 7, 10, 13, 15, 17, 20" // and so on....
Of course, if you're over a special margin (1½ pawn or so), it will be completely dumb to do this.
The only problems remaining is having good values in table and a good endgame knowledge.
I will test this with doublecheck
Regards
Ethan
There are other approaches as well. In Crafty, once we start to approach the 50 move rule, I start to pull the score back toward zero. This makes any sort of move that produces progress to look better if it resets the 50 move counter.

There is a danger, of course. You can try so hard to avoid a draw, that you lose, if your eval is not really accurate.
Someone asked via email, thought I would answer here.

By "eval being accurate" I mean that if your eval says that +0.30 is an advantage, then +0.20 had BETTER be an advantage as well, just not as big. Otherwise, if your eval is biased, the 50-move->draw-score trick will lose games, as 20 moves from 50 you might start to drag that .30 toward zero, and when you drag it far enough, it will become worse than that .20 that resets the 50 counter. That move had better NOT be a losing move...

Re: An experimental draw recognizer function

Posted: Sat Mar 17, 2012 6:00 pm
by ethanara
diep wrote:Ethan, where you want to apply your code, in root of search or something?
and with 'endgame' you mean, getting to the position with the same material and pawn structure?
I dont think it's a good idea to use it at root, because it does not matter if it is drawn or won right now, you just have to play the best moves.
What i suggest is that you use it in later search, to avoid going into a drawn endgame position.
With endgame i mean that both sides totally have x centipawns material. I still have to find a good value, but i think under a queen would be sufficient.