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

[Uri Blass]

Is this just a random thing you want to try or why do you think this is a good idea ?

Exactly what i felt, a random idea that probably needed a little bit of thinking before sharing. 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 ?

The problem is that it may be annoying if in specific position the BF is very high.

I play correspondence chess and give houdini3 hours to analyze.
For example
I got the following picture after 150,000,000,000 nodes(houdini did not change the suggested move Bf1-e2).

I need to decide if to continue to analyze or to stop to analyze at iteration 31.

28/58 35:19 9,054,384,720 Bf1-e2....
29/59 48:18 12,364,785,832 Bf1-e2....
30/64 3:36:54 56,236,659,223 Bf1-e2....



The main problem is that I am not sure
about the time that I need to get a pv for the root move at iteration 31.

If the time is too big then I prefer to have the option to tell houdini to stop the search and search other moves at depth 31 when it is going to search
later at iteration 32(if I get there) Bf1-e2 with the same depth that it failed to search at iteration 31.

[Uri Blass]

a possible modification of the idea may be to allow using more nodes only if you saved them earlier.

meaning for example that if you spend 1,000,000 nodes
for the first 4 moves at iteration 20 then you are allowed to spend
not more than 10,000,000 nodes for the first 4 moves at iteration 21 and
if you cannot do it then you simply skip the 4th move at iteration 21 and reduce it at iteration 22(note that at iteration 22 you may do a research of the 4th move to depth 22 in case that you have enough time but you first reduce it to depth 21).

[Daniel Shawul]

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 ?

[Uri Blass]

Note that I did not claim that the BF is 10 on average.
I know that in most of the cases it is less than 10 and my idea is to skip moves in the rare cases when it is not less than 10 and to search them again (with reduced depth first) in the next iteration.

I admit that practically my idea(in the way that I suggested) is going to skip some moves also even if the branching factor is 2 as bob showed
so it is better to use a set of moves and in the case of Bob there is not going to be skipping after my modification because he had at one iteration

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

and in the next iteration

Qe3 227940945 0 0
Bxb4 19828167 0 1


Now
227940945<171556994*10 so no skipping
227940945+19828167<171556994*10+2325729*10 so again no skipping.

basically you check after 171556994*10 nodes if you searched the first move
If you finish then no skipping.
you check after (171556994+2325729)*10 nodes if you finished to search
the first 2 moves
if you finished to do it then no skipping and you continue in that way.

Uri

[ZirconiumX]

I may be having a stupid moment - but why couldn't you try performing fail high reductions if the move was 10x more nodes - the idea being that a good line would be extended to the original depth (or further)?

Matthew:out

[bob]

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.

[bob]

I wonder if there is some engine that use the following idea.

For every root move at iteration n use no more than 10 times the number of nodes that you used at iteration n-1 for the same root move.

If you do not find a score for a root move simply skip that move and remember to reduce the depth in the next iteration.

Of course you can replace 10 by a different number.

When you are going to "change your mind" at some depth, THAT move is guaranteed to produce a tree > 10x larger than on the previous iteration. So you would give up rather than changing to the new (better) move.

I give up changing my mind only in the specific iteration
I still can change the move in the next iteration when I allow again a tree that is 10x larger than the previous iteration.

The point is that if the pv is move A and searching move B takes a long time then maybe it is better idea to skip B in the relevant iteration
and look at other moves(because you may change your mind to move C faster).

Problem I see is that it gets harder and harder to change your mind (harder in terms of search effort required). If you COULD change it this iteration, but quit early and go on to the next, it will be much harder there and take even longer.

[Daniel Shawul]

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.

[syzygy]

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:

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?

[bob]

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.

Read what I wrote and what you wrote. I said that a move being 10x larger than the previous iteration is COMMON. You said it was not, it would imply a branching factor of 10x. That is wrong. And you are right, there is NO point in arguing with you.