fulitiy + lmr; funny results

[Mangar]

Hi,

like many chess engines we reduce late moves in the last plys of search. If there is only few plys left to search they could be pruned instead of a shallow search. I thiks this was first done by Toga.

I a game I found a bad effect. In an endgame there was only one move to hold draw and may other loosing moves. As the position was near leaf the drawish move was pruned and the position was decided a loss. As eval knew the rule it was funny that eval knew it was draw and search found a loss.

Thus I tried the following rule:
If inner_node_eval is > Alpha - Margin then try more moves before pruning. First thing I discovered is that the search depth increases a little (decrease was expected). Second is loses several elos and got far worse on tactical positions tests.

Any body else tried to reduce the amount of pruned moves in lmr because of current eval? I know value based pruning done in stockfish that does not help or harm in Spike. I can´t imagine why searching more moves in positions with eval >= alpha - margin leads to less tactical force at same serach depth.

I have tools to browse throuh our search tree. Thus I know that it works, more moves has been searched. I compared a few amount of serach trees to see why the additional moves searched harm. The answer I found was the move ordering. The tactical move to find was allways orderd much later by history tables and thus found later.

Any ideas or tests?

Greetings Volker

[Engin]

if i am not missunderstand stockfish it not pruning connected moves never, i dont have implement connected moves and prune those move too, its makes not much effects in tactical thought, but i do the reduced move count prune much later then, and by the LMR i dont reduce for the first 3 moves more then one ply, because of tactical risk.

[mcostalba]

Any body else tried to reduce the amount of pruned moves in lmr because of current eval?

Yes, we have tried very hard to throw "distance from beta" in the LMR reduction formula, because it seems (at least to me) a very natural thing to do.

Currently LMR reductions in Stockfish are based on depth and on the move count (distance from first move). It seems very naturally to add a third parameter "distance from beta" so that positions where evaluation is above beta are reduced less then positions well below beta. Interestingly and somewhat surprisingly, although the big efforts we did in this direction, we were unable to get an ELO increase so that at the moment we stay with current 2 LMR parameters: depth and move count

I really don't know why eval score doesn't seem to work with LMR

[Mangar]

Yes, we have tried very hard to throw "distance from beta" in the LMR reduction formula, because it seems (at least to me) a very natural thing to do.

Currently LMR reductions in Stockfish are based on depth and on the move count (distance from first move). It seems very naturally to add a third parameter "distance from beta" so that positions where evaluation is above beta are reduced less then positions well below beta. Interestingly and somewhat surprisingly, although the big efforts we did in this direction, we were unable to get an ELO increase so that at the moment we stay with current 2 LMR parameters: depth and move count

I really don't know why eval score doesn't seem to work with LMR

Hi,

thanks for that reply. At least I don´t feel stupid any longer

The lmr has several misterious effects. For example I gain some elo if I count illegal moves of pinned pieces instead of ignoring them for move count.

Maybe a problem with allready reduced move. There might be a cut node that if fails low leads to a research of an allready reduced move. Maybe then the rule: if the "usual" good moves doesn´t work for this cut node reasearch the hole part of the tree. There might be some tactical issues.
One thing I´ll try is to use the "beta-parameter" only on not reduced positions or at positions where searching more moves could only lead to a research of an earlier reduction.

Greetings Volker

[mcostalba]

The lmr has several misterious effects. For example I gain some elo if I count illegal moves of pinned pieces instead of ignoring them for move count.

This could be an hint that your movecount rule is a bit too shy and you could push it a bit more....just a guess

[Ferdy]

I can´t imagine why searching more moves in positions with eval >= alpha - margin leads to less tactical force at same serach depth.

How about adding another condition eval < 2*QUEEN_VALUE, the point being why would you try to search more moves when you are probably already winning.

I don't reduce and prune in ending without rooks. I also need to improve my eval to adapt inner nodes position evaluation.

For lmr, I guess the current eval has less influence on move being reduced. Individual moves have different impacts on the positions. It is the move not the current eval that determines the future of positions, because even if the current eval is good and yet the next move made is bad, everything is ruined.

[bob]

Hi,

like many chess engines we reduce late moves in the last plys of search. If there is only few plys left to search they could be pruned instead of a shallow search. I thiks this was first done by Toga.

I think Kent did it first. Then Heinz explained an extension to the idea in Dark Thought. It has been around forever.

I a game I found a bad effect. In an endgame there was only one move to hold draw and may other loosing moves. As the position was near leaf the drawish move was pruned and the position was decided a loss. As eval knew the rule it was funny that eval knew it was draw and search found a loss.

Thus I tried the following rule:
If inner_node_eval is > Alpha - Margin then try more moves before pruning. First thing I discovered is that the search depth increases a little (decrease was expected). Second is loses several elos and got far worse on tactical positions tests.

Any body else tried to reduce the amount of pruned moves in lmr because of current eval? I know value based pruning done in stockfish that does not help or harm in Spike. I can´t imagine why searching more moves in positions with eval >= alpha - margin leads to less tactical force at same serach depth.

I have tools to browse throuh our search tree. Thus I know that it works, more moves has been searched. I compared a few amount of serach trees to see why the additional moves searched harm. The answer I found was the move ordering. The tactical move to find was allways orderd much later by history tables and thus found later.

Any ideas or tests?

Greetings Volker

There are two issues. Reaching extreme depth. Making fewer mistakes. If you are not careful, changing one changes the other. Sometimes hurting, sometimes helping. If you fix a position that you find, you likely hurt many more you didn't know about. That is why testing in real games (and lots of them) is so important...

[Uri Blass]

Any body else tried to reduce the amount of pruned moves in lmr because of current eval?

Yes, we have tried very hard to throw "distance from beta" in the LMR reduction formula, because it seems (at least to me) a very natural thing to do.

Currently LMR reductions in Stockfish are based on depth and on the move count (distance from first move). It seems very naturally to add a third parameter "distance from beta" so that positions where evaluation is above beta are reduced less then positions well below beta. Interestingly and somewhat surprisingly, although the big efforts we did in this direction, we were unable to get an ELO increase so that at the moment we stay with current 2 LMR parameters: depth and move count

I really don't know why eval score doesn't seem to work with LMR

I wonder if you tried distance from 0 instead of distance from beta.
The idea is to have more stable rule of reductions because if you use distance from beta you may reduce lines in iteration x and do not reduce them in iteration x+1.