All and Cut nodes
All and Cut nodes
Currently, I only use PV and nonPV nodes, and do not distinguish the 'All' and 'Cut' ones from my non PV nodes. But I'm wondering if this distinction can be useful.
From your experience, what kind of things are worth experimenting with distinguishing all and cut nodes. For example, does it work to have a different min depth and reduction for IID between 'All' and 'Cut' nodes, and same question for Null move.
From your experience, what kind of things are worth experimenting with distinguishing all and cut nodes. For example, does it work to have a different min depth and reduction for IID between 'All' and 'Cut' nodes, and same question for Null move.
"Talk is cheap. Show me the code." -- Linus Torvalds.
Re: All and Cut nodes
Is this forum dead or what ?
I just wanted to compare, so I sent the same question on talkchess.com, and got plenty of answers in a few hours, (almost) all of which were intelligent and instructive:
http://talkchess.com/forum/viewtopic.php?t=46854
I just wanted to compare, so I sent the same question on talkchess.com, and got plenty of answers in a few hours, (almost) all of which were intelligent and instructive:
http://talkchess.com/forum/viewtopic.php?t=46854
"Talk is cheap. Show me the code." -- Linus Torvalds.
-
- Posts: 1242
- Joined: Thu Jun 10, 2010 2:13 am
- Real Name: Bob Hyatt (Robert M. Hyatt)
- Location: University of Alabama at Birmingham
- Contact:
Re: All and Cut nodes
lucasart wrote:Is this forum dead or what ?
I just wanted to compare, so I sent the same question on talkchess.com, and got plenty of answers in a few hours, (almost) all of which were intelligent and instructive:
http://talkchess.com/forum/viewtopic.php?t=46854
I missed the question. My answer, however, is that I don't make any distinction. I consider PV to be any node where alpha < beta-1 (there is no null-window in effect). Beyond that, I don't distinguish. I attempt to recognize ALL nodes for splitting, but only via the YBW criterion that at least one move has been searched with no fail high.
Re: All and Cut nodes
I misunderstood the inquiry. The "From your experience" line made me think you wanted something beyond anecdotes, data-less argumentation (however good or bad), and/or info you could get from CPW. Actually, this is something that I find more and more about technical discussions, lots of pontificating about ideas or why something should/does work, but often little concrete. To me, the signal-to-noise ratio is often rather low, even if the noise has a technified aura. I've also found that I tend to be wrong when I open my mouth w/o evidence to back it up.
Anyhow, here are possibly related links:
http://www.open-aurec.com/wbforum/viewt ... f=4&t=6392
http://www.open-aurec.com/wbforum/viewt ... f=4&t=4384
http://www.talkchess.com/forum/viewtopic.php?t=38408
The first discusses Null Move pruning, the last discusses IID, exactly the issues you raised. The other deals with move ordering and cut-off percentages, similar to what your TalkChess thread also mentioned.
OK, so maybe I'm too much of an academic, who can only cite what has been said, rather than say anything new.
Anyhow, here are possibly related links:
http://www.open-aurec.com/wbforum/viewt ... f=4&t=6392
http://www.open-aurec.com/wbforum/viewt ... f=4&t=4384
http://www.talkchess.com/forum/viewtopic.php?t=38408
The first discusses Null Move pruning, the last discusses IID, exactly the issues you raised. The other deals with move ordering and cut-off percentages, similar to what your TalkChess thread also mentioned.
OK, so maybe I'm too much of an academic, who can only cite what has been said, rather than say anything new.
Re: All and Cut nodes
In the meantime, I've experimented with it, and I came to the same conclusion than you. I couldn't improve my program in any (measurable) way by treating All and Cut nodes differently.hyatt wrote:lucasart wrote:Is this forum dead or what ?
I just wanted to compare, so I sent the same question on talkchess.com, and got plenty of answers in a few hours, (almost) all of which were intelligent and instructive:
http://talkchess.com/forum/viewtopic.php?t=46854
I missed the question. My answer, however, is that I don't make any distinction. I consider PV to be any node where alpha < beta-1 (there is no null-window in effect). Beyond that, I don't distinguish. I attempt to recognize ALL nodes for splitting, but only via the YBW criterion that at least one move has been searched with no fail high.
The only thing that was an improvement is to have an IID precondition that is different between Cut and All nodes. But that's not really treating the nodes differently, rather a speed optimization (on averageIID is more likely to be useful at a predicted Cut node than at a predicted All node).
But some engine authors did manage to get measurable improvements (including Robert Houdart) by treating All and Cut nodes differently. I've tried to use different reduction formula for example, but that didn't work for me
PS: As for splitting, I have no idea. I never even got started with SMP...
"Talk is cheap. Show me the code." -- Linus Torvalds.
-
- Posts: 1242
- Joined: Thu Jun 10, 2010 2:13 am
- Real Name: Bob Hyatt (Robert M. Hyatt)
- Location: University of Alabama at Birmingham
- Contact:
Re: All and Cut nodes
My exceptions (from memory) are:
(1) no null-move if alpha < beta-1, which is a RARE condition in PVS. Since in such positions I am hunting for a PV, a null-move is not legal and I avoid trying them.
(2) IID is ONLY done in nodes where alpha < beta-1 and I have no hash move. Ordering there is important enough to spend the IID time necessary. In other nodes, no. And in ALL nodes it would be pointless since everything has to be searched anyway...
(1) no null-move if alpha < beta-1, which is a RARE condition in PVS. Since in such positions I am hunting for a PV, a null-move is not legal and I avoid trying them.
(2) IID is ONLY done in nodes where alpha < beta-1 and I have no hash move. Ordering there is important enough to spend the IID time necessary. In other nodes, no. And in ALL nodes it would be pointless since everything has to be searched anyway...
Re: All and Cut nodes
Same in DiscoCheck.hyatt wrote: (1) no null-move if alpha < beta-1, which is a RARE condition in PVS. Since in such positions I am hunting for a PV, a null-move is not legal and I avoid trying them.
I have a slightly more subtile condition at non PV nodes. Rather than simply skipping IID at non PV nodes, I use the following conditionshyatt wrote: (2) IID is ONLY done in nodes where alpha < beta-1 and I have no hash move. Ordering there is important enough to spend the IID time necessary. In other nodes, no. And in ALL nodes it would be pointless since everything has to be searched anyway...
(i) depth >= (node_type == PV ? 4 : 7)
(ii) node_type != All || eval+pawn >= beta
In other words
- PV nodes: perform IID whenever depth >= 4
- Cut nodes: perform IID whenever depth >= 7
- All nodes: perform IID whenever depth >= 7 and eval+pawn >=beta
"Talk is cheap. Show me the code." -- Linus Torvalds.
Re: All and Cut nodes
I've just found that it's better (at least in DiscoCheck) to only perform razoring at All nodes. And it makes a lot of sense too! But don't expect a big elo jump from that, as razoring itself isn't worth much anyway.
"Talk is cheap. Show me the code." -- Linus Torvalds.
-
- Posts: 1242
- Joined: Thu Jun 10, 2010 2:13 am
- Real Name: Bob Hyatt (Robert M. Hyatt)
- Location: University of Alabama at Birmingham
- Contact:
Re: All and Cut nodes
why would you do IID at an ALL node in the first place? By definition, at an ALL node, move ordering is completely irrelevant and you have to search ALL moves before you are done...
Re: All and Cut nodes
Experiment: Because not doing it scores slightly (but significantly) worse.hyatt wrote:why would you do IID at an ALL node in the first place? By definition, at an ALL node, move ordering is completely irrelevant and you have to search ALL moves before you are done...
Theory: Because sometimes a *predicted* All node fails high. And in that case, if we don't have a TT move, having a sub-optimal move first at a high search depth can be quite costly. These cases are not so rare.
"Talk is cheap. Show me the code." -- Linus Torvalds.