Also sometimes it scales but not lineal, thats an issue to. A big one. Like raw MC, you can get a very good move with less than 70k simulations, to get a really good move perhaps you need 400 billons. I remember there is a paper about this with a 'oracle' MC engine and they used it to compare to different mc implementations.
MC oracle was a MC engine running like 100 billon simulations for every move. --- Don Dailey <[EMAIL PROTECTED]> escribió: > 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 > > > > [email protected] > > > > > http://www.computer-go.org/mailman/listinfo/computer-go/ > > > > > > _______________________________________________ > > > computer-go mailing list > > > [email protected] > > > > http://www.computer-go.org/mailman/listinfo/computer-go/ > > > > > > _______________________________________________ > computer-go mailing list > [email protected] > http://www.computer-go.org/mailman/listinfo/computer-go/ > __________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
