LMR

[Bas Hamstra]

Any non-believers in LMR? It seems to introduce some nasty randomness, missing tactics here and there. Well, how could it be good, reducing moves upon moves for no good reason?

Bas

[Dann Corbit]

Any non-believers in LMR? It seems to introduce some nasty randomness, missing tactics here and there. Well, how could it be good, reducing moves upon moves for no good reason?

Bas

All the strongest programs use it, but it is very fiddly to get it right.

You will find, upon examination of every successful LMR implementation, that there are lots of quid-pro-quos involved.

A good example to examine is that of stockfish.

P.S.
Will we see a new yin/yang/tao soon?

[Dann Corbit]

Any non-believers in LMR? It seems to introduce some nasty randomness, missing tactics here and there. Well, how could it be good, reducing moves upon moves for no good reason?

Bas

All the strongest programs use it, but it is very fiddly to get it right.

You will find, upon examination of every successful LMR implementation, that there are lots of quid-pro-quos involved.

A good example to examine is that of stockfish.

P.S.
Will we see a new yin/yang/tao soon?

For stockfish, this is from the pv search:

Code: Select all

      if (moveCount == 1) // The first move in list is the PV
          value = -search_pv(pos, ss, -beta, -alpha, newDepth, ply+1, threadID);
      else
      {
        // Try to reduce non-pv search depth by one ply if move seems not problematic,
        // if the move fails high will be re-searched at full depth.
        if (    depth >= 2*OnePly
            &&  moveCount >= LMRPVMoves
            && !dangerous
            && !moveIsCapture
            && !move_is_promotion(move)
            && !move_is_castle(move)
            && !move_is_killer(move, ss[ply]))
        {
            ss[ply].reduction = OnePly;
            value = -search(pos, ss, -alpha, newDepth-OnePly, ply+1, true, threadID);
        }
        else
            value = alpha + 1; // Just to trigger next condition

        if (value > alpha) // Go with full depth non-pv search
        {
...

And this is from the general search:

Code: Select all

      // Make and search the move
      StateInfo st;
      pos.do_move(move, st, dcCandidates);

      // Try to reduce non-pv search depth by one ply if move seems not problematic,
      // if the move fails high will be re-searched at full depth.
      if (    depth >= 2*OnePly
          &&  moveCount >= LMRNonPVMoves
          && !dangerous
          && !moveIsCapture
          && !move_is_promotion(move)
          && !move_is_castle(move)
          && !move_is_killer(move, ss[ply]))
      {
          ss[ply].reduction = OnePly;
          value = -search(pos, ss, -(beta-1), newDepth-OnePly, ply+1, true, threadID);
      }
      else
        value = beta; // Just to trigger next condition

      if (value >= beta) // Go with full depth non-pv search
      {
          ss[ply].reduction = Depth(0);
          value = -search(pos, ss, -(beta-1), newDepth, ply+1, true, threadID);
      }
      pos.undo_move(move);

[Karlo Bala]

Any non-believers in LMR? It seems to introduce some nasty randomness, missing tactics here and there. Well, how could it be good, reducing moves upon moves for no good reason?

Bas

I think that point of using LMR is to make tactically STRONGER engine. Gain of the LMR is deeper search, but at what cost? If you reduce non interesting non tactical moves than you risk to miss some positionally stronger moves somewhere in the tree. Weaker positional move can cost you few elo points, but tactical miss can cost you much more (Vas talked about that long time ago, but then he wasn't so famous ). IMO, after hash move, killers, exchanges, promotions, and perhaps some passed pawn pushes you can freely reduce everything else. As Dann says, you should look at Tord's code. He introduces some nice tricks and he is the biggest expert for LMR.

[bob]

Any non-believers in LMR? It seems to introduce some nasty randomness, missing tactics here and there. Well, how could it be good, reducing moves upon moves for no good reason?

Bas

It is not exactly for "no good reason". Most nodes either fail high or fail low. If they fail high, it happens on the first move most of the time (>90% at least). If it fails low, every move must be searched, regardless of effort required. LMR actually seems quite natural when you think about it.

We used to recognize two classes of moves. Those we extend because they appear to be tactically significant (checks, maybe others) and those we do not. We now add a third class, so that we have those we extend, those we search to the normal depth, and those we search to a shallower-than-normal depth. In my case, near the tips, I have a 4th class, those I don't even search, period....

[Mincho Georgiev]

Any non-believers in LMR? It seems to introduce some nasty randomness, missing tactics here and there. Well, how could it be good, reducing moves upon moves for no good reason?

Bas

Besides what Bob just said, i'd like to add that there is no reduction technique, that should be considered separately from the rest of the search
algorithm. If we exclude the tactical moves that are obviously bad candidates for reduction, The reason, that you mention for the other ones, almost always comes from other techniques, that works in conjunction with LMR.
For example, if you are 'full-depth' searching 4 moves and the 5th one according to your move ordering is a killer move and despite that, you are reducing it, that doesn't sound reasonable. I hope you see my point.

[adieguez]

But have you tried it in a long match?

my very first and simple try with LMR gave me 34 ELO. My current implementation (just my 4th try and still I have many things to try) is giving me 45 ELO.

You also said time ago futility prunning was bad. You are not using it neither?

Any non-believers in LMR? It seems to introduce some nasty randomness, missing tactics here and there. Well, how could it be good, reducing moves upon moves for no good reason?

Bas

[adieguez]

for this technique, it is even so simple to get gain no code is necesary just the name "late move reduction". Also for nullmove. Time ago I was confused with the definition of R once because for nullmove you just need a short description and I never paid atention to how was R defined in any example.

A good example to examine is that of stockfish.

[adieguez]

Aaaaah and there is something I forgot to comment isn't more cool if your chess engine show a higher search depth? I think is so cool. In my next update amyan will show a noticeable higher search depth is a complete liar! but whatever.

[Bas Hamstra]

But have you tried it in a long match?

Yes...it gives me nothing. Not even a 100 game match.

I also read older posts of Bob Hyat in which he tried and tried and tried. And still reported it gave nothing. I don't know what caused his position to change. Suddenly he was a defender, I don't understand.

What I don't understand is that people claim FHR improves tactical ability. In all my testsuites critical winning (but unexpected) moves are found way later in time.

I see at the server programs report ridiculous depths, presumably using LMR, and making HORRIBLE blunders. Like going from +2 to -6 the next move

>my very first and simple try with LMR gave me 34 ELO. My current >implementation (just my 4th try and still I have many things to try) is >giving me 45 ELO.

I think there may be some room for gain, but NOT the naive unrestricted implementation as propagated in this trhead. It seems yours is adapted too.

Naive version: reduce everything after the 4th move, provided the move is no capture and there was no extension triggered. It sucks

Bas