An experimental draw recognizer function

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
ethanara
Posts: 134
Joined: Mon May 16, 2011 4:58 pm
Location: Denmark
Contact:

An experimental draw recognizer function

Post by ethanara » Wed Mar 14, 2012 2:56 pm

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

User avatar
lucasart
Posts: 3196
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: An experimental draw recognizer function

Post by lucasart » Wed Mar 14, 2012 3:50 pm

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.

bob
Posts: 20923
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: An experimental draw recognizer function

Post by bob » Thu Mar 15, 2012 2:10 pm

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.

diep
Posts: 1786
Joined: Thu Mar 09, 2006 10:54 pm
Location: The Netherlands
Contact:

Re: An experimental draw recognizer function

Post by diep » Sat Mar 17, 2012 1:30 pm

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?

bob
Posts: 20923
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: An experimental draw recognizer function

Post by bob » Sat Mar 17, 2012 4:14 pm

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...

ethanara
Posts: 134
Joined: Mon May 16, 2011 4:58 pm
Location: Denmark
Contact:

Re: An experimental draw recognizer function

Post by ethanara » Sat Mar 17, 2012 5:00 pm

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.

Post Reply