Hey all.
My program does not have a seperate root search and I have noticed that the root node is an 'All node'.
Is this always going to be the case ?
Can I change/improve this ?
Laurie (LTchess)
Root Moves
Moderators: hgm, Rebel, chrisw
-
hgm
- Posts: 27796
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Root Moves
If you use an aspiration window the root can be a cut-node. Of course that means you then have to re-search it with a larger window. So in the end it must be an all-node. If you don't search all moves in the root, you could overlook the best move. There is no way to know if it is best if you don't search it.
If there are enough things you do differently in the root, it could be a reason for making a separate routine for it. Aspiration could be one such thing. Some people also use different move sorting in the root, e.g. by number of nodes in the previous iteration. The idea is that the closer a low-failing move is to alpha, the more difficult it will be for the search to find the opponent cut-moves that push it below alpha, so the larger the tree will be. Some engines create non-determinism by randomizing the initial move order in the root.
In principle a root node is not very different from other PV nodes, so what is good for the root is also likely good for any PV node. But a practical problem is that while in the root subsequent depth iterations follow each other without ever leaving the root, this is not true for deeper PV nodes. So you would only be able to uses node-count-based sorting if you would remember the node counts from the previous iteration despite the fact that you returned from the node. You could use a tri-angular array of move lists for that.
If there are enough things you do differently in the root, it could be a reason for making a separate routine for it. Aspiration could be one such thing. Some people also use different move sorting in the root, e.g. by number of nodes in the previous iteration. The idea is that the closer a low-failing move is to alpha, the more difficult it will be for the search to find the opponent cut-moves that push it below alpha, so the larger the tree will be. Some engines create non-determinism by randomizing the initial move order in the root.
In principle a root node is not very different from other PV nodes, so what is good for the root is also likely good for any PV node. But a practical problem is that while in the root subsequent depth iterations follow each other without ever leaving the root, this is not true for deeper PV nodes. So you would only be able to uses node-count-based sorting if you would remember the node counts from the previous iteration despite the fact that you returned from the node. You could use a tri-angular array of move lists for that.