Late move reductions ?

[MahmoudUthman]

I tried it in non PV nodes reducing only quiet moves "castling excluded" & depth >2, using a reduction of 1 and I almost got no improvement "for example in the starting position ~-1second at depth 13 which takes ~16s without it" , I also tried it not reducing while in check and it was worse ,so am I doing something wrong ?
*Also what type of moves that should/shouldn't be reduced , and by how much "any general formula that works well generally" ?
*also in stock fish :

Code: Select all

// Step 13. Pruning at shallow depth
      if (  !rootNode
          && bestValue > VALUE_MATED_IN_MAX_PLY)
      {
          if (   !captureOrPromotion
              && !givesCheck
              && !pos.advanced_pawn_push(move))
          {
              // Move count based pruning
              if (moveCountPruning)
                  continue;

              // Reduced depth of the next LMR search
              int lmrDepth = std::max(newDepth - reduction<PvNode>(improving, depth, moveCount), DEPTH_ZERO) / ONE_PLY;

              // Countermoves based pruning
              if (   lmrDepth < 3
                  && (!cmh  || (*cmh )[moved_piece][to_sq(move)] < VALUE_ZERO)
                  && (!fmh  || (*fmh )[moved_piece][to_sq(move)] < VALUE_ZERO)
                  && (!fmh2 || (*fmh2)[moved_piece][to_sq(move)] < VALUE_ZERO || (cmh && fmh)))
                  continue;

              // Futility pruning: parent node
              if (   lmrDepth < 7
                  && !inCheck
                  && ss->staticEval + 256 + 200 * lmrDepth <= alpha)
                  continue;

              // Prune moves with negative SEE
              if (   lmrDepth < 8
                  && !pos.see_ge(move, Value(-35 * lmrDepth * lmrDepth)))
                  continue;
          }
          else if (    depth < 7 * ONE_PLY
                   && !extension
                   && !pos.see_ge(move, -PawnValueEg * (depth / ONE_PLY)))
                  continue;

why is it pruning moves with bad see based on the lmr depth/depth even captures , isn't that dangerous ?
& is there any connection between futility pruning and lmr's depth, or is it just using lmr's formula for futility ?

[Ferdy]

I tried it in non PV nodes reducing only quiet moves "castling excluded" & depth >2, using a reduction of 1 and I almost got no improvement

It is fine to have a little improvement.

"for example in the starting position ~-1second at depth 13 which takes ~16s without it" , I also tried it not reducing while in check and it was worse ,so am I doing something wrong ?

Could you post sample code you use, also describe your move ordering, because LMR is dependent on it.

*Also what type of moves that should/shouldn't be reduced , and by how much "any general formula that works well generally" ?

This is engine dependent you have to test every possible way like what SF team is doing. Usually you don't reduce captures and queen promotions. But the basic concept is to examine your evaluation function. Tell me which features in your eval has bonus and penalty. Passers for example has a good bonus points, so try not to reduce passers in the search. Also try not to reduce killers and moves with good history, you can try to reduce these type of moves later as you become familiar with your engine.

*also in stock fish :

Code: Select all

// Step 13. Pruning at shallow depth
      if (  !rootNode
          && bestValue > VALUE_MATED_IN_MAX_PLY)
      {
          if (   !captureOrPromotion
              && !givesCheck
              && !pos.advanced_pawn_push(move))
          {
              // Move count based pruning
              if (moveCountPruning)
                  continue;

              // Reduced depth of the next LMR search
              int lmrDepth = std::max(newDepth - reduction<PvNode>(improving, depth, moveCount), DEPTH_ZERO) / ONE_PLY;

              // Countermoves based pruning
              if (   lmrDepth < 3
                  && (!cmh  || (*cmh )[moved_piece][to_sq(move)] < VALUE_ZERO)
                  && (!fmh  || (*fmh )[moved_piece][to_sq(move)] < VALUE_ZERO)
                  && (!fmh2 || (*fmh2)[moved_piece][to_sq(move)] < VALUE_ZERO || (cmh && fmh)))
                  continue;

              // Futility pruning: parent node
              if (   lmrDepth < 7
                  && !inCheck
                  && ss->staticEval + 256 + 200 * lmrDepth <= alpha)
                  continue;

              // Prune moves with negative SEE
              if (   lmrDepth < 8
                  && !pos.see_ge(move, Value(-35 * lmrDepth * lmrDepth)))
                  continue;
          }
          else if (    depth < 7 * ONE_PLY
                   && !extension
                   && !pos.see_ge(move, -PawnValueEg * (depth / ONE_PLY)))
                  continue;

why is it pruning moves with bad see based on the lmr depth/depth even captures ,

Read the code again.

[cdani]

... and I almost got no improvement "for example in the starting position ~-1second at depth 13 which takes ~16s without it"

I'm not sure what you mean. If you mean that your measure of improvement is how fast goes to a given depth, is not a good measure. The good measure is to play enough games to have an statistically significative result. Maybe you have done it already.

[Henk]

LMR assumes that all late moves are bad moves. But that is almost never the case. For there are many late moves and information about move order is cumbersome.

So it's not much more than an upgraded PV extension.

[Lyudmil Tsvetkov]

LMR assumes that all late moves are bad moves. But that is almost never the case. For there are many late moves and information about move order is cumbersome.

So it's not much more than an upgraded PV extension.

are not you mixing LMR with LMP?

or I got a sunstroke?

[Henk]

LMR assumes that all late moves are bad moves. But that is almost never the case. For there are many late moves and information about move order is cumbersome.

So it's not much more than an upgraded PV extension.

are not you mixing LMR with LMP?

or I got a sunstroke?

Reducing search of late moves and not seeing that at least one of them is better than current PV is bad enough.

[Lyudmil Tsvetkov]

LMR assumes that all late moves are bad moves. But that is almost never the case. For there are many late moves and information about move order is cumbersome.

So it's not much more than an upgraded PV extension.

are not you mixing LMR with LMP?

or I got a sunstroke?

Reducing search of late moves and not seeing that at least one of them is better than current PV is bad enough.

I supposed you were talking about completely pruning away moves ordered lower in the list, as you were talking about move ordering. why do only a shallower search on moves ordered lower, as you can completely prune after 3rd or 4th ordered move?

in any case, what do couple of plies more or less really mean? in 3/4 of all cases you hit an evaluation position again, and not one resolved until mate/big material/positional advantage, and chances are your eval migth be better at bigger-depth nodes, but it also migth be worse there in comparison to lower-depth nodes?