What feature kicks in at ply 7 in Stockfish?

[Michiel Koorn]

I am chasing a bug for the MTD mod of Stockfish, and in doing so I noticed a pattern of crazy return values and best move changes at ply 7. Something happens there and it is not something I implemented. Anybody?

[Eelco de Groot]

I am chasing a bug for the MTD mod of Stockfish, and in doing so I noticed a pattern of crazy return values and best move changes at ply 7. Something happens there and it is not something I implemented. Anybody?

If you ask what feature kicks in at the last plies it could well be you see something of the tactical search there, that begins around that depth and is pruning fairly aggressively if a move is not supposed to have tactical consequences.

I have not studied futility from that last version of search much, it has changed somewhat in 1.8. See for instance

Code: Select all

inline Value futility_margin(Depth d, int mn) { return Value(d < 7 * OnePly ? FutilityMarginsMatrix[Max(d, 0)][Min(mn, 63)] : 2 * VALUE_INFINITE); }

which is then used for the futility pruning later, movecount based and value based, the margins in the value based pruning.

Code: Select all

      // Step 12. Futility pruning (is omitted in PV nodes)
      if (   !PvNode
          && !captureOrPromotion
          && !isCheck
          && !dangerous
          && !move_is_castle(move))
      {
          // Move count based pruning
          if (   moveCount >= futility_move_count(sp->depth)
              && !(ss->threatMove && connected_threat(pos, move, ss->threatMove))
              && sp->bestValue > value_mated_in(PLY_MAX))
          {
              lock_grab(&(sp->lock));
              continue;
          }

          // Value based pruning
          Depth predictedDepth = newDepth - reduction<NonPV>(sp->depth, moveCount);
          futilityValueScaled =  ss->eval + futility_margin(predictedDepth, moveCount)
                               + H.gain(pos.piece_on(move_from(move)), move_to(move));

          if (futilityValueScaled < sp->beta)
          {
              lock_grab(&(sp->lock));

              if (futilityValueScaled > sp->bestValue)
                  sp->bestValue = futilityValueScaled;
              continue;
          }
      }

Also IID and the singular extension search are switched off for shallow depths that is around 8 plies in the nullwindow searches I believe for Stockfish.

Don't know much about MTD, sorry Michiel, but that is where I would look first

Regards,
Eelco

[Michiel Koorn]

Coming from the other direction I come to the same thing, pruning. First I was focussed on my TT interfering with refined eval. This did not pan out. I found a case where the move selected had a lower bound of 25 and an upperbound of -500. Kicking in with pruning is what I understand search instability to be. This subset (both upper & lowerbound known and contradictory) is easy to detect. Question is what to do. What result can be trusted, if any at all. I am currently thinking of just swapping upper and lowerbound, and proceed from there.
Another question is why the effect subsides with deeper searches. Is is "just" Beal effect or is there an effect of move selection( killers etc) needing to adapt to a step change in evaluation
Finally the effect is dominating due to MTD, but to what extent is it also interfering in in the original?