[computer-go] Monte-Carlo Go Misnomer?

[Don Dailey]

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 at computer-go.org
>         > http://www.computer-go.org/mailman/listinfo/computer-go/
>         
>         _______________________________________________
>         computer-go mailing list
>         computer-go at computer-go.org
>         http://www.computer-go.org/mailman/listinfo/computer-go/
>