Interesting ideas

[nionita]

I was fighting a lot trying to use somehow the threat move from the null move search.

At the end I inserted it as a killer move. After about 70k games the resulting gain was ~2cp, a bit smaller then the error margin (more engines involved in the games). But I let the code in place, 'cause I could not accept the idea that that information is useless.

[cdani]

I was fighting a lot trying to use somehow the threat move from the null move search.

At the end I inserted it as a killer move. After about 70k games the resulting gain was ~2cp, a bit smaller then the error margin (more engines involved in the games). But I let the code in place, 'cause I could not accept the idea that that information is useless.

I have it also like a killer, with preference in move ordering and less reductions.

[jdart]

Stockfish had code that would extend a previously reduced move if the threat move from a null search was related to that previous move. They also disabled certain pruning/reductions for moves that appeared to counter the null move threat. However IIRC this code was removed from Stockfish at some point.

--Jon

[hgm]

I was fighting a lot trying to use somehow the threat move from the null move search.

Indeed, I also had that experience. The true threat seems to be masked most of the time by an unrelated harmless Q or R trade, which in the move ordering goes (quite justly) before cashing of an existing threat. The special evasion code that would use this information would then try to avoid that trade, rather than solving the real problem.

Basing the threat on SEE is much more reliable. If the node after nullmove uses SEE to order its captures, the capture with the highest SEE could be labeled as the threat move. The catch is that for efficiency reasons we often don't calculate SEE for good or equal captures, as they are ordered by victim value. LxH captures are easy to recognize, and always represent threats. But for the equal captures of protected pieces it depends on what follows. So you might be forced to subject them to SEE, at least in the node after null move.

[Rebel]

I was fighting a lot trying to use somehow the threat move from the null move search.

At the end I inserted it as a killer move. After about 70k games the resulting gain was ~2cp, a bit smaller then the error margin (more engines involved in the games). But I let the code in place, 'cause I could not accept the idea that that information is useless.

I have some gain extending one ply when the null move returns a mate value.

[cdani]

New idea that also did not work for me.

When you enter in a new position in alpha_beta not previously evaluated (so without tt move), you save in a history-like table (piece-destination) the difference of the evaluation of the position previous and after doing the move, and also increase a counter for this piece-destination.

When sorting quiets, after adding history value, add the median of the differences.

I tried different variations, and none worked; they were not very bad, though.

[nionita]

The catch is that for efficiency reasons we often don't calculate SEE for good or equal captures

Hmm, this could be an idea, after returning from the null nove (NOT faiiling high) to find the highest SEE move (in the same position, but with side to move changed, as found by the null move), a posteriori. Then try that as threat move.

[hgm]

This surely can aid a lot in move ordering. If you know which piece is under threat, and how much you stand to lose there, you can add the latter to the sort key (be it MVV/LVA or SEE_based) for any captures made with that piece. And if the SEE is also indicating the lowest attacker, you could upgrade the sort key of captures of that piece as well.

In fact it would often be useful to know if a threat is overkill, and thus immune to cappture of one of the attackers. E.g. if I have both a Knight and Bishop attacking an unprotected Rook, the threat is worth a Rook, but neither capturing the B or N will alter that. If you have a tabl-based SEE, you could flag 'immunity' of the threat in the table. Or even indicate how much the threat would devaluate on capture of each attacker. (E.g. if both B and R attack a Q protected by two P, SEE=+6. It remains +6 if the Rook gets captured, but if the Bishop is captured it reduced to +4.)