how to track down a BUG?

[Michel]

It's better to selectively extend the moves that prevent the threat (this is at low depth only). Testing confirms (Marco, Gary, and I tested separately, and all got positive results):

Yes, but did you also test it _without_ the extension? I find it hard to believe that extending a few moves in a reduced search would make much of a difference.

It might be that automatically researching at full depth after a ("connected") null threat was simply too expensive. Your patch eliminates this.

[lucasart]

It's better to selectively extend the moves that prevent the threat (this is at low depth only). Testing confirms (Marco, Gary, and I tested separately, and all got positive results):

Yes, but did you also test it _without_ the extension? I find it hard to believe that extending a few moves in a reduced search would make much of a difference.

It might be that automatically researching at full depth after a ("connected") null threat was simply too expensive. Your patch eliminates this.

Try it, you'll see. It performed measurably better than the original code, which itseld was a measurable improvement over nothing at all.

[hgm]

So, if the search turns successful, when it returns to the original parent's node it will also trigger a research, effectively doing an extension since the child was not reduce (the parent does not know that).

I am not sure what you mean. Parents NEVER do researches, having delegated the decision and the responsibility to do them full to their childs.

If you mean that children could try to take away a reduction that was never granted, thus causing an extension: obviously you have to pass information to the child to enable it to decide when to 'extend'. For the LMR this would be whether the move leading to it was 'late' in the parent. And possibly how late, if you don't reduce all moves by the same amount. So basically you pass a minimum (reduced) and a maximum (unreduced) depth to the child, (or a nominal depth and a reduction), rather than a single depth. (I use the 'node type' parameter for this, where different reductions are simply a diversification of the cut-node type.)

For PVS researches you will have to pass the parents beta, so that the child can open the window by the right amount if its first iteration fails low. This does not require an extra parameter, as the child can see from the node-type that it has to collapse the window to a null window (setting alpha to beta-1) in the first iteration (namely in all non-PV nodes).

[Michel]

Try it, you'll see. It performed measurably better than the original code, which itseld was a measurable improvement over nothing at all.

You are not contradicting what I am saying.

I am not disputing your test results. I am suggesting that the improvement is not due to extending the threat avoiding moves, but simply because the
automatic research was too expensive.

If I am right then your patch would also work without extending the threat avoiding moves.

[lucasart]

I am suggesting that the improvement is not due to extending the threat avoiding moves, but simply because the research was too expensive.

Exactly! Extending the threat avoiding moves is enough, rather than extending all moves (HGM's proposal) or doing a research at full depth (Tord's idea in Glaurung, which is basically the same as what HGM says, bus slightly more economical, due to potential early cutoffs in the re-search).

[Michel]

Exactly! Extending the threat avoiding moves is enough, rather than extending all moves (HGM's proposal) or doing a research at full depth (Tord's idea in Glaurung, which is basically the same as what HGM says, bus slightly more economical, due to potential early cutoffs in the re-search).

I am suggesting that extending _no moves at all_ would do just as well.... I have been asking in the last three posts if you have tested that.

[hgm]

I know that Bob claims that it works best to rigorously reduce all (non-checking) non-captures, making no exceptions at all based on history or tactical 'follow-ups'. Where the latter seems to be what you are proposing.

Not reducing branches along a sensible non-futile attack + evasion, like Lucas does, seems a good way to reduce tactical blindness, though.

[lucasart]

Exactly! Extending the threat avoiding moves is enough, rather than extending all moves (HGM's proposal) or doing a research at full depth (Tord's idea in Glaurung, which is basically the same as what HGM says, bus slightly more economical, due to potential early cutoffs in the re-search).

I am suggesting that extending _no moves at all_ would do just as well.... I have been asking in the last three posts if you have tested that.

Yes, I have tested it, and it was a regression. But I agree with you, it shouldn't be the case. None of these extensions (and many different ideas around it that I tested) worked for my engine DiscoCheck.

Stockfish is a strange animal: somehow this idea works in SF and perhaps nowhere else...!?

The only "null move fail low" stuff that I managed to get a measurable improvement out of, in DiscoCheck is the following "mate threat extension":

Code: Select all

		// Null move pruning
		if (!is_pv && !in_check && !is_mate_score(beta)
			&& current_eval >= beta
			&& B.st().piece_psq[B.get_turn()])
		{
			const int reduction = null_reduction(depth) + (current_eval - vOP >= beta);

			B.play(0);
			int score = -search(B, -beta, -alpha, depth - reduction, false, ss+1);
			B.undo();

			if (score >= beta)		// null search fails high
				return score < mate_in(MAX_PLY)
				       ? score		// fail soft
				       : beta;		// *but* do not return an unproven mate
			else if (score <= mated_in(MAX_PLY) && (ss-1)->reduction)
				++depth; // mate threat extension
		}

I know what you're going to say: this code is unsound as it relies on fail soft scores, instead of doing a zero window search to test for a mate score. But the point is that when the null move returns a mate score, you can trust that the mate threat is real. On the other hand, due to beta cut-offs, you can't expect this to detect deep mates. So, I don't detect many deep mate threats in this way, but the ones I detect are gratis.

However doing a zero window search for a mate is very costly, because, in general, you won't find one and wuill just waste time searhcing for it (this was an idea I found in the chess programming wiki, and I think it's rather silly due to the cost of the ZW search for mate threat).