Author: Uri Blass
Date: 13:47:44 09/06/02
Go up one level in this thread
On September 06, 2002 at 16:25:11, Robert Hyatt wrote: >On September 06, 2002 at 15:47:24, Uri Blass wrote: > >>On September 06, 2002 at 14:42:02, Robert Hyatt wrote: >> >>>On September 06, 2002 at 13:33:29, Vincent Diepeveen wrote: >>> >>>>On September 05, 2002 at 14:06:08, Eugene Nalimov wrote: >>>> >>>>>Actually, often you don't want to search the objectively best move first. You >>>>>want to search the move that will cause a beta cutoff and will result in a >>>>>smallest subtree being searched. >>>> >>>>Not really, the best move is usually best, because usually the >>>>problem of *a move* cutting off is shown next iteration by major >>>>overhead. So at this iteration i a move could cutoff in very little >>>>nodes, but if it next iteration fails low it obviously is a whole >>>>subtree you researched. >>> >>> >>>Would you _please_ think a bit before jumping in? Eugene's statement is a >>>direct premise of any tree searching program based on alpha/beta. Do the >>>least amount of work possible. Given a set of N moves that will produce a >>>cutoff (fail high) and another set M that will not... If you search any moves >>>in M first, you waste time and effort and slow down. If you search any move in >>>N you get a cutoff and are done. How can it _not_ be best to pick the one that >>>requires the least effort to fail high? Because once you fail high at a node, >>>you are _finished_ there.. >> >>If this iteration is the last iteration you are right. >>The point is that if the iteration is not the last iteration you may prefer >>to have a move with bigger tree if it means that the tree for the same position >>is smaller in later iterations. > > >I disagree based on the "bird in the hand" proverb. > >I have a "bird in the hand"... I can cause a cutoff with minimal work. > >I have "two birds in the bush"... I will do a bit more work now and _might_ >get a hash hit the next iteration that will save a little more. > >Serendipity is not a good neighbor in computer chess. Otherwise there are >probably _lots_ of things you could do _now_ to make the next iteration go >faster. If you can get there... I agree that it is not clear what is better. It is only a possibility that it is better to prefer the bigger tree. The main test is simply times. You can decide that you search the bigger tree only at small depths(depth<8). If you can get at depth 10 less nodes than it suggest that searching the bigger tree at small depthes may be better. I did not investigate better order of moves so I do not know but it is not something clear that the smallest tree must be the best. Today I do not use an estimate of the size of the tree for order of moves in movei and I have things that i consider as more important to do first Uri
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.