[computer-go] Explanation to MoGo paper wanted.

[David Doshay]

On 9, Jul 2007, at 4:01 PM, Sylvain Gelly wrote:

> Hi,
>
>> > I'm on the other side of this issue. In my opinion all kinds of go
>> > knowledge are fair game and I'm rather disappointed that so small
>> > amounts of domain specific knowledge have been merged with the UCT
>> > search approaches.
>> >
>
>> I agree. I really do not understand why using domain knowledge would
>> be a problem for some people.
>
> Maybe one big reason is that domain knowledge is really hard to get
> right. A lot of man power is needed to have a program with non
> ridiculous go knowledge, higher than any other ideas that have been
> successful in UCT.

I agree with you that it is hard. It is easy to include simple domain
knowledge that is only sometimes right and often wrong. It is hard
start with one set of domain knowledge and add to it in a way that
improves play.

>> It seems to me that this opinion is held
>> by programmers with less Go knowledge who hope that pure search is
>> an answer.
> Maybe they believe that there is a lot of room for improvement without
> go knowledge, and other will put the go knowledge because they are
> stronger in that part. Isn't it the way research goes forward?

Absolutely. I just think that the UCT method has given us the biggest
part of what it can without biasing methods that stay away from random
games and select moves that are closer to the relevant space. This is
easier in thermal physics, where the theory tells us that Boltzman
distributions are what we need. You are closer to these methods and
I am just starting to learn them, so you may be more correct than I.

>> (...) I cannot imagine that progress will be
>> made without a great deal of domain knowledge.
>
> Depending on what you exactly mean I disagree.

I mean progress by the standard usually applied to computer Go:
programs that can beat 1D humans on a full board, and then get
better.

> Progress has been made
> without "a great deal of domain knowledge" and there are many
> improvements in the algorithms we can make. That does not prevent
> using domain knowledge!
>
>> I think that the
>> next big trick will be in getting the domain knowledge into the form
>> that the MC methods can use efficiently.
>
> I agree that it is ONE OF the next big trick. But people with
> experience in the "classical" programs are much more suited for that
> than "new comers". On the other side, there are plenty of other ways
> to improve.
> My point is that they are not mutually exclusive.
>
> Cheers,
> Sylvain

We agree that work on algorithms as well as on data representation
are needed. I am less sure that knowledge representation in the  
classical
programs is the right expertise for its representation in the MC  
playouts.

So many thing yet to do!


Cheers,
David