Why search() reaching max ply of > 120 ?

[Sven]

I have understood that you do not try nullmove when in check. Now I have replayed part of the move sequence you gave (which is far from being the PV, it is clear that this is just one path of the whole tree that was searched by your engine). Black has a mate threat on b2 for a long time, and white is chasing the black king around the board. Most check evasions played by black are extended twice: once to extend check by 1 ply, and once as a "mate threat". As pointed out by HGM already, this is the critical point, I think this does not match the idea of a mate threat. Let's take the position after ply 41 (21...Kd6) as an example:
[d]4Q3/p7/3k4/1Bp5/8/1bq5/P4rPP/1K5R w - - 6 22
You try nullmove for white which returns something like "mated in 1" so you detect a mate threat, and therefore extend 21...Kd6 by one more ply. But a check escape is kind of a forced move, and I would never count a forced move also as a mate threat at the same time. I think you'll have to restrict your mate threat detection to silent (i.e., non-checking) moves which are also not forced (i.e., non-evasions). I have never tried it since I have not implemented mate threat detection but the given case seems to be quite obvious.

Sven

[AlvaroBegue]

I have a slightly different way of thinking about extensions that may help you: Extensions are a poor man's approach to make the search closer to realization-probability search. You can think of realization-probability search as meaning "a move should reduce depth by an amount proportional to -log(probability_of_the_move)". When the probability of the move is close to 1, that number is close to 0.

In plainer words, a move should be extended only if its probability of being played is very high. For instance, if there is only one check evasion available, it should be extended. Even if there are a few, you may want to do it. But you rarely have reason to believe that you are forced to give check, so you shouldn't extended checks: Only check evasions.

This general principle should keep your search tree from exploding.

[hgm]

Even by your reasoning the check would have to be extended: there is a serious mate threat against you, and the checks belong to the few moves that 'solve' it.

I think it is very legitimate to want to extend here; it is important to know at an early stage if the mate threat is unresolvable. If the black King could eventually flee to safety, and the mate could not be averted in another way,the resultingmate score of this branch could strongly affect the rest of the tree. I run into such problems in my Shogi engine all the time. You are in QS, happily making favorable exchanges, but while you doing so, the pieces accumulate in the handof the opponent, and despite their inferiority, when he starts dropping them with check next to your King, (i.e.contact checks), he might be able to checkmate you without you getting any opportunity to drop someof the superiorpieces in your hand. So it is very important to also search the check drops in QS. But it totally explodes the search when I do that.

I still have to figure out ways to contain this search explosion. For instance by more clever move ordering, trying to judge which evasions offer the least possibility for continuing the checking, and search those before evasions that expose you more. In the Chess case discussed here, the situation might improve if you order checks last.

[Chan Rasjid]

...I think you'll have to restrict your mate threat detection to silent (i.e., non-checking) moves which are also not forced (i.e., non-evasions).
Sven

Your diagram let me see what a nullmove matethreat is for the first time (I don't usually read chess positions)! White indeed is in a bad spot - passing means a mate-in-1!

I think it is never easy to find an 'ideal solution' to things in general. Chess programming most of the time rely on the 'most probable scenario'. I had this search reaching max ply as I ask for it to see what it means and what can be learned from it. Most program just put a limit to the number of max extension per line as mentioned by Michael Sherwin earlier and many would not know of this situation. I think the simple logical way is still to just do simple matethreat extension and put in a limit and don't worry about special cases... Don Dailey said in another thread that ... "... I would not have got a strong program if I ... worry about...it ".

Rasjid

[Sven]

...I think you'll have to restrict your mate threat detection to silent (i.e., non-checking) moves which are also not forced (i.e., non-evasions).
Sven

Your diagram let me see what a nullmove matethreat is for the first time (I don't usually read chess positions)! White indeed is in a bad spot - passing means a mate-in-1!

"My diagram" is in fact derived from your data directly

Once again: if the moving side has a mate threat but currently has to escape from check, as in the diagram above where black (the moving side of the predecessor position!) escaped with its last Move Ke7-d6, then I believe it will always be counter-productive to extend both: the check escape itself *and* the mate threat. Note that you have already extended when the mate threat was initially created. I would consider it a gross misunderstanding of the "mate threat extension" concept when applying this extension regardless whether the current move that creates (or keeps up!) the threat is a "silent", a "tactical", or a "forced" move. Extending also on threatening moves that are "tactical" or "forced" has great potential of creating a tree explosion, where the latter can be seen by the example you gave.

Sven