draw detection ?

Discussion of chess software programming and technical issues.

Moderator: Ras

MahmoudUthman
Posts: 237
Joined: Sat Jan 17, 2015 11:54 pm

draw detection ?

Post by MahmoudUthman »

*Should the evaluation include draw "insufficient material" detection ?
*I can't find insufficient material detection in SF's search , is it not there ? or am I missing something ?
*Should I check for draw by repetition in quiescence search , or is it not worth it ?
*Is it worth it to include the heuristics mentioned here & here ?
User avatar
hgm
Posts: 28473
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: draw detection ?

Post by hgm »

Advanced engines usually keep a 'material key', used to access a table (hashed or exhaustive) that contains information for evaluating the position. This can be as simple as a fixed score correction in centi-Pawn (e.g. to account for the Bishop pair). Or it can be a multiplication factor to be applied to any 'naive advantage' for black or white. And it can be as complex as a pointer to a special evaluation routine, which would evaluate the position based on the actual location of the pieces (e.g. for KBPK or KPK).

In such a framework a draw by insufficient material could be given a factor 0. Note that you could still make a distinction between only affecting the evaluation (but continuing the search as normal, using that evaluation), or returning the evaluation without further search, no matter how deep a search was requested. E.g. KBK should be evaluated as 0, and the score will obviously always stay 0, so further search is pointless.

A simple implementation would be to have an 8-bit code for every material combination, which would mostly be used as a score correction to the 'naive' evaluation (e.g. for values N = 0-200, by adding N - 100). For values above 200 (which only a few late-endgame material combinations would have) it could the be passed to a routine that would be called instead of the normal evaluation to figure out what should be done (possibly calling the normal evaluation and multiply it with a factor), and would also return a flag to indicate whether this should abort the search of the current branch. This would cause pracically zero overhead in positions that do not need special treatment.

The Elo gain from knowing which end-games are drawish will not be shocking, but it will also not be negligible. And even mistakes that cost very little Elo are very noticeable (e.g. trading your last Pawn in KBNPKNP).
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: draw detection ?

Post by Evert »

MahmoudUthman wrote:*Should the evaluation include draw "insufficient material" detection ?
Depends what you mean by "insufficient material", but in general yes. Things like KK, KNK and KBK you could detect in search to prevent the engine from wasting time shuffling pieces in those positions.
*Should I check for draw by repetition in quiescence search , or is it not worth it ?
That's a waste of time. You cannot get repetitions during quiescence search.
*Is it worth it to include the heuristics mentioned here & here ?
Depends. For playing strength? Probably not. For analysis/solving problems? Sure.
User avatar
hgm
Posts: 28473
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: draw detection ?

Post by hgm »

Evert wrote:That's a waste of time. You cannot get repetitions during quiescence search.
You can when you also search non-capture checks. (Or in Crazyhouse...)
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: draw detection ?

Post by Evert »

hgm wrote:
Evert wrote:That's a waste of time. You cannot get repetitions during quiescence search.
You can when you also search non-capture checks.
Yes, that is true. However, if you just do that on the first ply, it probably doesn't matter either way.
(Or in Crazyhouse...)
Obviously.
MahmoudUthman
Posts: 237
Joined: Sat Jan 17, 2015 11:54 pm

Re: draw detection ?

Post by MahmoudUthman »

hgm wrote: A simple implementation would be to have an 8-bit code for every material combination, which would mostly be used as a score correction to the 'naive' evaluation (e.g. for values N = 0-200, by adding N - 100). For values above 200 (which only a few late-endgame material combinations would have) it could the be passed to a routine that would be called instead of the normal evaluation to figure out what should be done (possibly calling the normal evaluation and multiply it with a factor), and would also return a flag to indicate whether this should abort the search of the current branch. This would cause pracically zero overhead in positions that do not need special treatment.
I don't understand this part could you please elaborate more ? also what do you mean by naïve advantage ?
Evert wrote:Yes, that is true. However, if you just do that on the first ply, it probably doesn't matter either way.
I don't understand this , by first ply do you mean non capture/promotion evasions or repetition detection ? and if it's the second case why wouldn't it matter ?
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: draw detection ?

Post by Evert »

MahmoudUthman wrote:
Evert wrote:Yes, that is true. However, if you just do that on the first ply, it probably doesn't matter either way.
I don't understand this , by first ply do you mean non capture/promotion evasions or repetition detection ? and if it's the second case why wouldn't it matter ?
I meant including checking moves in addition to winning captures during the first ply of quiescence. That checking move and its evasion are the only cases where you could get a repetition. This happens under a specific set of circumstances that I suspect is rare in practice. The first repetition is not a draw anyway (searching it is a waste of time, but not a big waste if it is rare) and the test is not free.

Dealing with repetitions at the start of quiescence is really part of the horizon effect, and the solution is to search deeper, which will happen naturally on the next iteration.
User avatar
hgm
Posts: 28473
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: draw detection ?

Post by hgm »

MahmoudUthman wrote:I don't understand this part could you please elaborate more ? also what do you mean by naïve advantage ?
With 'naive advatage' I mean the normal evaluation based on piece values. So in KNKP you would have a naive advantage of +225, while of course your winning chances are zero, and you could in fact be totally lost.

As to the material key you can for instace set (white) N=1, B=3, R=9, Q=27, P=54, and for black all values 3*3*3*2*8times as large. Then adding the value for all pieces gives you a unique signature for the material combination, which you would use as an index in a table to find what special things you have to do to evaluate the position. The material key is easily updated incrementally; you only has to subtract the weight of the piece that gets captured, or replace a Pawn by aother on a promotion.