[computer-go] Explanation to MoGo paper wanted. (BackGammon Code)

Łukasz Lew lukasz.lew at gmail.com
Tue Jul 3 09:17:47 PDT 2007


On 7/3/07, chrilly <c.donninger at wavenet.at> wrote:
> >> >
> >> > We just presented our paper describing MoGo's improvements at ICML,
> >> > and we thought we would pass on some of the feedback and corrections
> >> > we have received.
> >> > (http://www.machinelearning.org/proceedings/icml2007/papers/387.pdf)
> >> >
> >
> > They are probably referring to this paper:
> > http://www.cs.ualberta.ca/~mmueller/ps/silver-ijcai2007.pdf
> >
> No, I am referring to the icml2007 paper.

What I said is that ICML paper mentions RLGO evaluation function which
is described in this paper:
http://www.cs.ualberta.ca/~mmueller/ps/silver-ijcai2007.pdf

> >
> > It's because Go is not only game in the world and certainly not only
> > reinforcement learning problem. They are using a widely accepted
> > terminology.
> >
> But a very inappropriate one. I have read Suttons book and all the things I
> know (e.g. TD-Gammon) are completly obfuscated. Its maybe suitable to
> present generel concepts, but it is extremly complicated to formulate an
> algorithm in this framework.
> But the main point is: I think game programmers should be more proud of
> their work and should present their results in the language of game
> programming. We are the ones which make progress, not these paper tigers.

I agree that game programmers make most of the progress in game domain.

>
> When I wrote the Null-Move article, some referees pointed out, that the
> article is not scentific enough. The NullMove was already known and even
> published before. But only after this "non-scientific" article it became a
> "must have" in chess programming. The pseudo-code had a bug and I see till
> today this bug in open-source chess programms.
> >
> > Can You share the source?
> >
> Yes. See attached Archive. The "interface" and the "UCT" part are rather
> primitive. The move-generator is better/faster than the ones I have seen in
> other public code (but can be certainly improved). The evaluation was
> published by G.Tesauro, but the implementation is more efficient. It is -
> according to G.Tesauro - a baseline for an evaluation. Every usefull
> evaluation function should clearly beat this one.
> The purpose of the code was to study the effect of Monte-Carlo sampling. I
> was deeply impressed how much better the Rollout/Monte-Carlo version plays.

Thanks,
I asked for the source, mostly because I expect to learn something from you.

Best regards,
Lukasz

>
> Chrilly
>
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>


More information about the computer-go mailing list