What is wrong with doing Nulls & ttcuts in a pv node ?

[MahmoudUthman]

stock fish doesn't do Null move pruning -"it looks like the only type of early pruning it does in PV nodes is futility"- or TTcuts in PV nodes , why is that ?

[Evert]

There may be two reasons for not taking tt cut-offs at PV nodes: not doing it ensures that you can return the full PV, and if the pruning decisions are based on node-type, then accepting cut-offs from entries with the wrong node-type causes search inconsistensies. If you only base pruning decisions on depth, then you can always accept a TT entry with adequate depth. Otherwise you need to make sure node types match. In non-PV nodes, you would accept PV node results (which should be more accurate, or at least not less accurate), but not the other way around. A good approximation is to not accpt cut-offs in PV nodes, which are rare anyway.

Doing a null-move in a PV node is fine, but pointless: it's not expected to produce a cut-off.

[mjlef]

There may be two reasons for not taking tt cut-offs at PV nodes: not doing it ensures that you can return the full PV, and if the pruning decisions are based on node-type, then accepting cut-offs from entries with the wrong node-type causes search inconsistensies. If you only base pruning decisions on depth, then you can always accept a TT entry with adequate depth. Otherwise you need to make sure node types match. In non-PV nodes, you would accept PV node results (which should be more accurate, or at least not less accurate), but not the other way around. A good approximation is to not accpt cut-offs in PV nodes, which are rare anyway.

Doing a null-move in a PV node is fine, but pointless: it's not expected to produce a cut-off.

You certainly can do nullmove searches around beta in PV nodes. If the search fails high, you get a cutoff (just like any other PV node failing high). So it would not shorten the PV at all.

The main reason to not do them is it has (so far) not tested as well. Nullmove searches suffer from zuqzwang issues (even with verification searches) as well as the basic inaccuracy of reducing the search depth greatly. But perhaps you can come up with ways to make them gain strength.

[Evert]

You certainly can do nullmove searches around beta in PV nodes. If the search fails high, you get a cutoff (just like any other PV node failing high). So it would not shorten the PV at all.

Never said it does.
You can certainly do a null-move search in a PV-node, but they're not as useful because typically the goal is not to get a quick cut-off, but to get a score between alpha and beta. If the null-move doesn't produce a cut-off, fine, but you wasted time. If it does then whether it's worth it or not depends on how reliable the null-move search is. I think testing has shown that it's a waste of time. I seem to recall that there's a logical reason to expect this to be the case too, but I can't reconstruct the argument now.
It probably also depends on aspiration search and how you treat null-move refutations.

[mjlef]

You certainly can do nullmove searches around beta in PV nodes. If the search fails high, you get a cutoff (just like any other PV node failing high). So it would not shorten the PV at all.

Never said it does.
You can certainly do a null-move search in a PV-node, but they're not as useful because typically the goal is not to get a quick cut-off, but to get a score between alpha and beta. If the null-move doesn't produce a cut-off, fine, but you wasted time. If it does then whether it's worth it or not depends on how reliable the null-move search is. I think testing has shown that it's a waste of time. I seem to recall that there's a logical reason to expect this to be the case too, but I can't reconstruct the argument now.
It probably also depends on aspiration search and how you treat null-move refutations.

You might be surprised how many fail high (beta) cutoffs you get in PV nodes. I often meter my chess programs to record this kind of thing.

[MahmoudUthman]

There may be two reasons for not taking tt cut-offs at PV nodes: not doing it ensures that you can return the full PV, and if the pruning decisions are based on node-type, then accepting cut-offs from entries with the wrong node-type causes search inconsistensies. If you only base pruning decisions on depth, then you can always accept a TT entry with adequate depth. Otherwise you need to make sure node types match. In non-PV nodes, you would accept PV node results (which should be more accurate, or at least not less accurate), but not the other way around. A good approximation is to not accpt cut-offs in PV nodes, which are rare anyway.

Doing a null-move in a PV node is fine, but pointless: it's not expected to produce a cut-off.

so If I add a field in TTEntry that indicate the node search origin (PV,NotPV) , would it be worth it to use TTCuts PV nodes , assuming I don't care about the full PV ?

[PK]

Code: Select all

so If I add a field in TTEntry that indicate the node search origin (PV,NotPV) , would it be worth it to use TTCuts PV nodes , assuming I don't care about the full PV ?

as usually, do whatever tests best. another way of doing what You want is accepting TT cutoffs in pv only if score >alpha and score < beta. By definition it cannot happen in zero window node which always fails one way or the other.

[Dann Corbit]

From a logical standpoint:
Your pv is your plan of action.
Why will you reduce your search effort, in the line that you plan to actually play?

[hgm]

But why would you do it again, if you have already done it before?