Sylvain Gelly wrote:
2008/1/10, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
Hi Sylvain,
Have you finished your thesis? We are eager to read it:-)
Hi,
Yes I did! :).It is not on my website, but will (soon?).
However, you should not be so
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
Gian-Carlo Pascutto: [EMAIL PROTECTED]:
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
Hi,
You have to put the file vtbeta.jar in the lib directory of the gogui. For me,
it is ~/Go/gogui-0.9.2/lib. vtbeta.jar uses the other files that are in this
directory. Note that the visual tree is not compatible with gogui 1.x yet, only
with version 0.9.x :(
Visual Tree was also used by
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
I clearly stated what I meant by effective:
How much faster you find the correct move. Not interesting is: how many
positions you search per second or how many playouts you do per second.
What is correct move? It has sense only for some artificial
problems or very limited
Gian-Carlo Pascutto wrote:
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
Sylvain Gelly wrote:
It looks like MoGo does respect the time_left commands from GTP, so I
don't think the totalTime parameter is required in this case.
What do you mean? If you don't put --totalTime, then MoGo indeed ignores
time_left. If you put --totalTime, then it respect the
Gian-Carlo Pascutto: [EMAIL PROTECTED]:
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
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.
There are many positions where winning the game requires one or a small set of
moves.
Suppose the board is
From: Rémi Coulom [EMAIL PROTECTED]
Sylvain Gelly wrote:
Yes I did! :).It is not on my website, but will (soon?).
However, you should not be so eager to read it :)
Cheers,
Sylvain
Google finds it:
http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf
Thanks, Rémi!
Now eagerly
There is lots of English in it. Just scroll down.
terry mcintyre wrote:
From: Rémi Coulom [EMAIL PROTECTED]
Sylvain Gelly wrote:
Yes I did! :).It is not on my website, but will (soon?).
However, you should not be so eager to read it :)
Cheers,
Sylvain
Google finds it:
Le dimanche 13 janvier 2008, terry mcintyre a écrit :
From: Rémi Coulom [EMAIL PROTECTED]
Sylvain Gelly wrote:
Yes I did! :).It is not on my website, but will (soon?).
However, you should not be so eager to read it :)
Cheers,
Sylvain
Google finds it:
I don't think such positions are enough to evaluate total
performance of a program. Because they don't include middle games
nor opening games, for examples.
-Hideki
terry mcintyre: [EMAIL PROTECTED]:
Hideki Kato wrote:
What is correct move? It has sense only for some artificial
problems
Thanks Alain. I see I had given up on the paper too soon.
- Dave Hillis
-Original Message-
From: Alain Baeckeroot [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sun, 13 Jan 2008 11:51 am
Subject: Re: [computer-go] Sylvain Gelly thesis in english
Le dimanche 13
Google finds it:
http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf
That is NOT the latest version. Please at least let me put the latest
version on my web site, it took me so long to correct it :).
Sylvain
___
computer-go mailing list
The reason I said that was this behavior from mogo. If I start it without
that switch and as for a move, it allocates 20 seconds. If I then issue a
small
time_left command and ask for another move, it allocates a much smaller
amount of time. Here is the output:
Because you give a
Sylvain Gelly wrote:
The reason I said that was this behavior from mogo. If I start it
without that switch and as for a move, it allocates 20 seconds. If
I then issue a small
time_left command and ask for another move, it allocates a much
smaller amount of time. Here is
Hi,
Nothing strange here. You tell MoGo to play 19x19 and you tell him that
there is only 60 s left. It can be understood that it takes only 1s for this
move...
BTW, if you see him play in 9x9, it is because while you told him to set his
parameters for a 19x19, by default the boardsize is 9x9 and
I'm not saying that it's anything strange. I was just pointing out that it does seem to heed the time_left number, even without specifying totalTime on the
command line. Yes, I started mogo with the --19 switch so that it would have to think about the first move on 9x9 instead of using the
21 matches
Mail list logo
