A couple of questions.
Currently my program is not good with draw handling.
For example, a draw is 0 and gets set when the position repetition count
is greater than 2
But so could a balanced position be 0.
So I am curious how best to differentiate the two and how best to ensure
that once the draw is seen, somehow that branch gets a draw-flag set for it only and all search returns. But then there's the question of scoring the draw which might be disadvantageous given the position.
Anyway, if folks could talk about how they implemented draws, that's usually the best way to proceed and I appreciate it.
Managing draws in the tree search
Moderators: hgm, Rebel, chrisw
-
- Posts: 737
- Joined: Wed Mar 08, 2006 8:08 pm
- Location: Orange County California
- Full name: Stuart Cracraft
-
- Posts: 2559
- Joined: Fri Nov 26, 2010 2:00 pm
- Location: Czech Republic
- Full name: Martin Sedlak
Re: Managing draws in the tree search
I'm not differentiating draws.
Also I think the probability to get balanced position with 0 seems very unlikely to get (if we ignore draw by material or eg recognizers).
I don't see why this should be a problem in the first place?
Also I think the probability to get balanced position with 0 seems very unlikely to get (if we ignore draw by material or eg recognizers).
I don't see why this should be a problem in the first place?
-
- Posts: 737
- Joined: Wed Mar 08, 2006 8:08 pm
- Location: Orange County California
- Full name: Stuart Cracraft
Re: Managing draws in the tree search
Well, as I recall, Bob Hyatt did something with the draw score and appeared to have a good reason.
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: Managing draws in the tree search
Couple of things:
1. I set an "exact" flag when the search returns an exact score. Cases in which this happens include a tablebase hit, and legal draw situations. This enables some optimizations. For example you never need to re-search a node with this flag set, even if ordinarily you would do so, such as after LMR.
2. If running on a chess server where I can know the opponent's rating, I apply a correction to the draw score so that it will avoid draws against lower-rated opponents, and accept draws against higher-rated opponents. This does not work under UCI, however. The "rating" command is only sent to Winboard-protocol engines.
--Jon
1. I set an "exact" flag when the search returns an exact score. Cases in which this happens include a tablebase hit, and legal draw situations. This enables some optimizations. For example you never need to re-search a node with this flag set, even if ordinarily you would do so, such as after LMR.
2. If running on a chess server where I can know the opponent's rating, I apply a correction to the draw score so that it will avoid draws against lower-rated opponents, and accept draws against higher-rated opponents. This does not work under UCI, however. The "rating" command is only sent to Winboard-protocol engines.
--Jon
-
- Posts: 115
- Joined: Mon Sep 17, 2012 8:59 pm
Re: Managing draws in the tree search
The reason as to why you would like to recognize path dependent draws (so not stalemate) separately is because it has a potential to mess up the hashtable. I guess you should not use them until they've been propagated a few (2?) plies towards the root, and then we get back to the original question of the thread.
I know Vincent Diepeveen made a study of this. Perhaps if he still visits this forum he could comment on this.
As to what I'm doing: I just do not store draws in the hashtable when they're detected, but I have no special mechanism to avoid propagation of bogus draw scores.
I know Vincent Diepeveen made a study of this. Perhaps if he still visits this forum he could comment on this.
As to what I'm doing: I just do not store draws in the hashtable when they're detected, but I have no special mechanism to avoid propagation of bogus draw scores.
-
- Posts: 4833
- Joined: Sun Aug 10, 2008 3:15 pm
- Location: Philippines
Re: Managing draws in the tree search
Generally it is fine because 3 same positions can be claimed as a draw. But in engine this is tricky. There are times that your engine may think that the position can be repeated 2x and consider it to be the best line because of the way your engine searches, but actually it is not true for the other engine because the other engine would choose a different path (that your engine did not see) avoiding the repetition that your engine has seen to be the best line. This is common when playing against a superior opponent. The best way to solve such problem is to make the engine stronger .smcracraft wrote:A couple of questions.
Currently my program is not good with draw handling.
For example, a draw is 0 and gets set when the position repetition count
is greater than 2
There are two simple cases of balanced positions one with less pieces and with more pieces. With less pieces there is high probability that a position can be safely scored as zero. With more pieces remaining on the board it is a different story.smcracraft wrote: But so could a balanced position be 0.
I created options for those type of scoring except the zero score from the eval, this would allow the user more freedom to experiment and to possibly come up with the best behaviour of the engine.smcracraft wrote: Anyway, if folks could talk about how they implemented draws, that's usually the best way to proceed and I appreciate it.
Code: Select all
option name RepetitionScore type spin default 0 min -500 max 500
option name InsufficientMaterialScore type spin default 0 min -500 max 500
option name FiftyMoveScore type spin default 0 min -500 max 500
option name StaleMateScore type spin default 0 min -30000 max 30000