Author: Severi Salminen
Date: 09:27:30 02/02/02
Go up one level in this thread
>I will try to make it clearer. Most program only look at capture moves first and >if there are more than one capture then they sort them according to the value of >the piece captured. But not in the root node. In root node (ply=0) most programs sort all the moves based on the node count on previous iteration (PV move is the first). >What I was trying to explain is this: >At ply 0 generate all possible moves captures and others and then sort them >according to their weights. The non capture moves will contain points from the >value for center control etc. There fore you have all moves generated from the >frist ply with their respective weights. >At ply 1, repeat the above process. By doing it this way, you do not have to go >back and generate other moves after all of the captures have been tried. I didn't probably understand correctly, what do you mean by "you do not have to go back and generate other moves after all the captures have been tried"? A few points: 1. In root node your weighting method doesn't sound very promising. Because we will do a 10+ ply search, weighting root moves based on center control is _very inaccurate_. The real order won't be near the weighted order. 2. In other plies there is no point generating and sorting like in root node. Most likely we'll get a cutoff from the 1st move tried (hash move, positive captures based on SEE...). So no point generating all the moves. 3. I don't understand why would you have to "generate other moves.." in root. We create then once and then go through that move list and order it after every iteration. It doesn'treally matter if you generate then every timeor not 0.0000000001% of the total search effort... Severi
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.