>
I have serious problems with KO. UCT-Suzie plays generally strong, but
makes
terrible blunders in KO-positions. So far I do not even understand the
problem. Could you describe it more detailed?
I had also some serious SuperKO problems. UCT-Suzie was very "clever" to
find SuperKOs. We do not ch
Chaslot G (MICC) wrote:
p_hat = (w_i + n_h*H_B)/(n_i+n_h)
Interesting... But then how do you compute n_h in practice
The mathematical derivation is based on estimating an a-priori
probability distribution. In theory, one simply needs to run MC
simulations for a wide variety of heur
> How do you handle n_i = 0 in equation 1.2?
I don't compute it when n_i is not equal to 1. At that point, I give every node
a high upper bound in order to visit every node once. Remember that I am using
"progressive unpruning" in the same time, so only the best nodes according to
the heuristi
Rémi Coulom wrote:
to Magnus: If you consider the example of section 2.2: 1,2,3 wins
against 4,2 and 1,5,6,7. The probability is
P=c1c2c3/(c1c2c3+c4c2+c1c5c6c7). For this example:
N1j=c2c3,B1j=0,M1j=c2c3+c5c6c7,A1j=c4c2
N2j=c1c3,B2j=0
N3j=c1c2,B3j=0
N4j=0,B4j=c1c2c3
I will add this example to t
On 5/17/07, Chrilly <[EMAIL PROTECTED]> wrote:
I have now also finished a first version of UCT-Suzie (in parallel the Peter
Woitke works on the Alpha-Beta Version). UCT-Suzie uses a hashtable, mainly
because I found the programming of the tree too complicated. The Monte-Carlo
part uses some simpl
Hi Rémi,
2007/5/17, Rémi Coulom <[EMAIL PROTECTED]>:
to Sylvain: Here are tests of Crazy Stone at 90s/game 1CPU against GNU
3.6 level 10, measured over about 200 games
[...]
Thank you for your answer. These numbers are interesting.
The improvement in the tree search is really huge. It is what
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
I have now also finished a first version of UCT-Suzie (in parallel the Peter
Woitke works on the Alpha-Beta Version). UCT-Suzie uses a hashtable, mainly
because I found the programming of the tree too complicated. The Monte-Carlo
part uses some simple patterns according the MoGo article. Progres
On 5/17/07, Rémi Coulom <[EMAIL PROTECTED]> wrote:
Álvaro Begué wrote:
> There are many things in the paper that we had never thought of, like
> considering the distance to the penultimate move.
That feature improved the effectiveness of progressive widening a lot.
When I had only the distance to
How do you handle n_i = 0 in equation 1.2? I'd assume that if a heuristic
says a move is really bad (H_B = 0), then you'd want to avoid simulations
for a while.
Also, has mango experimented with other related strategies for a soft
transition?
In my own mathematical recreation, I came up with a
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 se
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 furthe
Yes, now I understand. I think what made it hard for me conceptually was that
P(Rj) can be rewritten n different ways for each feature ci 1 <= i <= n. I had
this problem with your example too. I first thought that the lines with the
factors were arbitarary, but then I realized that each line goes
On Thu, 2007-05-17 at 12:17 -0400, George Dahl wrote:
> Imagine if you had a monte carlo program that took almost no time to
> run. You would use it to do "heavy" playouts for another monte carlo
> program to make it even stronger.
I tried something like this as a test with simple monte carlo.
On Thu, 2007-05-17 at 10:54 -0500, Zach Keatts wrote:
> What you would have after your training/evaluator phase is a hueristic
> knowlege of possibly better montecarlo trees to consider. This will
> definitely cut down on the search space, but could also alienate a
> strong search path. I have be
Álvaro Begué wrote:
There are many things in the paper that we had never thought of, like
considering the distance to the penultimate move.
That feature improved the effectiveness of progressive widening a lot.
When I had only the distance to the previous move, and the opponent made
a dangerous
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.co
Dear all,
Following the example of Rémi, I would like to share with you a paper that I
wrote which describe some important elements of my Go program Mango.
I submitted this paper recently to the JCIS workshop 2007. Due to the fact that
it was an extended abstract, a lot of details are missing.
Rémi:
John and I are planning a similar usage of patterns and features in
the MC simulations, although we were thinking of a very different
method to update "strengths". Although we derived our formulas from an
extension of the logistic regression instead of Bradley-Terry models,
we arrived at ve
> It seems that e-mail at my university does not work any more. I have
> received none of the replies to my message of yesterday, but I could
> read them on the web archives of the list. So I have registered from
> another address, and will answer to the questions I have read on the web.
In sect
It seems that e-mail at my university does not work any more. I have
received none of the replies to my message of yesterday, but I could
read them on the web archives of the list. So I have registered from
another address, and will answer to the questions I have read on the web.
In section 2.3
But it is very difficult that a board position is repeated between games. I
don't see how you will use the training pairs in the new games.
2007/5/17, George Dahl <[EMAIL PROTECTED]>:
What I am actually proposing is collapsing the results of the playouts
offline and then having a function that
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, "Pas
Hi,
It seems that e-mail at my university does not work any more. I have
received none of the replies to my message of yesterday, but I could
read them on the web archives of the list. So I have registered from
another address, and will answer to the questions I have read on the web.
to Matt
What I am actually proposing is collapsing the results of the playouts
offline and then having a function that maps board positions to
playout values without actually doing playouts. So I would use an MC
player to generate a lot of training pairs of the form (position,
score) where position would
Dear all,
We are proud to announce that Guo Juan, 5d professional from China, will
be present at the Computer Olympiad in Amsterdam on the Sunday 17th of
June. She will play against the winner of the Olympiad and comment the
most interesting games. We will broadcast as many Go games and comments
a
What you would have after your training/evaluator phase is a hueristic
knowlege of possibly better montecarlo trees to consider. This will
definitely cut down on the search space, but could also alienate a strong
search path. I have been thinking along these same line for some time. The
problem
On 17, May 2007, at 8:17 AM, Brian Slesinsky wrote:
A weakness of this approach is that sometimes the best move depends on
how you plan to follow it up; a program that plays the theoretically
best move but doesn't know how to follow it up is weaker than a
program that plays safer moves.
I have
I think there is something to this; it seems like it should be
possible to use a database of randomly selected positions from games
along with the best known followup, and use that as a faster way of
testing a program's strength than playing full games. Such a database
would be valuable for all s
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
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
31 matches
Mail list logo
