On Thu, Jun 18, 2009 at 10:20 AM, Brian Sheppard <sheppar...@aol.com> wrote:
> >> In my old Goliath program I used positions as hashcodes to lookup a > >> move/value combination because it was much easier to program than > >> trees :) > > >I think this is the better solution and it's probably easier too. > > You probably need both an automatically generated system (self-learning) > and a manual override. Lazarus didn't have a manual override since I don't know how to build a good book for 9x9. But what I did do is let Lazarus search moves off-line to much larger depths that would normally be possible. I actually let it play games on CGOS and then made a little note of the first position out of book. The the off-line version deep-searched it and it would get added to the book. So while it was in the book, it was as if a super-strong Lazarus was playing it's moves. I wanted some variety so even though it was a pain I searched the position several times and let it play moves in the same ratio that it chose them off-line. You calculate how often an opponent can force you into a particular line by assuming he is trying too and then computing the combined probability (based on your move playing percentages) that you would end up in this line if the opponent wanted to get you there. When that dropped below 1 percent, I only searched 1 move and stopped trying to provide variety. You could do this on-line easily by letting it search the first move out of book twice as long as you normally would, then adding it to the book. An ideal system would let you edit book moves but allow you to store information about how the move got there, i.e. whether it was placed by a human expert, searched by the program and so on. Also, it might want to store the win percentage from each position but this should not be taken too seriously, as the win percentage is mostly related to who your opponent are. There is no reason not to save the result of a previous search and add it to the book, why duplicate the effort? But of course that doesn't mean your move choice will be a good one. So what I think might be a really good system is a hybrid system where the computer is given (or produces it's own) variety, but some utility is able to identify problem moves for a human to later analyze. So if we keep getting beat the same way the human expert could take a look and see why - and then edit the book accordingly to fix the problem. - Don > > > You need the automatically generated system because computers can fill > in much larger sections of the tree than any human possibly can. The > quality can easily be made higher than your engine can create over the > board. > > In most domains there are problems that defy computer solution. Even > Chinook struggled with one particular checkers opening and required > manual instruction despite having deep search, carefully tuned heuristics, > and an exhaustive library of 9-piece endgames. IIRC, it was only with > the 10-piece endgames that Chinook was able to see through the variations > from the root. > > For Go, Fuego uses hand-coded openings and Mogo uses automated learning. > Martin's recent match report makes clear that both systems have relative > strengths. > > Here is a tidy illustration of both strength and weakness of manual book > preparation: Martin had to change an opening that had long been in Fuego's > book because Fuego had done badly with it. > > For the other side, Mogo was able to play an amazing 13 book moves at the > start of one game, but then found that the position was not as good as > it thought. > > Pebbles is doing both. Maybe someday it will do both well. :-) > > Brian > > _______________________________________________ > 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/
