having a maximal number of nodes to search for root moves.

Discussion of chess software programming and technical issues.

Moderator: Ras

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: having a maximal number of nodes to search for root move

Post by bob »

syzygy wrote:
Daniel Shawul wrote:
bob wrote:
Daniel Shawul wrote:He said a move taking 10x as much nodes at iteration n than it did at n-1. That could only mean your BF is 10 on average. So focus on that.
Edit
As far as comparing two successive iterations, which the above doesn't show, here's a couple of numbers

Code:

Qe3 227940945 0 0
Bxb4 19828167 0 1


From the previous iteration:

Code:


Qe3 171556994 0 0
Re8 2325729 0 1
Rd8 1817427 0 1
Rf8 1815718 0 1
Bxb4 1716974 0 1


Bxb4 went from 1.7M nodes to 19.8M in one iteration. Other's changed also, to keep the low effective branching factor...
There Qe3 growth is not even remotely close to 2, which the most contributor to the overall growth. Now for Bxb4 took more nodes because it is probably a good move. This is not a common behaviour for all moves. And you want to reduce that ?
No, and that was my point. THAT move is likely to become a "best move" in an iteration or two. That's why it is growing at a rate far beyond the normal effective branching factor of 2 or so.

Just because ONE move sees its node count increase by 10x does not come close to suggesting that the overall effective branching factor is 10x.
Your point to whom, yourself? I thought you brought an example to refute what I said which is :
For one you never spend 10x as much on a move on the next iteration with the current BFs we have. If it did it means it is probably a good move that will fail high, and we reduce that ?
Such a waster of time arguing with you.
Care to explain what you meant by:
Daniel Shawul wrote:He said a move taking 10x as much nodes at iteration n than it did at n-1. That could only mean your BF is 10 on average. So focus on that.
If a move takes 10x as many nodes at iteration n as it did at n-1 (i.e. one single move at one single value of n), that means that the effective branching factor is 10, so the programmer should focus on getting it below 2?

I thought that's what you were trying to say, but apparently we are misunderstanding you?
The effective branching factor for the TREE is significantly different from the effective branching factor of any one move. Should that one move happen to be the first, then yes, the EBF is going to go up, because normally the first move is far bigger than the rest (in node count). But if you watch, as I do (since Crafty can display this data easily) different moves have different delta changes. Some actually get SMALLER the next iteration, some don't change, and some get bigger. It is the overall effect that needs to remain as low as possible, not each individual move.