Re: [computer-go] Amsterdam 2007 paper
Chris Fant wrote:
I first thought I would keep my ideas secret until the Asmterdam
tournament, but now that I have submitted my paper, I cannot wait to
share it. So, here it is:
http://remi.coulom.free.fr/Amsterdam2007/
Comments and questions are very welcome.
I'd like to propose a potential direction of further research. In
your paper, you acknowledge that the strong assumption that each
feature's Elo can be added to form the feature team Elo may not be
correct all the time.
The Stern/Herbrich/Graepel method did not need to make this assumption
because for them a feature team was it's own first class feature
(leading to exponential growth of the number of features). You could
evaluate the degree to which each feature violates additive-Elo
assumption by distributing that feature to all the other features and
retesting the prediction rate.
For example, instead of having features {Pass, Capture, Extension},
you would evaluate the Pass feature additive-Elo assumption by testing
with features {Capture, Extension, Pass-Capture, Pass-Extension}.
This is a bad example, because Pass and Capture are mutually exclusive,
and so are Pass and Extension, but I understand the idea, and I think it
is very good. In fact, I had planned to add it to the conclusion of the
paper. That is the reason why I wrote that "relevance of the model"
section. But it was 1 AM when I finished the paper, and I had been
writing it since early in the morning, so I decided I wouldn't start
explaining something complicated, sorry.
Another (less important) problem I forgot to mention in the paper,
regarding the validity of the model, is the hypothesis of independence.
When training from consecutive moves of the same game, it may not be
reasonable to consider that all the positions are independent. Sampling
one or two random position in every game might be better.
Thanks for your remarks,
Rémi
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Amsterdam 2007 paper
Very interesting paper: many ideas for me to study. And thanks for giving us an early look at it. I'll make one suggestion: in the final version, it deserves some better salesmanship in the results section. I've read through too many papers, only to reach the results section at the end and see something like "although our program was unable to defeat Wally on a 9x9 board, the authors still feel..." So now I look there first to see if I want to invest time on the paper. When I look at the end of this paper, what jumps out is "37.5% victories against Gnugo." IMHO, it's asking an awful lot of potential readers to expect them to recognize that this is an impressive result, which of course it is. I think it would be easier for people to understand if the "Performance against Gnugo" section started with 9x9 results against gnugo, maybe mentioned scaling issues and the 13x13 KGS results, and then went on to 19x19. Just my 2 cents. Now back to studying the paper. Dave Hillis Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Amsterdam 2007 paper
I first thought I would keep my ideas secret until the Asmterdam
tournament, but now that I have submitted my paper, I cannot wait to
share it. So, here it is:
http://remi.coulom.free.fr/Amsterdam2007/
Comments and questions are very welcome.
I'd like to propose a potential direction of further research. In
your paper, you acknowledge that the strong assumption that each
feature's Elo can be added to form the feature team Elo may not be
correct all the time.
The Stern/Herbrich/Graepel method did not need to make this assumption
because for them a feature team was it's own first class feature
(leading to exponential growth of the number of features). You could
evaluate the degree to which each feature violates additive-Elo
assumption by distributing that feature to all the other features and
retesting the prediction rate.
For example, instead of having features {Pass, Capture, Extension},
you would evaluate the Pass feature additive-Elo assumption by testing
with features {Capture, Extension, Pass-Capture, Pass-Extension}.
This obviously leads to more first class features, but you can test
each one one at a time to see if it is worth it. Or at least to
validate that the additive-Elo assumption is okay in most cases.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Amsterdam 2007 paper
Thanks for the great paper. And thanks for sharing it before it's published. Now I know what directions to take my engine in next. Time for Team MoGo so share some more secrets :) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Amsterdam 2007 paper
This is very interesting. I've skimmed so far and don't understand everything yet, but I can make some comments on readability. Table 1 takes some study to understand. If I understand it correctly, the Feature column might be more clearly labeled "Feature of Candidate Move." (For example, "Pass" means that the candidate move is a pass.) The "Level" column might be more clearly labeled the "Alternative" for that feature. It was unclear what "distance to the move before" means at first. It sounds like this is "distance to the move before the previous move" or maybe "distance from own previous move". - Brian On 5/16/07, Rémi Coulom <[EMAIL PROTECTED]> wrote: Hi, I first thought I would keep my ideas secret until the Asmterdam tournament, but now that I have submitted my paper, I cannot wait to share it. So, here it is: http://remi.coulom.free.fr/Amsterdam2007/ Comments and questions are very welcome. Rémi ___ 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/
Re: [computer-go] Amsterdam 2007 paper
Thanks, for sharing this early!
Everything in this paper makes perfect sense, and is well written.
Reading it is
like finding the last pieces of a difficult puzzle.
I do however have some problem with the math of section "2.5 A
Minorization-Maximization Algorithm". I have a feeling that a lot of
definitions are left out here. What is A, B, M and N? I think I can get what N
is. Somehow I have a feeling that you are using some special notation of
summation here, but even so I have no clue what is summed.
Also for Wi you use {} and || which might mean something special, but
since I am
already quite confused it hard to figure out.
Later on the section "Derivation of the Minorization-Maximization Formula"
seemed pretty clear to me although that was supposed to be more difficult.
Best
Magnus
Quoting Rémi Coulom <[EMAIL PROTECTED]>:
Hi,
I first thought I would keep my ideas secret until the Asmterdam
tournament, but now that I have submitted my paper, I cannot wait to
share it. So, here it is:
http://remi.coulom.free.fr/Amsterdam2007/
Comments and questions are very welcome.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Amsterdam 2007 paper
Hi Rémi, Thank you for this paper. I found the work very interesting, well written, and the paper is clear and pleasant to read. As two things are modified in the same time (simulation policy and tree search), I wonder what is the contribution of each part in the overall improvement. For example I wonder what is the exact improvement of the new policy simulation on itself (without modifying UCT) over the one of MoGo. I guess you already have those results, but don't have enough room to put it on this paper. For example, if I remember correctly plain UCT with MoGo's simulation policy at 70k per move was 83% against gnugo 3.6. What is the result with your simulation policy? 85%/90%/95 %/ more? That would help to know where this approach is more usefull: simulation, tree or even both. I mean it is possible that combining the two improvements makes a stronger player that taking the sum of each improvement. If so, that would mean that some win-win effect arises, and the tree search part type has to be related to the simulation type. Again, very interesting work. Sylvain 2007/5/17, Rémi Coulom <[EMAIL PROTECTED]>: Hi, I first thought I would keep my ideas secret until the Asmterdam tournament, but now that I have submitted my paper, I cannot wait to share it. So, here it is: http://remi.coulom.free.fr/Amsterdam2007/ Comments and questions are very welcome. Rémi ___ 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] Amsterdam 2007 paper
"I first thought I would keep my ideas secret until the Asmterdam tournament, but now that I have submitted my paper, I cannot wait to share it. So, here it is: http://remi.coulom.free.fr/Amsterdam2007/ Comments and questions are very welcome. Rémi" I Thought it was very interesting. Good job and congrats. I just skimmed over the part with all the math in it (too hard for me.) So I'm not sure that I understand 100%. Is this pattern analysis used only for choosing a node that's never been explored before? When exploring nodes that have been explored before does CrazyStone prefer nodes that have been successful in the past (i.e. UCT) or is the MC result just used for picking the final move? Good job. Matt - Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Amsterdam 2007 paper
Hi, I first thought I would keep my ideas secret until the Asmterdam tournament, but now that I have submitted my paper, I cannot wait to share it. So, here it is: http://remi.coulom.free.fr/Amsterdam2007/ Comments and questions are very welcome. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
