Is the 19x19 server down? (I wanted to look at some games.)
Thomas
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
SGF files? I looked at the gokgs archives for MoGoTitan, but didn't see
anything recent.
They are archived under Mogo, aren't they?
http://www.gokgs.com/gameArchives.jsp?user=mogo
The games that we've been talking about were the H7 games, I believe.
Eric Dunham
—
Ricky1, Owner and
The game can be found here http://www.lri.fr/~teytaud/H7.sgf
or on KGS, for user mogo.
I'm posting these results, but I must precise that I was not operating
myself - Arpad Rimmel did operate, and Guillaume Chaslot was also very
involved in the preparation. MoGo was running on Huygens (in
I do something similar to this in Many Faces.
-Original Message-
From: computer-go-boun...@computer-go.org
[mailto:computer-go-boun...@computer-go.org] On Behalf Of Don Dailey
Sent: Wednesday, December 24, 2008 5:47 AM
To: computer-go
Subject: [computer-go] 19x19 results (so far)
19x19
So if I understand this correctly, you only allow moves on the 3rd,
4th, or 5th lines to be considered (in both the tree and the playouts)
unless there is another stone within manhattan distance of two?
What would be really interesting is if one of the stronger open source
engines was modified to
-go.org
[mailto:computer-go-boun...@computer-go.org] On Behalf Of Don Dailey
Sent: Wednesday, December 24, 2008 5:47 AM
To: computer-go
Subject: [computer-go] 19x19 results (so far)
19x19 results of 3,4,5 rank rule:
Rank Name Elo+- games score oppo. draws
1 d2p 2050 21 21
On Wed, 2008-12-24 at 11:01 -0500, George Dahl wrote:
So if I understand this correctly, you only allow moves on the 3rd,
4th, or 5th lines to be considered (in both the tree and the playouts)
unless there is another stone within manhattan distance of two?
Correct.
What would be really
On Wed, Dec 24, 2008 at 01:27:46PM -0500, Don Dailey wrote:
Basically, in the playouts or move choice I veto any move to the 3rd 4th
or 5th line unless there is a stone of either color within distance 2
manhattan distance. Another version does 3 manhattan distance.
I hope you mean that you
On Wed, 2008-12-24 at 19:43 +0100, Heikki Levanto wrote:
On Wed, Dec 24, 2008 at 01:27:46PM -0500, Don Dailey wrote:
Basically, in the playouts or move choice I veto any move to the 3rd 4th
or 5th line unless there is a stone of either color within distance 2
manhattan distance. Another
Yes, the 19x19 server is down.
It's up and running now.
Olivier
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
It seems to be down for a few days now.
David
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Jason House wrote:
On Jan 29, 2008 10:16 AM, Jason House [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Jan 29, 2008 10:01 AM, Don Dailey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
FatMan seems to hit some kind of hard limit rather suddenly.
On Wed, Jan 30, 2008 at 04:35:18PM -0500, Don Dailey wrote:
Heikki Levanto wrote:
On Wed, Jan 30, 2008 at 03:23:35PM -0500, Don Dailey wrote:
Having said that, I am interested in this. Is there something that
totally prevents the program from EVER seeing the best move?
No problem for me. I did not want to multiply the number of versions not to
confuse people. With the double version, don't forget it will increase the
memory footprint for a given number of nodes.
Sylvain
2008/1/30, Olivier Teytaud [EMAIL PROTECTED]:
I can provide a new release with double
We want a version simply for the study - it may not make a performance
difference and will probably hurt the performance for a given time
level, so I would suggest it not to be the primary version.
- Don
Sylvain Gelly wrote:
No problem for me. I did not want to multiply the number of
You probably don't understand how UCT works. UCT balances exploration
with exploitation. The UCT tree WILL explore B1, but will explore it
with low frequency.That is unless the tree actually throws out 1
point eye moves (in which case it is not properly scalable and broken in
some
These are G5 Macs, so if we get a binary it needs to be appropriate.
We can do the compiling if you don't want to, but you may not wish
to deliver us your code, and in that case I can make you an account
so you can compile it and then delete the source if you wish.
The cluster will be available
That is correct.
It is my understanding that the Intel machines can compile to
a universal binary that will run on the G5 machines, but we
have not verified that. I trust that it works, but have no idea
if there is an efficiency hit.
Cheers,
David
On 31, Jan 2008, at 11:30 AM, terry mcintyre
Dave Hillis wrote:
I've noticed this in games on KGS; a lot of people lose games
with generous time limits because they, rashly, try to keep up
with my dumb but very fast bot and make blunders.
What Don says about humans scaling applies to humans making
an effort to use the time they have,
Dave,
I really thought about mentioning that in my original post because it
does affect the ability of human players. In fact one technique I
use when I'm losing badly in chess is to start playing instantly.I
have actually salvaged a few games that way - the opponent starts
playing fast
Jacques Basaldúa wrote:
Dave Hillis wrote:
I've noticed this in games on KGS; a lot of people lose games
with generous time limits because they, rashly, try to keep up
with my dumb but very fast bot and make blunders.
What Don says about humans scaling applies to humans making
an
I can provide a new release with double instead of float.
(unless the other mogo-people reading this mailing-list do not agree for
this; Sylvain, no problem for you ?).
I don't know exactly when it begins to do bad moves. However, I know that
after several hours, the estimated winning rate
I
would
agree
at
100%
if
it
wasn't
for
the
known
limitations:
Nakade,
not
filling
own
eyes,
etc.
Because
the
program
is
blind
to
them
it
is
blind
in
both
senses:
it
does
not
consider
those
moves
when
defending,
but
it
does
not
consider
them
when
to this situation?
Terry McIntyre [EMAIL PROTECTED]
- Original Message
From: Sylvain Gelly [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tuesday, January 29, 2008 10:36:38 AM
Subject: Re: [computer-go] 19x19 Study
but not linearly and you can see a nice gradual curve
I am, sadly, in the 9 kyu AGA range, yet can regularly create situations which
Mogo cannot read on a 19x19 board. Harder to do on a 9x9 board, but I have done
it.
Don asks how significant a jump of 3 kyu is. On a 19x19 board, one with a 3 kyu
advantage can give a 3 stone handicap to the weaker
Hi Olivier,
Yes, that would be great. Please do. Also, is there a Mac version
of this? We have the possiblity of using a huge cluster of Mac
machines if we have a working binary. We could probably get you a
temporary account to build such a thing if you don't already have it.
- Don
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 and do
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
___
I changed bayeselo to use the prior command as Rémi suggested I could do.
It raised the ELO rating of the highest rated well established player by
about 60 ELO!
I set prior to 0.1
http://cgos.boardspace.net/study/
- Don
Rémi Coulom wrote:
Don Dailey wrote:
They seem under-rated to me
Is nakade actually a problem in mogo? Are there positions it could
never solve or is merely a general weakness.
I thought the search corrected such problems eventually.
- Don
Gian-Carlo Pascutto wrote:
Don Dailey wrote:
If a nakade fixed version of mogo (that is truly scalable) was in
]
- Original Message
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, January 30, 2008 11:10:01 AM
Subject: Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study
Is
nakade
actually
a
problem
in
mogo
-go.org
Sent: Wednesday, January 30, 2008 11:10:01 AM
Subject: Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study
Is
nakade
actually
a
problem
in
mogo?
Are
there
positions
it
could
never
solve
or
is
merely
a
general
weakness.
I
thought
the
search
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
Gian-Carlo Pascutto wrote:
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
computer-go@computer-go.org
Sent: Wednesday, January 30, 2008 11:22:16 AM
Subject: Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study
I
must
not
understand
the
problem.
My
program
has
no
trouble
with
nakade
unless
you
are
talking
about
On Jan 30, 2008 2:48 PM, Don Dailey [EMAIL PROTECTED] wrote:
So are you saying that if mogo had this position:
| # # # # # #
| O O O O O #
| + + + + O #
a b c d e
That mogo would not know to move to nakade point c1 with either color?
That's not nakade... Even if it was one shorter,
in the House of Commons [June 15, 1874]
- Original Message
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, January 30, 2008 11:22:16 AM
Subject: Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS
study
I
must
in the nursery.”
Benjamin Disraeli, Speech in the House of Commons [June 15, 1874]
- Original Message
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, January 30, 2008 11:22:16 AM
Subject: Re: [computer-go] 19x19 Study - prior in bayeselo
According to Sensei's Library, nakade is:
It refers to a situation in which a group has a single large
internal, enclosed space that can be made into two eyes by the right
move--or prevented from doing so by an enemy move.
Several examples are shown that where there are exactly 3
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
Does mogo have a play-out rule that says, don't move into self-atari?
If so, then I can see how the play-out would miss this.
But the tree search would not miss this.I still don't see the
problem. I can see how a play-out strategy would delay the
understanding of positions, but that's
While bigger examples exist, 4 in a line (with both ends enclosed) is not
nakade because the two center points are miai (b and c in your example). It
requires two moves (both b and c) to reduce your example to a single eye.
Because of that, it is not nakade.
A comprehensive list of nakade shapes
] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Don Dailey
Sent: Tuesday, January 29, 2008 7:18 PM
To: computer-go
Subject: Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS
study
I wish I knew how that translates to win expectancy (ELO rating.)Is
3 kyu at this level a pretty
It would get it eventually, which means this doesn't inhibit scalability.
I don't expect every aspect of a program to improve at the same rate -
but if a program is properly scalable, you can expect that it doesn't
regress with extra time. It only moves forward, gets stronger with
more
Vlad Dumitrescu wrote:
Hi Don,
On Jan 30, 2008 9:02 PM, Don Dailey [EMAIL PROTECTED] wrote:
According to Sensei's Library, nakade is:
It refers to a situation in which a group has a single large
internal, enclosed space that can be made into two eyes by the right
move--or
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
Hi Don,
On Jan 30, 2008 9:02 PM, Don Dailey [EMAIL PROTECTED] wrote:
According to Sensei's Library, nakade is:
It refers to a situation in which a group has a single large
internal, enclosed space that can be made into two eyes by the right
move--or prevented from doing so by an
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, January 30, 2008 12:15:04 PM
Subject: Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study
While bigger examples exist, 4 in a line (with both ends enclosed) is not
nakade because the two
-go.org
Sent: Wednesday, January 30, 2008 11:53:57 AM
Subject: Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS study
You're not crazy. Gmail shows it that way too.
On Jan 30, 2008 2:49 PM, Don Dailey [EMAIL PROTECTED] wrote:
Is is just my email client or does Terry's post have one word
On Tue, 29 Jan 2008, Don Dailey wrote:
I wish I knew how that translates to win expectancy (ELO rating.)Is
3 kyu at this level a pretty significant improvement?
in the order of 90%
Christoph
___
computer-go mailing list
To: computer-go
Subject: Re: [computer-go] 19x19 Study - prior in bayeselo, and KGS
study
I wish I knew how that translates to win expectancy (ELO rating.)Is
3 kyu at this level a pretty significant improvement?
- Don
Hiroshi Yamashita wrote:
Instead of playing UCT bot vs UCT
On Jan 30, 2008 3:51 PM, terry mcintyre [EMAIL PROTECTED] wrote:
There are other shapes which are known to be dead. For example, four
points in a square shape make one eye, not two. If the defender plays one
point, trying to make two eyes, the opponent plays the diagonally opposite
point,
On Wed, Jan 30, 2008 at 03:23:35PM -0500, Don Dailey wrote:
Having said that, I am interested in this. Is there something that
totally prevents the program from EVER seeing the best move?I don't
mean something that takes a long time, I mean something that has the
theoretical property
Heikki Levanto wrote:
On Wed, Jan 30, 2008 at 03:23:35PM -0500, Don Dailey wrote:
Having said that, I am interested in this. Is there something that
totally prevents the program from EVER seeing the best move?I don't
mean something that takes a long time, I mean something that has
On Jan 30, 2008 4:35 PM, Don Dailey [EMAIL PROTECTED] wrote:
Heikki Levanto wrote:
On Wed, Jan 30, 2008 at 03:23:35PM -0500, Don Dailey wrote:
Having said that, I am interested in this. Is there something that
totally prevents the program from EVER seeing the best move?I don't
Regardless of the exact example, _if_ pruning rules exclude a move,
then an engine will never play it. That means that for that
situation, they're not scalable. That may be a big if but will
definitely affect some bot implementations. Progressive widening and
soft-pruning rules probably
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
Le mercredi 30 janvier 2008, Don Dailey a écrit :
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.I can't believe mogo
I agree with this completely. If fixing this problem was just a simple
matter of course, then I'm sure the mogo team would have done so very
quickly.The cure could be worse than the disease in this case.
But I think what we forget is that this discussion has been hijacked in
a sense,
Good position. I think this illustrates my point.
In this case we are not talking about whether a program is capable of
seeing a nakade position, but instead a situation very complicated to
the extent that even very strong players missed it.
For instance I would not use this position to
[EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, January 30, 2008 3:14:24 PM
Subject: Re: [computer-go] 19x19 Study. Nakade is difficult
Good
position.
Be a better
Earlier Don Dailey asked how much of a difference it would make, if UCT
programs understood nakade plays.
I'll throw out a ballpark figure: if the current UCT programs understood nakade
as well as I do ( which is not terribly well), that would make four handicap
stones difference on a 19x19
-go] 19x19 Study. Nakade is difficult
Good
position.
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt
terry mcintyre wrote:
Earlier Don Dailey asked how much of a difference it would make, if UCT
programs understood nakade plays.
But actually they already understand nakade play. It was a
misconception that they don't, and I at first believed it because I
didn't know for sure what nakade
Don, welcome to my battle last week (or was it the week before?). It was the exact same discussion. I don't know if people are assuming that a typical UCT
reference implementation does not consider all moves or if they just don't understand the difference between a playout policy and a tree
I believe you COULD improve as fast as that young guy you are talking
about, but you would need to do serious study. Not read some books
while watching television, but putting yourself in a quiet room and
being totally focused.A 3 dan teacher would help enormously.
Agreed. It
Don Dailey: [EMAIL PROTECTED]:
About Don's arguments on self testing:
I would agree at 100% if it wasn't for the known limitations:
Nakade, not filling own eyes, etc. Because the program is blind
to them it is blind in both senses: it does not consider those
moves when defending, but it
Are you kidding? That's based on only 10 games.
Hideki Kato wrote:
Don Dailey: [EMAIL PROTECTED]:
About Don's arguments on self testing:
I would agree at 100% if it wasn't for the known limitations:
Nakade, not filling own eyes, etc. Because the program is blind
to them it is blind in both
...
That mogo would not know to move to nakade point c1 with either color?
Mogo tends to get confused on nakade positions when there are still
external liberties. Here is my report on this with a couple of examples:
http://computer-go.org/pipermail/computer-go/2007-October/011327.html
If I've
2008/1/30, Don Dailey [EMAIL PROTECTED]:
It would get it eventually, which means this doesn't inhibit scalability.
Having said that, I am interested in this. Is there something that
totally prevents the program from EVER seeing the best move?I don't
mean something that takes a long
On Jan 29, 2008 10:01 AM, Don Dailey [EMAIL PROTECTED] wrote:
FatMan seems to hit some kind of hard limit rather suddenly. It
could be an implementation bug or something else - I don't really
understand this. It's very difficult to test a program for
scalability since you are limited
The 9x9 scalability study has been a huge success with 35 cpu's
participating and several volunteers.This means we got about a month
of testing done per day and have the equivalent of about a years worth
of data or more.We are considering whether to extend the study a bit
more to test
No, FatMan is a primitive UCT player, so it builds a tree in memory.
I am not willing to extend it beyond the current level as it is a
resource hog. Mogo is playing at the same strength in far less time.
- Don
Jason House wrote:
On Jan 29, 2008 10:01 AM, Don Dailey [EMAIL PROTECTED]
I'd be willing to donate some CPU time. I run Ubuntu linux on a P4 3ghz with
1gig RAM. Can be configured with or w/o HT. (usually leave it off)
-Josh
On Jan 29, 2008 10:01 AM, Don Dailey [EMAIL PROTECTED] wrote:
The 9x9 scalability study has been a huge success with 35 cpu's
participating and
.
bayesian inference takes this into account, which is nice.
s.
- Original Message
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tuesday, January 29, 2008 1:46:56 PM
Subject: Re: [computer-go] 19x19 Study
They seem under-rated to me also. Bayeselo
But that's not relevant for this study. All that matters is the 14
out
of 20 total score and the order should not matter one little bit.
With players that change, that is very relevant however.
lemme think that over.
by the way, attached is what a quadratic fit looks like to the
however.
- Don
s.
- Original Message
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tuesday, January 29, 2008 1:46:56 PM
Subject: Re: [computer-go] 19x19 Study
They seem under-rated to me also. Bayeselo pushes the ratings
together
They seem under-rated to me also. Bayeselo pushes the ratings together
because that is apparently a valid initial assumption. With enough
games I believe that effect goes away.
I could test that theory with some work.Unless there is a way to
turn that off in bayelo (I don't see it) I
PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tuesday, January 29, 2008 2:18:30 PM
Subject: Re: [computer-go] 19x19 Study
steve uurtamo wrote:
it is a good thing to make your prior knowledge completely
fair (in the sense of not having any bias) when doing bayesian
calculations
On Tue, 29 Jan 2008, Álvaro Begué wrote:
Of course the value of A is the interesting number here. If they are using
anything like the common UCT exploration/exploitation formula, I think we
will see a roof fairly soon. In my own experiments at long time controls,
the program would spend entirely
Yes, you are right. But gnugo's 1800 rating is the only real point of
reference that I have. As you get farther away from 1800 I believe
it's the case that the true rating can be sloppy.
- Don
Sylvain Gelly wrote:
between pairs
of programs, you can get a more and more
Don Dailey wrote:
They seem under-rated to me also. Bayeselo pushes the ratings together
because that is apparently a valid initial assumption. With enough
games I believe that effect goes away.
I could test that theory with some work.Unless there is a way to
turn that off in bayelo (I
Instead of playing UCT bot vs UCT bot, I am thinking about running a
scaling experiment against humans on KGS. I'll probably start with 2k,
8k, 16k, and 32k playouts.
I have a result on KGS.
AyaMC 6k (5.9k) 16po http://www.gokgs.com/graphPage.jsp?user=AyaMC
AyaMC2 9k (8.4k) 1po
Rémi Coulom wrote:
Don Dailey wrote:
They seem under-rated to me also. Bayeselo pushes the ratings together
because that is apparently a valid initial assumption. With enough
games I believe that effect goes away.
I could test that theory with some work.Unless there is a way to
What are the time controls for the games?
- Don
Hiroshi Yamashita wrote:
Instead of playing UCT bot vs UCT bot, I am thinking about running a
scaling experiment against humans on KGS. I'll probably start with
2k, 8k, 16k, and 32k playouts.
I have a result on KGS.
AyaMC 6k (5.9k)
What are the time controls for the games?
Both are 10 minutes + 30 seconds byo-yomi.
Hiroshi Yamashita
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I don't feel like searching for it right now, but not too long ago someone posted a link to a chart that gave the winrates and equivalent rankings for different
rating systems.
Don Dailey wrote:
I wish I knew how that translates to win expectancy (ELO rating.)Is
3 kyu at this level a
Hiroshi Yamashita wrote:
What are the time controls for the games?
Both are 10 minutes + 30 seconds byo-yomi.
Hiroshi Yamashita
Good. I think that is a good way to test.
- Don
___
computer-go mailing list
computer-go@computer-go.org
We can say with absolute statistical certainty that humans when playing
chess improve steadily with each doubling of time.This is not a
hunch, guess or theory, it's verified by the FACT that we know exactly
how much computers improve with extra time and we also know for sure
that humans play
From: Don Dailey [EMAIL PROTECTED]
...
Rémi Coulom wrote:
...
Instead of playing UCT bot vs UCT bot, I am thinking about running a
scaling experiment against humans on KGS. I'll probably start with 2k,
8k, 16k, and 32k playouts.
That would be a great experiment. There is only 1
Eric Boesch wrote:
By the way, does anybody know of any nifty tools or heuristics for
efficient probabilistic multi-parameter optimization? In other words,
like multi-dimensional optimization, except instead of your function
returning a deterministic value, it returns the result of a Bernoulli
On Jan 23, 2008 7:39 PM, Jason House [EMAIL PROTECTED] wrote:
On Wed, 2008-01-23 at 18:57 -0500, Eric Boesch wrote:
I am curious if any of those of you who have heavy-playout programs
would find a benefit from the following modification:
exp_param = sqrt(0.2); // sqrt(2) times the
Eric Boesch
This is probably massive overkill, but one of the most
successful techniques for multi-parameter optimization
is Taguchi methods.
http://en.wikipedia.org/wiki/Taguchi_methods
However, in my experience, starting with the decisions
that make the biggest difference, and then adding
i recommend:
http://www.research.att.com/~njas/gosset/index.html
s.
- Original Message
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Saturday, January 26, 2008 2:35:01 PM
Subject: Re: [computer-go] 19x19 MC improvement
Eric Boesch
By the way, does anybody know of any nifty tools or heuristics for
efficient probabilistic multi-parameter optimization? In other words,
like multi-dimensional optimization, except instead of your function
returning a deterministic value, it returns the result of a Bernoulli
trial, and the
My program Aya637_4CPU is top on 19x19 CGOS now.
It is temporary, but I'm so happy!
Please don't run full power MoGo, Crazy Stone and Leela :-)
My main improvement was
1. Do not move dead stones.
Before doing playout, Aya does string capture search up to 7 plies(ladders
are extended). And set
Congratulations! I'm really impressed with how fast the AyaMC improved.
Regards,
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Hiroshi Yamashita
Sent: Wednesday, January 23, 2008 12:12 AM
To: computer-go
Subject: [computer-go
On Jan 23, 2008 3:11 AM, Hiroshi Yamashita [EMAIL PROTECTED] wrote:
2. Change UCT exploration parameter
exp_param = sqrt(2.0);
uct = exp_param * sqrt( log(sum of all children playout) /
(number of child playout) );
uct_value = (child winning rate) + uct;
I
On Wed, 2008-01-23 at 18:57 -0500, Eric Boesch wrote:
I am curious if any of those of you who have heavy-playout programs
would find a benefit from the following modification:
exp_param = sqrt(0.2); // sqrt(2) times the original parameter value.
uct = exp_param * sqrt( log(sum of all
Have you selected the room with bot's name as a member?
Yes. Seemingly only public rooms are possible for bots.
I'm interested in if someone has a solution for private rooms.
Olivier
___
computer-go mailing list
computer-go@computer-go.org
1 - 100 of 242 matches
Mail list logo
