Author: Robert Hyatt
Date: 08:16:37 06/01/00
Go up one level in this thread
On June 01, 2000 at 00:50:28, blass uri wrote: >On May 31, 2000 at 17:47:13, Robert Hyatt wrote: ><snipped> >>That is an _impossible_ question to answer without searching all the moves. >>Then you can find the move that (a) causes a cutoff and (b) searches the >>smallest number of nodes to do so. >> >>What you are asking for is impossible to provide. To discover which of two >>moves will produce the smallest search tree while providing a score >= X >>requires that I search _both_ and then choose. But I don't need to search both. >> >>It is an unrealistic goal to add "with the least amount of work" to the >>requirement that "In an optimally ordered tree, we require that any move that >>causes a cutoff be the first move searched." (not "the first move searched >>which also is the easiest one to search.") > >I agree it is unrealistic to get optimally ordered tree by my definition(it is >also unrealistic to get 100% of the times cutoff in the first move) but it may >be realistic tp change the order of moves and get a smaller tree without getting >more times cutoff in the first move and my point is that the definition of >better order of moves should be defined by the size of the tree. > >It is possible to check the number of nodes that you need to get the same depth. >If you need less nodes to get the same depth after a change in the order of >moves you have better order of moves. > >Uri I understand what you are saying, but here is the problem: In a typical search, playing 40/2hr games, Crafty is going to search around 300M nodes to make up its mind on a particular move. What can it use, at each of those 300M positions, to choose the particular move that leads to the smallest tree to cause a cutoff here? _that_ is the serious problem I see. That is a big tree. Scattered over a _large_ landscape. I certainly don't want to do multiple searches. About the only idea I could think of is a 'cyclical best-move finder' that would search (this time) with move A, but next time we reach this position, we don't try A (even though it caused a cutoff last time) we try B instead, which also looks decent. We could "learn" the best move to try (perhaps) although the complexity makes me wonder if it is worthwhile. And the overall tree size would definitely get larger a good bit of the time. It is _always_ a good idea to try the same move whenever possible because of the trans/ref table.
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.