I'm not expert on decision theory, but it's my understanding that borda counting or voting is excellent way to integrate different decision making agents. Of course this depends a lot on the nature of the decision to be made, but if you have N choices and several agents that are capable of ranking those choices, the whole is greater than the sum of the parts.
One of my first primitive MC programs evolved moves using genetic algorithms. I discovered it worked surprisingly better to evolve a handful of players and borda vote the best choice. It was surprisingly the best use of resources I could find, based on a simple evolution strategy that is. I don't really understand why it worked so well. I think it is because any particular playing strategy is pretty brittle. The nature of the evolved individuals was such that were probably full of intransitives. They could beat particular strategies easily, but were susceptible to other strategies and with borda voting you tended to find a move that was reasonable with many strategies instead of super-tuned for just a few. There are many papers on making decisions using borda voting, and some of these papers are not just about voting theory or sociology but computer based decisions too. Like I say, I don't know much about this and perhaps you do, but I thought I would present it just in case. I think it's very interesting figuring out how to integrate knowledge based on "experts" or agents that have wildly varying strengths and weaknesses. - Don David Doshay wrote: > This is the direction in which we are moving with SlugGo. We also > expect it to be difficult to integrate different approaches, but this > has always been our research direction: when there are multiple > codes which will each give an evaluation of a situation, how does > one design an arbitrator that makes the final decision? > > While SlugGo started off with multiple instantiations of GNU Go, > it has always been our intent to add engines that evaluate, select, > and rank moves in completely different ways. It just made some > sense to start getting the cluster infrastructure worked out with > only one engine. > > There are many details ... each engine has a different bias in its > selection, and also a different representation for the values of > those choices, so simple algebraic combinations of the values > does not in general work, even though it did when we were using > only GNU Go engines. But one thing is reasonable obvious: if a > bunch of completely different engines pick the same move, the > confidence that it is your best choice goes up. > > Cheers, > David > > > > On 1, Feb 2008, at 8:55 AM, Don Dailey wrote: > >> There is much to think about with Jason's and Michaels ideas. I favor >> a more integrated approach than Michael suggests because I think it >> would be very difficult to essentially have 2 different programs playing >> the same game (ever play non-consultation doubles in chess or go? It's >> fun but the level of play stinks. You take turns making a move with >> your partner and no consultation is allowed.) >> >> I also favor focusing more on the tree portion, but no doubt the >> play-out portion could improve. I say this because search is more >> sensitive to early mistakes and work near the root is cheap compared to >> work nearer leaf nodes. But by all means we should do research on >> what it takes in the play-outs. >> >> - Don >> >> >> >> Jason House wrote: >>> I wouldn't stop there. I'd like a static analyzer to add tactical >>> smarts to playouts. If there's a pre-existing nakade, seki, etc, the >>> playouts should get it right. >>> >>> On Feb 1, 2008 10:34 AM, Michael Williams <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> wrote: >>> >>> I think we would all agree that UCT+MC is quite good for strategy >>> but not so good with tactics. I'd like to see this hybrid engine: >>> One that starts with a >>> traditional full-board static analysis (with local tactical >>> searches), looking for urgent moves. If it finds an urgent move, >>> it makes it. If the position is >>> relatively quiet, it uses UCT+MC to find a good strategic play. >>> _______________________________________________ >>> computer-go mailing list >>> computer-go@computer-go.org <mailto:computer-go@computer-go.org> >>> http://www.computer-go.org/mailman/listinfo/computer-go/ >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> computer-go mailing list >>> computer-go@computer-go.org >>> http://www.computer-go.org/mailman/listinfo/computer-go/ >> _______________________________________________ >> computer-go mailing list >> computer-go@computer-go.org >> http://www.computer-go.org/mailman/listinfo/computer-go/ > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
