All and Cut nodes

Code, algorithms, languages, construction...
lucasart
Posts: 201
Joined: Mon Dec 17, 2012 1:09 pm
Contact:

All and Cut nodes

Post by lucasart » Sat Jan 12, 2013 11:57 am

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.
"Talk is cheap. Show me the code." -- Linus Torvalds.

lucasart
Posts: 201
Joined: Mon Dec 17, 2012 1:09 pm
Contact:

Re: All and Cut nodes

Post by lucasart » Thu Feb 28, 2013 3:53 pm

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

:|
"Talk is cheap. Show me the code." -- Linus Torvalds.

hyatt
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

Post by hyatt » Thu Feb 28, 2013 7:34 pm

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.

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: All and Cut nodes

Post by BB+ » Thu Feb 28, 2013 11:43 pm

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. :cry:

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. :lol:

lucasart
Posts: 201
Joined: Mon Dec 17, 2012 1:09 pm
Contact:

Re: All and Cut nodes

Post by lucasart » Fri Mar 01, 2013 2:15 pm

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.
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.

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.

hyatt
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

Post by hyatt » Fri Mar 01, 2013 6:41 pm

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...

lucasart
Posts: 201
Joined: Mon Dec 17, 2012 1:09 pm
Contact:

Re: All and Cut nodes

Post by lucasart » Sat Mar 02, 2013 2:45 am

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.
Same in DiscoCheck.
hyatt 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 have a slightly more subtile condition at non PV nodes. Rather than simply skipping IID at non PV nodes, I use the following conditions
(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.

lucasart
Posts: 201
Joined: Mon Dec 17, 2012 1:09 pm
Contact:

Re: All and Cut nodes

Post by lucasart » Fri Apr 12, 2013 2:44 pm

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.

hyatt
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

Post by hyatt » Fri Apr 12, 2013 6:11 pm

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...

lucasart
Posts: 201
Joined: Mon Dec 17, 2012 1:09 pm
Contact:

Re: All and Cut nodes

Post by lucasart » Sat Apr 13, 2013 12:41 am

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...
Experiment: Because not doing it scores slightly (but significantly) worse.
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.

Post Reply