check extension

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
AndrewShort

check extension

Post by AndrewShort » Thu Aug 07, 2008 3:23 pm

when people talk of "check extensions", are they referring to:

(a) Quies() considers all checking moves and check evasion moves (in addition to captures, promotions). This implies that Quies must account for draw by repetition, since perpetual check could result, putting Quies in an infinite loop...

or do they mean

(b) the main search is expanded one full ply if side to move is in check

or do the mean

(c) both (a) and (b) above

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

Re: check extension

Post by bob » Thu Aug 07, 2008 4:11 pm

AndrewShort wrote:when people talk of "check extensions", are they referring to:

(a) Quies() considers all checking moves and check evasion moves (in addition to captures, promotions). This implies that Quies must account for draw by repetition, since perpetual check could result, putting Quies in an infinite loop...

or do they mean

(b) the main search is expanded one full ply if side to move is in check

or do the mean

(c) both (a) and (b) above
(b) although the "one full ply" is not an absolute...

AndrewShort

Re: check extension

Post by AndrewShort » Thu Aug 07, 2008 7:13 pm

but if you don't do (a), isn't your static eval grossly inaccurate? A player might be in check, and thus in mating danger, but the static eval wouldn't know it, thinking the position was quiescent, when it really isn't...

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

Re: check extension

Post by bob » Thu Aug 07, 2008 7:16 pm

AndrewShort wrote:but if you don't do (a), isn't your static eval grossly inaccurate? A player might be in check, and thus in mating danger, but the static eval wouldn't know it, thinking the position was quiescent, when it really isn't...
The idea, at least in the case of crafty, prevents that to an extent. In Crafty, I extend when I give check, which means that when a path goes from normal search to call Quiesce() it will _never_ be in check at the first ply of the q-search, because for that to happen the search would not have extended the check, something that can't happen. Once in the search, yes things could have some inaccuracy since a capture move can also be a checking move. But the q-search is already horribly inaccurate since it only considers captures anyway, so the effect seems to be something that can be ignored.

Uri Blass
Posts: 8036
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

Re: check extension

Post by Uri Blass » Thu Aug 07, 2008 8:41 pm

AndrewShort wrote:but if you don't do (a), isn't your static eval grossly inaccurate? A player might be in check, and thus in mating danger, but the static eval wouldn't know it, thinking the position was quiescent, when it really isn't...
I think that most programmers of top programs(including glaurung and fruit) do both a and b but only b is considered to be a check extension.

Uri

AndrewShort

Re: check extension

Post by AndrewShort » Fri Aug 08, 2008 4:33 pm

Can someone explain to me how the check extension works? If before you call Quies the side to move is in check, you expand that particular path one more ply, then call Quies, so that Quies is never called with the side to move in check.

That does not make sense to me, as it would only search 1 ply deeper along that path, while the actual mating sequence might consist of 3 or 4 checks deeper. I thought the whole idea of check extension is to exhaust a particular main path along a checking line, if any, then go into Quies. But to expand 1 ply would not exhaust the checking line.

Unless the path is expanded by check evasions as well...

thanks in advance for clearing my head on this...

Aleks Peshkov
Posts: 845
Joined: Sun Nov 19, 2006 8:16 pm
Location: Russia

Re: check extension

Post by Aleks Peshkov » Fri Aug 08, 2008 4:42 pm

Check extension is a modest reshaping of the search tree. The idea of extensions is to weaken pushing dangerous variations above search horizon with useless temporary delaying moves.

Real checkmates are to rare to worry about except artificial tactical test suits.

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

Re: check extension

Post by bob » Fri Aug 08, 2008 6:19 pm

AndrewShort wrote:Can someone explain to me how the check extension works? If before you call Quies the side to move is in check, you expand that particular path one more ply, then call Quies, so that Quies is never called with the side to move in check.

That does not make sense to me, as it would only search 1 ply deeper along that path, while the actual mating sequence might consist of 3 or 4 checks deeper. I thought the whole idea of check extension is to exhaust a particular main path along a checking line, if any, then go into Quies. But to expand 1 ply would not exhaust the checking line.

Unless the path is expanded by check evasions as well...

thanks in advance for clearing my head on this...
At any normal node (not in q-search) if I make a move that gives check to the opponent, I increment depth by one ply. Not just at nodes close to the q-search horizon, but anywhere.

AndrewShort

Re: check extension

Post by AndrewShort » Fri Aug 08, 2008 6:53 pm

ahhh, I see. I didn't realize that.

So if you happen to come across 4 checking moves in a main search path, the path is extended 4 ply. The checking moves are not necessarily every 2 plies - it could skip some plies, and also some checks are evaded by another check. And since you always extend one more ply when you see a check, that guarantees Quies will never start in check.

AndrewShort

Re: check extension

Post by AndrewShort » Sat Aug 09, 2008 3:16 am

still, though, as Aleks points out, check extensions do not exhaust a possible checking line. If there was only 1 check in the main search path, say, at the end, then the path is only extended 1 ply, where the opponent gets to evade the check.

Shouldn't the path be extended even further to see if the checking line can be continued - it could lead to mate. ?

or is that more for solving mating puzzles, as Aleks points out?

Post Reply