Your english is fine, it's my grammer that could use some help. I made it more complicated than it needed to be.
You mentioned that you have a slow but flexible data structure that supports lots of experimentation but makes the program slower. But it occured to me that a simple version that only does uniformly random play-outs - can't make any use of this extra sophistication - therefore it must suffer more of a speed penalty. I have the same situation with an older program that has a more sophisticated data strucutre. If I was building a smarter program I would rather use the older but slower code but I cannot optimize it any further for simple randomly uniform play-outs. If I compared the old code doing simple play-outs to the old code doing the sophisticated evaluation, it might not look so bad because the older program is doing uneeded work that is of no benefit to a simple program. - Don On Sat, 2007-02-03 at 20:26 +0100, Sylvain Gelly wrote: > > I seriously doubt a highly optimized MoGo would be able to > stay > this close to uniform random in speed. > > We certainly could not achieve 0.6 the speed Lukasz can achieve with > uniform random. > > > is suffering more from the baggage of this infrastructure than > the best simulation > policy version that I would guess is benefitting more from > this > infrastructure. > Sorry I don't understand :-(. Is the second "more" of the sentence a > mistake, or my english too poor? If I remove the second "more", do you > mean benefitting for the speed or the accuracy? > > Sylvain > > > > > On Sat, 2007-02-03 at 10:31 -0800, David Doshay wrote: > > On 3, Feb 2007, at 2:51 AM, Sylvain Gelly wrote: > > > > > the speed of the best simulation policy in MoGo is 0.6 * > the speed > > > of the uniform random one. > > > > I think that this is very good. You give up less than a > factor of 2 > > from uniform random and you probably get better than a > factor of 2 in > > the % of relevant moves. > > > > This has been the biggest reason we have delayed adding MC > to SlugGo: > > how do you keep the "randomly" selected moves anywhere near > the > > relevant moves? With the high branching factor we face in > Go, this > > seems most important to me. And MoGo has made huge strides > in that > > direction. > > > > > > > > Cheers, > > David > > > > > > > > > > > > _______________________________________________ > > 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/
