On Mon, 2007-03-05 at 11:58 -0300, Eduardo Sabbatella wrote: > 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.
But this doesn't scale to perfect play. Without the tree search beneath it, it doesn't matter how many trillions of simulations you do, even trivial errors like incorrect auto-atari's cannot be solved because it might statistically be the very best move against random play. - Don > > --- 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/
