I don't know what to call it

[Mike Sherwin]

Maybe a reversed polarity null move. The idea is if I make a move and my position is so bad that it is <= alpha and I pass for the opponent, then do a null move search and the score is still <= alpha then prune. Wouldn't it save some time to do it like this?

[hgm]

Doing a null move/turn pass for both yourself and the opponent is like doing no null move at all, right? So the search you do after this is guaranteed to get the same result (<= alpha) as you already had.

[Mike Sherwin]

If the reverse polarity null move is done the normal null move is not done. It is just a way of doing null move sooner?
for each move {
if eval <= alpha {
do null move search
if null mov search <= alpha return alpha
call negamax -b -a depth - 1
}
}

[Ras]

If the reverse polarity null move is done the normal null move is not done. It is just a way of doing null move sooner?

Lets assume the opponent has just captured a knight, which is why eval is below alpha. It's our turn, and we can capture the opponent's queen, which would get us above alpha. With your null move approach, we omit our queen capture, and the opponent moves his queen to safety. We would falsely return alpha here.

[Mike Sherwin]

I mistakenly put return alpha when I should have just put continue. Though in my move generator all the moves are scored when generated. Therefore the queen captures etc. would be tried first. Then after so many tries we can LMR and return alpha anyways.

[Ras]

I mistakenly put return alpha when I should have just put continue.

If you are close to the leaves of the search tree and much below alpha, you can discard moves that have no hope of getting above alpha, i.e. non-captures/promotions/killers that don't give check. That's not a null move, however, but futility pruning: https://www.chessprogramming.org/Futility_Pruning

[hgm]

It is still not clear to me what you propose. Do you make 'each' move, and if so, where? If you do the null move after making a move that does not raise the score above alpha, it is exactly the same as doing null move in the child when eval is above beta. It doesn't alter the search tree, but only how you slice it up into instances of Search(). Often it is more efficient to do this in other ways than the 'text-book examples'. E.g. probing the TT can be profitably be done in the parent, before making the move. And ordering the research for PVS or LMR can be more efficiently done in the child, to avoid having to generate the moves again.

[Mike Sherwin]

It is still not clear to me what you propose. Do you make 'each' move, and if so, where? If you do the null move after making a move that does not raise the score above alpha, it is exactly the same as doing null move in the child when eval is above beta. It doesn't alter the search tree, but only how you slice it up into instances of Search(). Often it is more efficient to do this in other ways than the 'text-book examples'. E.g. probing the TT can be profitably be done in the parent, before making the move. And ordering the research for PVS or LMR can be more efficiently done in the child, to avoid having to generate the moves again.

You correctly understand. Do null move in the parent to avoid an unnecessary call into the child.