Stockfish Nullmove uci option #178

[Evert]

Marco will never accept a patch that disables null move.
He's also against adding unnecessary UCI options.

If you really want a variant of Stockfish without null move you should just fork it and and just delete the null move code.
This will probably be easier than adding the option and the end product will be more efficient as well.

The crux, of course, is that disabling null-move is only ever useful for analysing certain positions. Thus the only reason to add it as an option is to make it more useful for analysing certain positions.

If that's not a goal of the team maintaining Stockfish, you'd have to fork it and make a special version that is more suitable for analysis. Nothing wrong with that.

[Evert]

Thanks

I forget to mention this change:

Code: Select all

  o["Enable Null Move"]            = Option(true);

to

Code: Select all

  o["Disable Null Move"]            = Option(false);

My intention was to change "IF ... AND ... AND ..." to "IF Options["Disable Null Move"] ... OR IF !PvNode && ..."

Edit:
I mean if the option is set to "FALSE" then Stockfish behaves like the original, and if it is "TRUE" that activates the patch supposed to disable "Nullmove".

Is that it makes sense to you?

What you're looking for is the change from

Code: Select all

if (null_move_enabled && ...)

to

Code: Select all

if (!null_move_disabled && …)

However,
1. I would personally prefer the former, I find it more readable and it avoids an inversion, making the code easier to follow. Why do you want to change it anyway?
2. This is a very simple change. No offence, but if you need to ask how to do this, I very strongly suggest investing some time in improving your programming skills before trying to make other changes to the code.
3. Said before, but repeated for emphasis: do NOT use a dictionary to test if an option has been set or not during the search. It will kill your performance. Use a plain scalar variable instead.

[Uri Blass]

Hello,

I would like your opinion on this patch https://github.com/mcostalba/Stockfish/pull/178/files
It is supposed to disable Nullmove

The patch replace this

Code: Select all

if (   !PvNode
        && !ss->skipNullMove
        &&  depth >= 2 * ONE_PLY
        &&  eval >= beta
        &&  abs&#40;beta&#41; < VALUE_MATE_IN_MAX_PLY
        &&  pos.non_pawn_material&#40;pos.side_to_move&#40;)))
    &#123;

by this:

Code: Select all

if (    Options["Enable Null Move"]
        && !PvNode
        && !ss->skipNullMove
        &&  depth >= 2 * ONE_PLY
        &&  eval >= beta
        &&  abs&#40;beta&#41; < VALUE_MATE_IN_MAX_PLY
        &&  pos.non_pawn_material&#40;pos.side_to_move&#40;)))
    &#123;

And I propose the following: (replace && by ||) Is this correct or is it more complex than that?

Code: Select all

if (    Options["Enable Null Move"]
        || !PvNode
        && !ss->skipNullMove
        &&  depth >= 2 * ONE_PLY
        &&  eval >= beta
        &&  abs&#40;beta&#41; < VALUE_MATE_IN_MAX_PLY
        &&  pos.non_pawn_material&#40;pos.side_to_move&#40;)))
    &#123;

My opinion is that is it better to have a number that tell you the minimal depth that stockfish avoid null move pruning.

&& depth <= max_null * ONE_PLY in the conditions for null move pruning.

max_null=1 means never using null move pruning because depth always at least 2 plies based on another condition.

max_null>=120 means that stockfish always use null move pruning.
People also can use max_null=20 or max_null=30 for analysis of their correspondence games that mean using null move pruning only when the remaining depth is small.

[syzygy]

Excessive use of parentheses is very bad for readability of code. Not knowing operator precedence is therefor a bad idea.

Ok, so you find

Code: Select all

if &#40;a < b ||  c > 5 && d == 2&#41;

more readable than

Code: Select all

if &#40;a < b || &#40;c > 5 && d ==2&#41;)

Very well. I certainly don't.

I'd be surprised if you find examples of your preferred version in, say, the official Stockfish source.

Hmm, as expert on readable code you might be of the view that both versions are about as bad and it should be as follows:

Code: Select all

if&#40;a<b||c>5&&d==2&#41;

[AlvaroBegue]

I've read code long enough that all those alternatives look equally clear to me.

It's like 3+4*x being as clear as 3+(4*x). If you have done math long enough, you have really internalized that products have higher precedence than additions. The situation with conjunctions and disjunctions in logic is completely analogous.

But I think my compiler would issue a warning telling me I should use extra parentheses to avoid mistakes, and I usually cave in because I value not having compilation warnings.

[phenri]

For now I need to clarify my ideas because I do not understand everything.
Including what the logic was:
IF {condition1 AND condition2...} THEN Disable NullMove
or is
IF {condition1 AND condition2...} THEN Enable NullMove

However, thank you all very much for all the invaluable help you have given me. :)

[hgm]

Ok, so you find

Code: Select all

if &#40;a < b ||  c > 5 && d == 2&#41;

more readable than

Code: Select all

if &#40;a < b || &#40;c > 5 && d ==2&#41;)

Very well. I certainly don't.

A more realistic example could be

Code: Select all

if&#40;4*x + 1 < 2*y || f&#40;3*x - 1&#41; > 5 && d&#91;i - 1&#93; == 2&#41;)

versus

Code: Select all

if&#40;((&#40;4*x&#41; + 1&#41; < &#40;2*y&#41;) || (&#40;f&#40;&#40;3*x&#41; - 1&#41; > 5&#41; && &#40;d&#91;i - 1&#93; == 2&#41;)))

Good layout is enormously more helpful to code readability than parentheses.

[Evert]

A more realistic example could be

Code: Select all

if&#40;4*x + 1 < 2*y || f&#40;3*x - 1&#41; > 5 && d&#91;i - 1&#93; == 2&#41;)

versus

Code: Select all

if&#40;((&#40;4*x&#41; + 1&#41; < &#40;2*y&#41;) || (&#40;f&#40;&#40;3*x&#41; - 1&#41; > 5&#41; && &#40;d&#91;i - 1&#93; == 2&#41;)))

Good layout is enormously more helpful to code readability than parentheses.

Actually, I might prefer something like

Code: Select all

if&#40; (&#40;4*x + 1&#41; < 2*y&#41; || &#40;f&#40;3*x - 1&#41; > 5 && d&#91;i - 1&#93; == 2&#41; )

Yes, I know, inconsistent use of parentheses, but they actually help me distinguish the different elements in the comparison. I might write "2*y > 4*x+1" instead of "(4*x+1) < 2*y" though. Other than that, I agree that code layout may be a more important factor in readability, but clearly there is some personal preference involved.

[AlvaroBegue]

I think operator precedence is not what's obscuring that expression: It's the fact that each of the ingredients is hard to read on its own. Chances are you can give your variables names that are more informative than `x' and `y', and you can use helper [inline] functions that also have informative names, and then the expression would read more like English.

[hgm]

OTOH, long, informative names make the line much longer, forcing it to be split over several lines, and pushing closing parentheses out of view.

The keyword in my remark was excessive. In Ronald's example there was only a single pair of parentheses, and that of course is always trivial, because it is obvious which closing parenthesis belongs to which opening parenthesis if there is only one. But it becomes tricky when they are nested, and several of them follow each other, so that you now really have to count them to realize which belongs with which. Consecutive parentheses are best avoided, and attempts to do so lead to bugs when one is ignorant on operator priorities.

The pedantic compiler warning about this can be turned off.