Check extension vs LMR

[hgm]

I always adhered to the common wisdom that one should not apply LMR reductions to moves that you would extend, without giving it much thought. So when I am doing check extension, it cancels LMR.

But now I realize there is a catch, because I really used to extend the check evasions, rather than the checks. That is, when a node finds the stm in check, it increases the requested depth by 1. In the end the result is the same, the branches reach 1 ply deeper, and it does not matter where along them the extesion was awarded.

But nowadays I typically apply LMR of moves 'after the fact', that is, I first make the move, informing the daughter node it is a late move, and then leave it up to the daughter to decide about the reduction. The daughter would figure out if the stm is in check anyway, so it saves me the trouble of throwing an extra test on every move in the parent, to see if it delivers check.

But this is equivalent to exempting checking moves from LMR, and not the evasions. So some of the check evasions (in particular the King withdrawals and the interpositions) will be qualified as 'late', and will be reduced. This somehow feels wrong; I don't see any reason why these 'silent' evasions would on average have less chance to be good, or would need less depth to pove their worth as capturing the checker. Often it is the opposite: when the check was unsafe, and can be refuted by gobbling up the checker, it is usually obvious at very low depth. And if the check was safe, you are completely dependent on late moves for evasions. Normal killers or history moves are not likely to work in an in-check position.

How do other engines do this? Do they exempt checking moves from LMR, or all check evasions? Or perhaps both?

[jdart]

Funny you should post this now - I have just tested a change that applies LMR to some evasions and it had a positive ELO gain. One reason may be that the first evasion is pretty often either a hash hit (so it was best in some previous visit) or a good capture (which get sorted first), so the late moves in both these cases are likely to be less good. But there will certainly be positions where that is not true.

--Jon

[cdani]

How do other engines do this? Do they exempt checking moves from LMR, or all check evasions? Or perhaps both?

I do LMR, which I reduce by one if there is check extension. There is check extension if the SEE of the checking move is not negative.

Also I don't prune the move if is check.

I have just tested a change that applies LMR to some evasions and it had a positive ELO gain.

Yes, this works.

[bob]

Probably a deeper topic than most of us will imagine. My thinking has always been "KISS". In Cray Blitz, I extended on the evasion. But in Crafty, I extend on the checking move itself. I never considered the idea of extending a checking move then reducing the evasions as particularly reasonable. I experimented with the inverse, not extending the check, then extending (or even reducing) the evasions. But it was more complicated and didn't seem to affect results when testing.

There's probably dozens of different approaches. Perhaps all the way to eliminating extensions completely (I have already removed all but check extensions as it stands today). Probably could all be collapsed into the LMR code which is something I might try.

[lucasart]

I always adhered to the common wisdom that one should not apply LMR reductions to moves that you would extend, without giving it much thought. So when I am doing check extension, it cancels LMR.

But now I realize there is a catch, because I really used to extend the check evasions, rather than the checks. That is, when a node finds the stm in check, it increases the requested depth by 1. In the end the result is the same, the branches reach 1 ply deeper, and it does not matter where along them the extesion was awarded.

But nowadays I typically apply LMR of moves 'after the fact', that is, I first make the move, informing the daughter node it is a late move, and then leave it up to the daughter to decide about the reduction. The daughter would figure out if the stm is in check anyway, so it saves me the trouble of throwing an extra test on every move in the parent, to see if it delivers check.

But this is equivalent to exempting checking moves from LMR, and not the evasions. So some of the check evasions (in particular the King withdrawals and the interpositions) will be qualified as 'late', and will be reduced. This somehow feels wrong; I don't see any reason why these 'silent' evasions would on average have less chance to be good, or would need less depth to pove their worth as capturing the checker. Often it is the opposite: when the check was unsafe, and can be refuted by gobbling up the checker, it is usually obvious at very low depth. And if the check was safe, you are completely dependent on late moves for evasions. Normal killers or history moves are not likely to work in an in-check position.

How do other engines do this? Do they exempt checking moves from LMR, or all check evasions? Or perhaps both?

What I can say from experience (ie. proper testing, not theoretical arguments) is this:
- extending all checks hurts elo.
- extending SEE >= 0 checks is good.
- that's why you should do it in the parent node, not in the child node, unless you want a messy code-base, with parent node lookup in a search stack.
- not reducing checks hurts elo. yes, you should combine reductions and extensions, rather than use extension to prevent reduction, or you get a double whammy cost.

In broad terms, I (or rather my test results) agree with Daniel Jose. But the devil is in the details. Testing is the only answer. The rest is hand-waving at best.

[hgm]

It is not clear to me what you are saying. The parent node (from where the checking move is made) would not know that the move delivers check. This will become only apparent in the daughter node. This is why the decision to extend or not is taken in the node that generates the evasions. The question is really whether I should distinguish evasions into early and late evasions, or whether I should search any evasion to the same depth.

[cdani]

It is not clear to me what you are saying. The parent node (from where the checking move is made) would not know that the move delivers check. This will become only apparent in the daughter node. This is why the decision to extend or not is taken in the node that generates the evasions. The question is really whether I should distinguish evasions into early and late evasions, or whether I should search any evasion to the same depth.

Not really. In Andscacs I know that the move is a checking one in the parent node. And is the same for Stockfish and sure others.

[nionita]

I always adhered to the common wisdom that one should not apply LMR reductions to moves that you would extend, without giving it much thought. So when I am doing check extension, it cancels LMR.

But now I realize there is a catch, because I really used to extend the check evasions, rather than the checks. That is, when a node finds the stm in check, it increases the requested depth by 1. In the end the result is the same, the branches reach 1 ply deeper, and it does not matter where along them the extesion was awarded.

But nowadays I typically apply LMR of moves 'after the fact', that is, I first make the move, informing the daughter node it is a late move, and then leave it up to the daughter to decide about the reduction. The daughter would figure out if the stm is in check anyway, so it saves me the trouble of throwing an extra test on every move in the parent, to see if it delivers check.

But this is equivalent to exempting checking moves from LMR, and not the evasions. So some of the check evasions (in particular the King withdrawals and the interpositions) will be qualified as 'late', and will be reduced. This somehow feels wrong; I don't see any reason why these 'silent' evasions would on average have less chance to be good, or would need less depth to pove their worth as capturing the checker. Often it is the opposite: when the check was unsafe, and can be refuted by gobbling up the checker, it is usually obvious at very low depth. And if the check was safe, you are completely dependent on late moves for evasions. Normal killers or history moves are not likely to work in an in-check position.

How do other engines do this? Do they exempt checking moves from LMR, or all check evasions? Or perhaps both?

What I can say from experience (ie. proper testing, not theoretical arguments) is this:
- extending all checks hurts elo.
- extending SEE >= 0 checks is good.
- that's why you should do it in the parent node, not in the child node, unless you want a messy code-base, with parent node lookup in a search stack.
- not reducing checks hurts elo. yes, you should combine reductions and extensions, rather than use extension to prevent reduction, or you get a double whammy cost.

In broad terms, I (or rather my test results) agree with Daniel Jose. But the devil is in the details. Testing is the only answer. The rest is hand-waving at best.

After this discussion I implemented 2 branches in Barbarossa (in which I until then extended all checks and did not reduce late extended moves):
- version one: LMR also for extended moves (aka checks)
- version two: extend only checks with SEE >= 0

Both were winner: one won 18 Elo (+- 6), two won 8 Elo (+- 6).

But when I combined them, there was no win at all (but a regression is very very probable, final Elo is not clear yet).

Every engine is different, but at least in my case, it looks like the SEE effort for checks does not pay out.

[MikeB]

...

After this discussion I implemented 2 branches in Barbarossa (in which I until then extended all checks and did not reduce late extended moves):
- version one: LMR also for extended moves (aka checks)
- version two: extend only checks with SEE >= 0

Both were winner: one won 18 Elo (+- 6), two won 8 Elo (+- 6).

But when I combined them, there was no win at all (but a regression is very very probable, final Elo is not clear yet).

Every engine is different, but at least in my case, it looks like the SEE effort for checks does not pay out.

For SEE not to work out is very unusual , I have tried removing the SEE test from many engines and it is always better with SEE. Every engine is different, but would suggest double checking your implementation. Without SEE, the search blows up eventually. A built in bench command will see a fairly dramatic pickup (20-25%) in the nodes per depth without SEE and that is what causes the ELO reduction.

Edit: Rethinking this - it may not be 20-25%, but even if it 10%, I believe it will hurt ELO. Not sure of the % now but you can test.

[jorose]

I have been very hesitant with implementing SEE, especially as how I understand it it probably has to be tuned somehow to work with the evaluation function? The value of piece extremely variable, ie SEE has to deal with active bishops and passive bishops, knights on a8 and knights on d4, is this typically dealt with in SEE implementations?

When reading about SEE it just seems so arbitrary to me. Do SEE implementations vary greatly between the top engines?