Check extension vs LMR

[MikeB]

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?

I think most keep it pretty simple -, taking Crafty for example, Crafty had different values for Knights and Bishops in addition to all kinds of bonuses and penalties for different situations depending on the board - but for SEE it treated bishops and knights as the same value as long SEE was >=0 , it extended.

[cdani]

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?

I think most keep it pretty simple -, taking Crafty for example, Crafty had different values for Knights and Bishops in addition to all kinds of bonuses and penalties for different situations depending on the board - but for SEE it treated bishops and knights as the same value as long SEE was >=0 , it extended.

Yes, SEE is about material, not about positional values of pieces. And between top engines SEE seems to be conceptually almost equal.

[Evert]

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?

It's not.
Such nuances are not dealt with. SEE is used to evaluate the merit of captures/exchanges on the observation that losing any type of material will normally cost you the game, so moves that lose material can normally be reduced or pruned.
Trading your good knight for a bad bishop is not handled in SEE, but should result in a score drop after the moves have been made.

As far as tuning goes, I think SEE is one of the few examples where there is nothing to tune, really.

[Michel]

As far as tuning goes, I think SEE is one of the few examples where there is nothing to tune, really.

There are no continuous parameters to be tuned. But SEE is expensive and it makes sense to try to truncate it to speed up things. This is something that could be tunable. I recall that somebody at fishtest experimented with this, but it was elo neutral and therefore rejected (although it was a simplification in terms of LOC).

[nionita]

...

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.

SEE alone worked. But combined with LMR for extended moves, did not bring anything.

[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.

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.

I usually do that in the daughter node, because that is where I need the information about the check (the checker and check ray, and whether is is a double check), for running a specific evasion generator.

BTW, it is not that problematic to share lots of data between a node and its children. In my latest engine I use a 'StairWell' struct, defined as a local variable in the parent, passing a pointer to it to all daughters. The pointer then is basically the only thing you have to pass; all other stuff you want to pass then can simply be assigned to fields in the struct. Other fields can be used to return stuff from the daughters (such as the best move and result depth).

[hgm]

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.

Are you talking here about using SEE to select checks for extension, or for sorting moves? These are quite different things. It is hard for me to believe that handling checks could make such a large difference in tree size. Checks are not that common in the tree, during most of the game.

In micro-Max I found that check extension in the end-game was counter-productive: checking then becomes always possible, and is usually a waste of time. The check extension would make the search focus on these pointless chases, at the expense of the useful lines. So micro-Max switches off check extension at the same point where it switches off King Safety. If I did not do that, I saw no improvement from check extension.

Have you tested if deciding about check extension really requires See, or that it would work ass well to only ctest if the target square is attacked by an enemy lower or equal piece (which would exclude SEE > 0)?

[nionita]

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.

Are you talking here about using SEE to select checks for extension, or for sorting moves? These are quite different things. It is hard for me to believe that handling checks could make such a large difference in tree size. Checks are not that common in the tree, during most of the game.

In micro-Max I found that check extension in the end-game was counter-productive: checking then becomes always possible, and is usually a waste of time. The check extension would make the search focus on these pointless chases, at the expense of the useful lines. So micro-Max switches off check extension at the same point where it switches off King Safety. If I did not do that, I saw no improvement from check extension.

Have you tested if deciding about check extension really requires See, or that it would work ass well to only ctest if the target square is attacked by an enemy lower or equal piece (which would exclude SEE > 0)?

Excellent point, this one with (no) check extension in end game. I will try this one for sure.

I will also try a simplified test to extend only checks that are on a secure square. This all will take a while though.

[hgm]

I never tried the latter, because I very much doubt that it has enough generality. If you look at a Crazyhouse or Shogi game, for example, it is full of checks on unsafe squares. Usually to lure away pieces that prevent check drops elsewhere.

It is of course a good idea to distinguish checks that achieve something from those that just cause pointless delay at the expense of material. But it seems to require more sophistication thenjust calculating the SEE.

[nionita]

I never tried the latter, because I very much doubt that it has enough generality. If you look at a Crazyhouse or Shogi game, for example, it is full of checks on unsafe squares. Usually to lure away pieces that prevent check drops elsewhere.

It is of course a good idea to distinguish checks that achieve something from those that just cause pointless delay at the expense of material. But it seems to require more sophistication thenjust calculating the SEE.

Actually the condition I tried was:
- if the current move checks
- and the move is double check OR the move has SEE >= 0
- then extend 1 ply

The SEE test has short circuits for the case that the capturing piece is a less valuable one and in this case the function is not (so) expensive.

Anyway what I wanted to point out is that:

1. Doing this test for all checks seems to be less efficient than extending all checks and allowing LMR even for extended moves

2. Doing both is worse than doing just the LMR/extension part (from my current tests: at most 0 Elo, with 95%)