On Mon, Jun 14, 2010 at 5:40 PM, Richard Brown <[email protected]> wrote: > On Mon, Jun 14, 2010 at 3:59 PM, Mark Boon <[email protected]> wrote: > >> But I'm not sure how the method you're describing is any different >> from what old programs like Goliath used to do. > > There's a step in pattern recognition called "feature extraction", where you > decide what information to encode, and how to scale that info so that you > get a useful way of representing features that you want to represent. At > the same time, some information must be discarded. (Unless each of > your patterns represents a total board state!) > > I'm sure you already knew that. > > So, while there might not be a difference in _what_ the old programs > used to do and in _what_ Tim's approach does, there could yet be a > difference in _how_ it's done. That is, perhaps there is some clever > representation of a behavior in go, for which we may select and encode > and scale various features, and also for which we may discard much > unnecessary or redundant information, with the end-result that _my_ > patterns take more into account (and hence are more useful) than your > patterns did, back in the old days. > > Which is to say, the "feature extraction" phase may be the crucial phase. > > I can't speak for Tim Maguire, but I share his suspicion that Monte Carlo > may not be the best way to achieve dan-level play. > > I believe (and hope to someday demonstrate, but there's still a lot of work > to be done) that dan-level programs will _severely_ prune the game-tree > via the use of pattern-classification, and then use simple minimax on the > remaining candidate moves (as Tim described). (One could also use a > Monte-Carlo layer in the program, but with this severely-pruned tree, > minimax is probably "enough".) > > The tricky parts are: 1) Extracting just those features we want (and throwing > others away as unnecessary or redundant), and 2) being able to compare an > arbitrary pattern to others that we may have seen in the past (likely, during > observation of professional games, as that is the behavior we wish to > emulate). > > -- > Rich
I won't say that this type of approach won't work. But, after many years of people trying precisely that type of thing and not getting strong programs, I will wait to get excited until the program gets a good rating in cgos. About the effective search depth idea that this thread is supposed to be about, I don't understand what it's supposed to be for... Álvaro. _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
