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

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
MahmoudUthman
Posts: 234
Joined: Sat Jan 17, 2015 10:54 pm

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

Post by MahmoudUthman » Sat Jan 21, 2017 6:01 pm

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 ?

User avatar
Evert
Posts: 2923
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

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

Post by Evert » Sat Jan 21, 2017 7:37 pm

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
Posts: 1420
Joined: Thu Mar 30, 2006 12:08 pm
Contact:

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

Post by mjlef » Sat Jan 21, 2017 9:38 pm

Evert wrote: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.

User avatar
Evert
Posts: 2923
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

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

Post by Evert » Sat Jan 21, 2017 10:24 pm

mjlef wrote: 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
Posts: 1420
Joined: Thu Mar 30, 2006 12:08 pm
Contact:

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

Post by mjlef » Sun Jan 22, 2017 3:05 am

Evert wrote:
mjlef wrote: 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
Posts: 234
Joined: Sat Jan 17, 2015 10:54 pm

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

Post by MahmoudUthman » Sun Jan 22, 2017 7:08 am

Evert wrote: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
Posts: 813
Joined: Mon Jan 15, 2007 10:23 am
Location: Warsza
Contact:

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

Post by PK » Sun Jan 22, 2017 7:58 am

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
Posts: 9894
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

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

Post by Dann Corbit » Mon Jan 23, 2017 2:55 pm

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?
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
hgm
Posts: 23455
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

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

Post by hgm » Mon Jan 23, 2017 3:08 pm

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

Post Reply