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

[Uri Blass]

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.

[tpetzke]

Hi,

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

Usually if I find my engine suddenly stuck at a move this is because it is starting to smell something like a move or response that is was considering good before starts to turn out bad.

So if the first move you search (the best one from the previous iteration) takes you to long, you want to abort that search and just take the 2nd one from the list? This is a move which you probably not even have an exact score from and you have probably less entries for that branch in your TT than for the first. So chances are this will take even longer or being bad and not solving the problem the 1st one spotted.

You might end up finishing no moves at all or only search the bad ones that are solved really quick.

Thomas...

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

[Uri Blass]

Hi,

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

Usually if I find my engine suddenly stuck at a move this is because it is starting to smell something like a move or response that is was considering good before starts to turn out bad.

So if the first move you search (the best one from the previous iteration) takes you to long, you want to abort that search and just take the 2nd one from the list? This is a move which you probably not even have an exact score from and you have probably less entries for that branch in your TT than for the first. So chances are this will take even longer or being bad and not solving the problem the 1st one spotted.

You might end up finishing no moves at all or only search the bad ones that are solved really quick.

Thomas...

No
I did not suggest to change the move but only to skip the move in the iteration when it takes too long(meaning that the pv is the same and the best move from previous iteration is not going to be changed).



Example
suppose at iteration 9 you search 10000 nodes after 1.e4 and 2000 nodes after 1.d4(1.e4 is the move the computer want to play)
suppose the exact score of the computer is 0.1 pawns for white

Supoose that at iteration 10 you search 100,000 nodes for 1.e4 without finding a new pv.

You keep the 0.1 pawns for white as the score for 1.e4 and continue to search other moves(assuming no change in the score for 1.e4)

you remember the following for iteration 11:

1)You need to reduce the depth after e4 by 1.
2)You are not going to use more than 1000,000 nodes for 1.e4 at iteration 11(because you already search 100,000 nodes at iteration 10).

[Houdini]

I did not suggest to change the move but only to skip the move in the iteration when it takes too long(meaning that the pv is the same and the best move from previous iteration is not going to be changed).

This will probably be counter-productive.
Moves that require many nodes are usually the best candidates for improving the score. It's probably not a good idea to prune or reduce these.

[Uri Blass]

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

[Uri Blass]

I did not suggest to change the move but only to skip the move in the iteration when it takes too long(meaning that the pv is the same and the best move from previous iteration is not going to be changed).

This will probably be counter-productive.
Moves that require many nodes are usually the best candidates for improving the score. It's probably not a good idea to prune or reduce these.

The problem is that you may suspect that you simply do not have the time for improving the score and this is a reason to skip the move.

The fact that in theory you could improve the score by searching a tree that is 1000 times bigger(after the root move relative to previous iteration) does not help you if you have no time to search a tree that is 1000 times bigger.

[Houdini]

The problem is that you may suspect that you simply do not have the time for improving the score and this is a reason to skip the move.

The fact that in theory you could improve the score by searching a tree that is 1000 times bigger(after the root move relative to previous iteration) does not help you if you have no time to search a tree that is 1000 times bigger.

It's legitimate to stop the search when you run out of time, but otherwise you gain nothing by pruning a move that is very promising, or by reducing this move in the next iteration. You should do the opposite, in fact.

[Daniel Shawul]

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 ?

[bob]

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 ?

actually, 10x is easy. Just count the nodes for each root move. You might see something like this, which comes from crafty with "display nodes" command:

Code: Select all

       move       nodes     R/P
        Qe3   227940945     0 0
       Bxb4    19828167     0 1
        Be7     9474981     0 1
        Re8     4665747     0 1
        Rd8     4145762     0 1
        Rf8     1745573     0 1
        Rb7      954240     0 1
         h5      521544     1 1
        Bf8      456157     1 1
        Kg8      321405     1 1
        Qd4      175594     1 1
        Bc7      157246     1 1
        Rg8      142976     1 1
         g6      108041     1 1
         g5       97176     1 1
        Ra8       79564     1 1
        Ke7       49183     1 1
        Kf8       45478     1 1
        Qc5       30672     1 1
        Qd8       29689     1 1
        Bc5       27093     1 1
        Rh8       24069     1 1
        Qa5       14678     1 1
        Rc8       13491     1 1
       Qxc6        9909     1 1
        Qa7        9536     1 1
       Qxa6        8833     1 1
        Qc7        7934     1 1
       Qf2+        7022     1 1
       Qg1+        6626     1 1
        Qb7        5795     1 1

10x is a TINY difference when you look at the above numbers. 10x is the difference between the first move and the second. Others are bigger. MUCH bigger.

As far as comparing two successive iterations, which the above doesn't show, here's a couple of numbers

Code: Select all

        Qe3   227940945     0 0
       Bxb4    19828167     0 1

From the previous iteration:

Code: Select all

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