Managing draws in the tree search

[smcracraft]

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.

[mar]

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?

[smcracraft]

Well, as I recall, Bob Hyatt did something with the draw score and appeared to have a good reason.

[jdart]

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

[pijl]

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.

[Ferdy]

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

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 .

But so could a balanced position be 0.

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.

Anyway, if folks could talk about how they implemented draws, that's usually the best way to proceed and I appreciate it.

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.

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