showing a list of moves with nullmoves in them

[flok]

Hi,

When doing iterative deepening, a pv is shown for each depth consisting of the moves in the branch(es) taken.
I now wonder: how can I emit such a pv when there are null moves? Because then I would have something like W, B, W, W, B which may confuse the reader?


regards

[hgm]

There should never be any null moves in the PV. Null moves either fail low, or make the node in which they are played fail high, refuting the previous ply.

[bob]

Hi,

When doing iterative deepening, a pv is shown for each depth consisting of the moves in the branch(es) taken.
I now wonder: how can I emit such a pv when there are null moves? Because then I

Can't happen unless you have a bug. A null move can NEVER be backed up as the best move, it has to fail low, or fail high, since you should only search it with a null window...

[flok]

There should never be any null moves in the PV. Null moves either fail low, or make the node in which they are played fail high, refuting the previous ply.

Code: Select all

alpha cur_score beta
-10000 -39 -28
-10000 -38 -34
-10000 -36 -34

So here (depth 3 searched from starting pos) the values are neither lower than -10000 and not higher than -28/-34. So that is a bug then, right?

Hi,

When doing iterative deepening, a pv is shown for each depth consisting of the moves in the branch(es) taken.
I now wonder: how can I emit such a pv when there are null moves? Because then I

Can't happen unless you have a bug. A null move can NEVER be backed up as the best move, it has to fail low, or fail high, since you should only search it with a null window...

So if cur_score >= beta, I should only return the score and not add use the pv returned by the null-move search?

[bob]

There should never be any null moves in the PV. Null moves either fail low, or make the node in which they are played fail high, refuting the previous ply.

Code: Select all

alpha cur_score beta
-10000 -39 -28
-10000 -38 -34
-10000 -36 -34

So here (depth 3 searched from starting pos) the values are neither lower than -10000 and not higher than -28/-34. So that is a bug then, right?

You are not doing this correctly. NULL move searches are ALWAYS done with a null-window, i.e. beta == alpha + 1. So you either fail low and ignore the null-move search completely, or you fail high and return beta, since this refutes the move at the previous ply. A null-move can never be a part of any PV if you do things correctly...

Hi,

When doing iterative deepening, a pv is shown for each depth consisting of the moves in the branch(es) taken.
I now wonder: how can I emit such a pv when there are null moves? Because then I

Can't happen unless you have a bug. A null move can NEVER be backed up as the best move, it has to fail low, or fail high, since you should only search it with a null window...

So if cur_score >= beta, I should only return the score and not add use the pv returned by the null-move search?

That is a "fail high" move, How can there be any PV? EVERY move at the next ply failed low, in order for the null-move to fail high. Which move was "best"???

[Edmund]

As already mentioned before: Nullmoves cannot be part of a PV.

A different issue is "current line", ie communicating current thinking in real time.
For example specified in the UCI protocol: option UCI_ShowCurrLine
The UCI protocol further specifies "A nullmove from the Engine to the GUI should be send as 0000."
It is then upto the GUI to decide how to deal with this. Arena for example doesn't indicate nullmoves at all and will show two moves of the same player in a row.

Winboard protocol specifies a nullmove should be transmitted as @@@@, however I am not aware of a case where the GUI would request the engine to send any line including nullmoves.

[Sven]

Maybe a part of your problem is how you construct your PV. You need to consider the following rule:

A move (and the PV of its subtree) that has just been searched becomes the new PV of the current node if and only if its score is inside the current alpha-beta window, so alpha < score < beta.

This is also valid at the root node when using aspiration windows.

By obeying this rule, null moves are excluded automatically from any PV as already stated by others since the window is empty due to beta == alpha + 1.

There is a second reason why null moves cannot occur as part of a PV: if a null move becomes "best move" of a node (and if you would ignore the rule mentioned above!) then you get a beta cutoff which refutes the previous move of the opponent at the parent node. Therefore such a "best move" would never make it into the PV of the parent node. An exception would be the root node but either you do not try the null move at the root node, or you obey the rule above (which you should always do) ...