Hideki Kato wrote:
delta_komi = 10^(K * (number_of_empty_points / 400 - 1)),
where K is 1 if winnig and is 2 if loosing. Also, if expected
winning rate is around 50%, Komi is unmodified.
I don't think the formula you posted is correct.
In the opening it gives delta_komi = 0.8 and in the
Hideki Kato wrote:
Gian-Carlo Pascutto: [EMAIL PROTECTED]:
Hideki Kato wrote:
delta_komi = 10^(K * (number_of_empty_points / 400 - 1)),
where K is 1 if winnig and is 2 if loosing. Also, if expected
winning rate is around 50%, Komi is unmodified.
I don't think the formula you posted
I also implemented RAVE in Mango. There was a few points of improvements
(around 60 Elo points with gnugo as reference), but as much as in the
paper of Gelly and Silver :( (around 250 Elo points if I remember well)
It might be that the effect of RAVE depends a lot on the simulation
strategy.
Hideki Kato wrote:
4) Before back-propagating the value of each playout, I setup a color
table for all intersections of the board for speed-up, in fact
(initialized with EMPTY). That is, fill the board (table[move] =
color) by tracing the moves and the colors returned by the playout
forward
Olivier Teytaud wrote:
Basically, the formula in MoGo combines the success ratio and the
RAVE-success ratio, with more focus on the success ratio when the
number of simulations is large.
You have no bias which favors exploration at all?
--
GCP
___
Harri Salakoski wrote:
Hi such question that do you typically traverse all child objects or is
there faster way to select explored node child object.
I have concluded that it is not at least easy as multiple nodes uct
values change each simulation so trying to keep biggest uct value in
first
I'm not sure what to think about the following:
Leela 0.3.0 vs Leela 0.3.7, 455 game match
177 vs 278 = +78 ELO points for Leela 0.3.7
CGOS rating
Leela_0.3.0_1CPU 2335
Leela_0.3.7_2CPU 2333
Hmm..but also
Zen-0.9 2386
Zen-1.0 2385
or more:
Uct-200801122348
Uct-200801132334
Michael Williams wrote:
So do I. I just stated a simpler version here because I previously
suggested a more integrated approach and got zero replies. I'll state
it again:
Start with a UCT+MC engine. When a tree node reaches X number of
playouts (1000?, 1?), do a tactical analysis.
Don Dailey wrote:
I don't know how David figures 1000 ELO, but I would expect the
difference to be much larger than that for 19x19 go. I don't believe
they are yet very close to 1 Dan.
http://www.gokgs.com/graphPage.jsp?user=CrazyStone
You're right. They're closer to 2 Dan.
:)
--
David Fotland wrote:
So, can the strong 19x19 programs please tell us your playout rates? I
expect the higher the rank, the fewer playouts per second. I'm not
interested in 9x9 data, since I think much less go knowledge is needed to
play 9x9. With your playout rate, please include the
Andy wrote:
CrazyStone hasn't played since the initial spike to 1k in December. The
movement of the chart afterwards is rating drift.
Ok. For me this is actually GOOD news :)
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
Don Dailey wrote:
If a nakade fixed version of mogo (that is truly scalable) was in the
study, how much higher would it be in your estimation?
You do realize that you are asking how much perfect life and death
knowledge is worth?
--
GCP
___
Don Dailey wrote:
I must not understand the problem. My program has no trouble with
nakade unless you are talking about some special case position.My
program immediately places the stone on the magic square to protect it's
2 eyes.
Can your program identify sekis? Nice examples in
Don Dailey wrote:
So I think this is nakade.
Yes. Leela 0.2.x would get it wrong [1].
[1] Not eternally, but it would still take unreasonably long.
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
Don Dailey wrote:
Yes, the tree generates pass moves and with 2 passes the game is scored
without play-outs.
How do you detect dead groups after 2 passes? Static analysis? All is
alive/CGOS?
I can't believe mogo doesn't do this, it would be very weak
if it didn't.
That's just an
Don Dailey wrote:
I am concerned that the current study is, as Jacques has so ably
described, a study of a restricted game where nakade and certain
other moves are considered to be illegal; this restricted game
approaches the game of Go, but the programs have certain blind
spots which humans can
David Fotland wrote:
This is an odd idea. When computers started beating people in chess, humans
did not abandon the game and change to some other similar game. Why do you
think go players would stop playing go when computers get strong?
At some point human players playing computers started
So I wouldn't be surprised at all if at some point you'll see a
marriage of the best ideas of traditional Go programs and Monte-
Carlo / UCT. In fact, this is most likely already happening as these
Monte-Carlo programs use algorithms / ideas from the traditional
programs for tactics,
John Fan wrote:
If we are talking about real suicide, I do not see any point to allow
the real suicide in the play out. What would be the gain if we allow the
real suicide in the play out.
The answer to this question has been given at least 3 times:
Speed.
It can take time to disallow a
Mark Boon wrote:
On 18-jan-08, at 12:01, Gian-Carlo Pascutto wrote:
But the speed of the random playout becoms less and less
important with heavy playouts.
This I don't understand at all. The improvement curve for being
faster isn't different with heavy than with light playouts.
I see I
Gian-Carlo Pascutto wrote:
Multi-stone suicide is allowed, single stone not.
I hadn't even considered suicide.(It would be a major change for me,
as neither my Gui nor my board system allow such moves.)
The question is Why do you do it?
a. Just in case you wanted the entire program
terry mcintyre wrote:
That key play might even have been discouraged by some pattern.
MoGo probably does not allow self-ataris. If you do not allow self-atari
you cannot see such a shape is dead.
--
GCP
___
computer-go mailing list
No wonder it plays so well at 9x9, because the max length of playout is
only
81, it can 'see' what the board look like when the game ends.
The *average* length of a 9x9 playout is roughly 100 moves.
The max length is much larger.
On a 2.2Ghz Athlon64, I get about 10 000 playouts/second, at
Playing randomly like that shouldn't work, but when you play Mogo et al,
you see that intelligent behaviour emerges.
Although interesting, I would hardly call that 'intelligence' :-)
Ah, the traditional flamewar topic: the definition of intelligence
shifts whenever a computer achieves what
Harri Salakoski wrote:
The *average* length of a 9x9 playout is roughly 100 moves.
The max length is much larger.
The *average* length of a 9x9 playout is roughly 100 moves.
The max length is much larger.
Hmm, sorry if this is old subject but does it effect much for playout
quality if I cut
Rémi Coulom wrote:
Gian-Carlo Pascutto wrote:
Multi-stone suicide is allowed, single stone not.
Strange. The reverse would make more sense to me.
I do not track liberties, so the speed penalty for doing it that way is
too much.
I wrote my program to track psuedoliberties because
[EMAIL PROTECTED] wrote:
Um, by easier I mean faster. Also, I think single point suicide is more
likely to lead to infinite loops, depending on your eye-filling rule.
- Dave Hillis
Yes.
Particularly near the end of the game there are zillions of bad single
stone suicides, but not often
Christoph Birk wrote:
On Jan 15, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:
Um, by easier I mean faster. Also, I think single point suicide is
more likely to lead to infinite loops, depending on your eye-filling
rule.
- Dave Hillis
I don't understand why anyone would allow suicide in
Don Dailey wrote:
But with the type of scoring that MC does (where we optimize for winning
percentage over score) it's more difficult to construct go problems.
You have to construct them so that you LOSE the game if you don't play
the right move, but if you do play it you win the game.
Hideki Kato wrote:
No. Remember UCT is a sequential algorithm. Parallelizing UCT make
playouts ineffective. Increasing the number of threads and/or
communicating delay decreases the effectiveness of the playouts. With
my experiments on a symmetrical threads implementation on a four core
Hideki Kato wrote:
What is correct move? It has sense only for some artificial
problems or very limited positions, and so, it cannot evaluate total
performance of a program.
This is true, but we are interested in search performance. So, it makes
sense to evaluate on those positions where
Don Dailey wrote:
It's not very clear to me how strong Mogo is at 19x19. I have no idea.
Can't we estimate from KGS games?
You'd need to know exactly how fast the hardware is, of course.
--
GCP
___
computer-go mailing list
Olivier Teytaud wrote:
Also, there are probably other people interested in combining
UCT and mpi; I don't know if some people have a more precise idea
of the level of the MPI+UCT combination than us. Someone ?
MPI is just a parallel programming model/library, right?
So the only thing to know
Michael Williams wrote:
Gian-Carlo Pascutto wrote:
Olivier Teytaud wrote:
Also, there are probably other people interested in combining
UCT and mpi; I don't know if some people have a more precise idea
of the level of the MPI+UCT combination than us. Someone ?
MPI is just a parallel
Yamato wrote:
I guess the current top programs have much better playout policy than
the classical MoGo-style one.
The original policy of MoGo was,
(1) If the last move is an Atari, plays one saving move randomly.
(2) If there are interesting moves in the 8 positions around the
last move,
Yamato wrote:
I finally improved my playouts by using Remi's ELO system to learn a set
of interesting patterns, and just randomly fiddling with the
probabilities (compressing/expanding) until something improved my
program in self-play with about +25%. Not a very satisfying method or an
Chris Fant wrote:
CGOS 19 is has been stuck for a while now.
At the bottom of the page, it says Many Faces is in a game, but does
not show it as currently playing at the top of the page. Perhaps the
problem is related to a bot leaving near the time a round is
ending/beginning.
I guess Oliver
Rémi Coulom wrote:
In Crazy Stone (maybe that is the case of MoGo, too), nakade is such a
big problem because the program avoids playing self-atari in playouts.
Crazy Stone will play the self-ataris anyway, but with a low
probability, so they are played at the end of the playout only. In case
steve uurtamo wrote:
It was my understanding that the netlag to the Philippines was about
380 ms; accounting for an additiaonal 15% packet loss and we end up
at about 440 ms.
i think that it works out to roughly double that because of the protocol, right?
Yes, the server sends out the move
Jason House wrote:
MoGo uses TD to predict win rates.
Really? Where did you get that information?
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Jason House wrote:
The paper introduces RAVE and
near the end talks about using heuristics for initial parameter
estimation. The heuristic they used was based TD.
Ah, you're talking about RLGO. RLGO was trained with TD, but MoGo itself
doesn't use TD (directly).
There are posts from Sylvain
Mogo is around 2500 on CGOS:
http://cgos.boardspace.net/9x9/cross/MoGo_psg7.html
This implies you believe the ratings didn't shift over time.
http://computer-go.org/pipermail/computer-go/2007-October/011405.html
http://cgos.boardspace.net/9x9/cross/MoGo_monothreadC.html
Joshua Shriver wrote:
FPGA boards are expensive
How many gates do you need?
It's not because the eval boards you find everywhere are expensive that
FPGA's are. Low-cost ones go from 10 to 70 USD depending on the gate
count. A bargain compared to an ASIC solution as long as the quantities
are
Petr Baudis wrote:
Hi,
is there any way to send game comments through kgsGtp on your own
(without the opponent triggering you)?
I think some possibility to send messages would be great. I could swear
I saw MogoBot do this, but I couldn't find anything in the KGSGtp
documentation.
The
201 - 244 of 244 matches
Mail list logo
