hash move vs. null move

[hgm]

A question to those that do not (always) do IID:

If the (non-null) hash move (searched first) fails low, do you still search a null move afterwards? The fact that you had a non-null hash move must mean that the null move failed low before, in this position.

OTOH, beta might be lower now than it was the previous time you tried the null move, and the hash move might fail low because it is a poor move that took some depth to refute. If you don't ever retry the null move, it can never become hash move again, even if it deserves to be so. Plus, the null move might be a cheap way to find a killer relevant for the next level, e.g. if the hash move was withdrawing a hanging piece, but to a poorly chosen refuge.

[Zach Wegner]

A question to those that do not (always) do IID:

If the (non-null) hash move (searched first) fails low, do you still search a null move afterwards? The fact that you had a non-null hash move must mean that the null move failed low before, in this position.

Not for my engine.

When I store a cutoff in the hash for a null move, I don't overwrite the old move. I also try a null move regardless of what is in the hash, always before a real move. I think even in your engine if null move failed low, it is still useful to do it again, unless perhaps you know that beta was greater than or equal to the current beta (I think crafty does something like this...). Null moves are always cheap and give more useful data than just the cutoff (mate threats, threat move for move ordering, LMR refutations, BM extensions).

[BubbaTough]

Zach,

Is a threat move just the best move from the null search? Which if you don't do anything special becomes your killer move?

-Sam

[hgm]

I also try a null move regardless of what is in the hash, always before a real move.

Do I understand correcty from this that you try the null move before the hash move? That sounds like a waste of time, as normally you would expect the hash move to be good. So killers on the next level would be to no avail for the hash-move search, they would be tried in an all-node.

Or don't you consider the hash move a real move?

[Zach Wegner]

Zach,

Is a threat move just the best move from the null search? Which if you don't do anything special becomes your killer move?

-Sam

Yeah, it's the null move refutation. It's tried on the next ply after the hash move if it's legal.

[Zach Wegner]

I also try a null move regardless of what is in the hash, always before a real move.

Do I understand correcty from this that you try the null move before the hash move? That sounds like a waste of time, as normally you would expect the hash move to be good. So killers on the next level would be to no avail for the hash-move search, they would be tried in an all-node.

Or don't you consider the hash move a real move?

I don't think it is a waste of time, in fact you're the only person I know of that doesn't do this. The hash move is expected to be good, but the null move is cheaper. In fact the hash move should be better than the null move in virtually all positions (sans zugzwang). Since the null move is never stored as the best move, we can't logically assume that the hash move is a better move to try (i.e. we can't assume the null move failed low before, because the score in the hash and the move might come from different searches).

I'm not sure what you mean about the killers on the next ply. Once the null move has been tried and failed, it's quite possible that the move is an all node. The hash move does indicate that it got a score > alpha at some point, but we don't know it will happen now. Anyways, I'm not sure why killers are relevant here anyways, I wasn't talking about them. Perhaps you meant the threat move? If so, that is kept for all moves on the next ply, so, assuming that the current node is an all node (since the null move failed low), then the threat move could help refute the hash move and every other move after it.

[BubbaTough]

Zach,

Is a threat move just the best move from the null search? Which if you don't do anything special becomes your killer move?

-Sam

Yeah, it's the null move refutation. It's tried on the next ply after the hash move if it's legal.

So I guess the threat move is the same as the killermove for the move tried (except if you don't use captures and such as killer moves) but is different (and better?) when the killer move gets replaced?

-Sam

[bob]

A question to those that do not (always) do IID:

If the (non-null) hash move (searched first) fails low, do you still search a null move afterwards? The fact that you had a non-null hash move must mean that the null move failed low before, in this position.

OTOH, beta might be lower now than it was the previous time you tried the null move, and the hash move might fail low because it is a poor move that took some depth to refute. If you don't ever retry the null move, it can never become hash move again, even if it deserves to be so. Plus, the null move might be a cheap way to find a killer relevant for the next level, e.g. if the hash move was withdrawing a hanging piece, but to a poorly chosen refuge.

I search null-move first, not after the hash move...

[bob]

I also try a null move regardless of what is in the hash, always before a real move.

Do I understand correcty from this that you try the null move before the hash move? That sounds like a waste of time, as normally you would expect the hash move to be good. So killers on the next level would be to no avail for the hash-move search, they would be tried in an all-node.

Or don't you consider the hash move a real move?

The null-move should always be searched first. That is the entire idea, that the reduced-depth null-move gives a quick cutoff before any full-depth search is done...

[hgm]

I don't think it is a waste of time, in fact you're the only person I know of that doesn't do this.

Well, uMax searches null move before hash move, but I always thought this was a built-in inefficiency because of the way it has to sneak in the hash move between the generated moves.

The hash move is expected to be good, but the null move is cheaper. In fact the hash move should be better than the null move in virtually all positions (sans zugzwang). Since the null move is never stored as the best move,

Now I am confused, as I remember having this discussion with Bob some years ago, who at the time was strongly advocating erasing a pre-existing hash move by a null move. So I had the impression that storing null moves as hash move was common practice.

we can't logically assume that the hash move is a better move to try (i.e. we can't assume the null move failed low before, because the score in the hash and the move might come from different searches).

How do you get a non-null hash move if the null move has always failed high?

I'm not sure what you mean about the killers on the next ply. Once the null move has been tried and failed, it's quite possible that the move is an all node. The hash move does indicate that it got a score > alpha at some point, but we don't know it will happen now. Anyways, I'm not sure why killers are relevant here anyways, I wasn't talking about them. Perhaps you meant the threat move?

Sam equated the threat move to a later killer move, and I simply used hs terminology.

If beta > 0, the most common reason the null move fails low is a simple threat against one of your pieces, which is usually easy to evade. The case where it really is an all node is fairly rare, as in cut-nodes you are playing an opponent who tries anything, and most of what can be tried is not very subtle, or even outright stupid. When eval < beta I don't even try the null move, (in Joker) as the opponent is going to refute it by standing pat for some depths to come.

If so, that is kept for all moves on the next ply, so, assuming that the current node is an all node (since the null move failed low), then the threat move could help refute the hash move and every other move after it.

The refutation of the null move is very unikely to be a refutation of the hash move. If you have a real threat against you, the hash move must somehow solve it, or it could not have failed high before.