about MateThreat

[ILikeChess]

MateThreat tell us "the null move found that the side on move gets
mated by not moving".

So if it is necessary still "doing" null move when the MateThreat variable had been set true by Transposition Table?

By the way,many engines extend the search depth when MateThreat is true. In my test, it seems little different.

[Ron Murawski]

MateThreat tell us "the null move found that the side on move gets
mated by not moving".

So if it is necessary still "doing" null move when the MateThreat variable had been set true by Transposition Table?

By the way,many engines extend the search depth when MateThreat is true. In my test, it seems little different.

There's no sense null-moving if you've already calculated (and stored to the hash) that it leads to 'checkmate against'. If you null-move the same position once more it will again lead to 'checkmate against'.

I extend for null-move mate threats. You need to test king-attacking positions where an engine is on the defensive to measure the mate threat extension's worth.

Ron

[Pradu]

There's no sense null-moving if you've already calculated (and stored to the hash) that it leads to 'checkmate against'. If you null-move the same position once more it will again lead to 'checkmate against'.

I extend for null-move mate threats. You need to test king-attacking positions where an engine is on the defensive to measure the mate threat extension's worth.
Ron

On a side note you want to try to extend the move that prevents mate because extending moves that don't prevent mate is a waste. This information can be gotten from a reduced depth search or IID. If you have a hashmove which has a non-mate score at null-search-depth+1, you can extend that. This concept can be extended to regular threat extensions.

[pijl]

There's no sense null-moving if you've already calculated (and stored to the hash) that it leads to 'checkmate against'. If you null-move the same position once more it will again lead to 'checkmate against'.

I extend for null-move mate threats. You need to test king-attacking positions where an engine is on the defensive to measure the mate threat extension's worth.
Ron

On a side note you want to try to extend the move that prevents mate because extending moves that don't prevent mate is a waste. This information can be gotten from a reduced depth search or IID. If you have a hashmove which has a non-mate score at null-search-depth+1, you can extend that. This concept can be extended to regular threat extensions.

I did not test this, but this seems an unnecessary measure to me.
1. If you have a matescore in the hashtable, extending that move won't hurt as it returns immediately anyway
2. If you go looking for moves that do not evade mate with a reduced depth: What bounds are you going to use? Using a matescore-alpha will cost you a lot of nodes on mate-evading moves.
3. Mate threat conditions do not happen that often. At least not as often as e.g. check extensions. It's not very costly anyway.

The main problem with mate threat extensions is that these are usually lucky hits. As null move will fail low on any good move, it's just 'luck' if you're detecting a mate threat. If you go looking for mate threats to detect them all with a -matescore bound for both alpha and beta in a regular search, it can cost a lot of nodes and I certainly do not recommend that.

Richard.

[Daniel Mehrmann]

1. If you have a matescore in the hashtable, extending that move won't hurt as it returns immediately anyway.

Don't do it if it's a DTM score from EGTB

The main problem with mate threat extensions is that these are usually lucky hits. As null move will fail low on any good move, it's just 'luck' if you're detecting a mate threat. If you go looking for mate threats to detect them all with a -matescore bound for both alpha and beta in a regular search, it can cost a lot of nodes and I certainly do not recommend that.

Richard.

Fully agree

Best,
Daniel