Question on Null Move Pruning

[jfern2011]

Why do we search null moves with null windows? Is it because if a node is passed the null window [alpha, alpha+1] and fails low, then our position is so good that no move can refute the null move?

[PK]

Because null window is faster, and is enough to provide information we need. When we make a null move, opponent gets huge odds. It does not matter if, given that odds, he gains a queen, or just a small positional advantage, it does not matter how far above beta he can get, so bigger window is not necessary. Tee only thing that matters is when he cannot beat beta. Null window is enough to recognize this.

[hgm]

The narrower the window, the more cut-nodes you will have, and the easier it will be to find the cut-moves in those, all lowering the required number of nodes. So never ask the search for more information than you need. In null-move pruning you only want to know whether the null move fails high or not. You won't use the score itself either way.

[Aleks Peshkov]

Null move heuristic should not be done on PV-nodes. To my limited understanding all non-PV nodes in PVS are searched with null-window.

[Henk]

Null move heuristic should not be done on PV-nodes. To my limited understanding all non-PV nodes in PVS are searched with null-window.

I even don't understand why no null move in PV nodes. I can understand first move of PV must no be null move for that is an invalid move.

[mjlef]

Null move heuristic should not be done on PV-nodes. To my limited understanding all non-PV nodes in PVS are searched with null-window.

You can use nullmove on PV nodes, provided beta is less than whatever is infinity for your program. It has not tested well in the past.

[mjlef]

Why do we search null moves with null windows? Is it because if a node is passed the null window [alpha, alpha+1] and fails low, then our position is so good that no move can refute the null move?

You probably mean [beta-1, beta]. Null move saves search nodes by assuming a score is so good that if we let the opponent move twice in a row and it cannot get the score below beta, then the present node is most likely a fail high node. In non-PV nodes that is the same as [alpha, alpha+1], but in PV nodes it is not, of course.

[hgm]

Indeed, but it is the null-move reply that we call Search() for, and I suppose he is referring to the argumentsof that call.

[Michael Sherwin]

Alpha & Beta swapping and negation has always been confusing to me. Am I doing it right or wrong. The way I do it does not match any of the examples given.

Null Move

Code: Select all

    MakeMove(&nullMove);
    score = -Search(-beta, -beta + 1, depth - 1 - r);
    TakeBack();
    if(score >= beta) {
      PosStore(beta, depth, LOWER, &nullMove);
      return beta;
    } 

Search, Zero Window

Code: Select all

        score = -Search(-alpha - 1, -alpha, depth - lmr);
        if(score > alpha)
          score = -Search(-beta, -alpha, depth - 1);

[hgm]

This is wrong. But you get away with it if beta = alpha+1, as it would be in a non-PV PVS node.