Sylvain, What you say is no surpise to me about the constraints. I knew that if you improved things, you would eventually have to improve or reduce the constraints.
The simple question I always ask about a feature is whether the idea is infinitely scalable. Some idea are very good in the short term, but in the long term form a barrier to improvement. Of course that doesn't mean the idea shouldn't be used because it might be helping you. But at some point you know your program will out-grow the idea and then it will be holding you back. A good example of this is piece square tables in computer chess. It was a wonderful way to add a lot of knowledge to a chess program without slowing it down any. It's based on the idea of looking at the starting position, making a lot of stategic decisions before you even begin searching (by filling the table with values) and then doing the search. This idea has serious limitation when you search incredibly deep, but really worked well in the days when programs could not search deeply. I think some programs still use this today but to a lesser extent - they have adjusted accordingly with much more dynamic evaluation. I have this theory that if something isn't "properly scalable", then you are probably doing it wrong - at least in an idealistic sense. >From a practical standpoint I have no trouble doing these non-scalable things if there is no obvious scalable solution that can give me the same short-term improvement. AnchorMan is a clear example of this non-scalable approach. A hackery of non-scalable patches to try to stop it from playing the ugliest of moves! - Don On Mon, 2007-03-05 at 10:52 +0100, Sylvain Gelly wrote: > Hello Peter, Hello Don, Hello all, > > It is true that I have been mainly working to improve the level of > MoGo in 19x19. It turned out in my experiments, that improving its > level in 9x9 with very little simulations was significant for the > level in 19x19, so it is one reason why the limited version of MoGo > are running on cgos. So even if the goal was 19x19 improvements, the > improvements appeared in all boardsizes. > > Our first approach to 19x19 was, as you say Don, to constrain the > board (as explained in our paper), and it brought improvements. > However, now it is quite the contrary what is happening, each > improvement allows to remove constrains on 19x19, and making it play > as if it was a 9x9 board (I mean in the parameters). As you may have > noticed for example, MoGo is not playing locally anymore on 19x19 > (which gives it an ugly style :-)). > The number of simulations done in this tournament was from 10k to 50k > per move, depending on the context and the move number (simple time > management stopping early the thinking if one move is clearly better > than the others). > For all the details on the improvements, we submitted a paper, and I > am writing them in my thesis, so you will all know, just wait for them > to be written :-/. > I still strongly believe in the future of MC even in 19x19. > > Bye, > Sylvain > > > 2007/3/5, Don Dailey <[EMAIL PROTECTED]>: > > I'm pretty sure I read that the MoGo team is shifting their efforts > > towards 19x19 GO. There are lot's of possibilites for research, > > but Mogo already does things to constrain the board on 19x19, they > > are probably just refining this stuff. > > > > - Don > > > > > > On Sun, 2007-03-04 at 19:58 -0800, Peter Drake wrote: > > > Congratulations to MoGo on winning the KGS tournament held earlier > > > today: > > > > > > http://www.gokgs.com/tournEntrants.jsp?sort=s&id=270 > > > > > > Even under borderline "blitz" conditions (18 minutes sudden death > for > > > 19x19), MoGo managed to beat conventional programs like GNU Go. > > > (ManyFaces apparently had some connection/restarting glitch, so > its > > > performance may not be representative.) Of course, MoGo also beat > all > > > the other MC/UCT programs. > > > > > > How did MoGo do it? I have three hypotheses: > > > > > > 1) MoGo is completing more runs per second. How many is it doing > on > > > the machine used in the tournament. > > > 2) MoGo is somehow getting more out of the runs it does, using > things > > > like the all-as-first heuristic. > > > 3) Each of MoGo's runs is "smarter", through the use of > heuristics > > > that bias the random games. > > > > > > My money is on #3. In the limit, of course, a very smart program > > > could predict the outcome with one MC run for each move under > > > consideration. > > > > > > Would the MoGo authors (and anyone else) care to weigh in? > > > > > > Peter Drake > > > http://www.lclark.edu/~drake/ > > > > > > > > > > > > _______________________________________________ > > > 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/
