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
I can well believe that a through implementation of even a flawed knowledge of
the game of Go will lead to fairly strong play.
For instance, given enough time, just knowing enough to keep score and remove
groups which are deprived of liberties would be enough to prune the more
egregious
I'm only 3 dan but I wouldn't mind taking a look. I suspect that there
might be some systematic issue causing the rolloff at high levels.
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Don Dailey
Sent: Thursday, January 31, 2008
UCT with light playouts that just avoid filling eyes is scalable, but much
weaker than the strongest programs at 19x19 go.
The strong programs have incorporated significant go knowledge, to direct
the search to promising lines (usually local), to order moves to try, and to
prune unpromising moves
David Fotland wrote:
UCT with light playouts that just avoid filling eyes is scalable, but much
weaker than the strongest programs at 19x19 go.
The strong programs have incorporated significant go knowledge, to direct
the search to promising lines (usually local), to order moves to try, and
I would like to see a very strong players analysis of some of the games
of Mogo at the high levels in the study, but I am very leery of
subjective human analysis. Even though I would like to see it, I
would take what I heard with a grain of salt.
I hate to keep bringing this up, but
There were some questions about the effective ELO difference of two players
3 ranks apart. Here are some links to information about go rating formulas,
and some statistics:
http://senseis.xmp.net/?KGSRatingMath
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
From: Don Dailey [EMAIL PROTECTED]
Yes,
basically
the
good
programs
prune
in
a
temporary
sense. We
call this
progressive
pruning
because
moves
are
identified
which
are extremely
unlikely
to
be
good,
but
when
the
depth
is
great
enough
they are
still
considered.
This implies that the top UCT programs are still over 1000 ELO points from
the top human amateurs.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy
Sent: Thursday, January 31, 2008 9:32 AM
To: computer-go
Subject: [computer-go] Go rating math information
There were some
terry mcintyre wrote:
I may have misunderstood, so please clarify a point.
Let's say the game hinges on solving a life-and-death problem - if you find
the right move, you win the game; if not, you lose. Many such problems - as
found in real games - are extremely order-dependent; there is
How do you compute that? I think the ELO values given are the rating
differences that correspond to the particular upset (win) rate. They're not
absolute ELO values. A truly absolute value is also tough to define. CGOS
picked its value somewhat arbitrarily.
On Jan 31, 2008 12:54 PM, David
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
Please can someone answer my question about playout rates? If you must make
some comment about scaling or nakade or anything similar, please change the
title and start a new thread.
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of
Since you hijacked my thread, I'm changing the title and injecting some data
:)
I tried to be very clear that I didn't want that thread to become another
scalability flame fest.
Here is a high level mogo game, level 15 vs level 16, that hinges on a life
and death problem that mogo gets wrong
ELO ratings don't have to be absolute, just self consistent. So if you
beat someone 7.2% of the time, that means you are about 440 ELO
stronger than him.
However, I don't understand what the K-factor has to do with anything.
scaling it up or down doesn't change anything. It's common
Sorry, the KGS formula uses a constant k which is different from the
K-factor in Elo.
P(A wins) = 1 / ( 1 + exp(k*(RankB-RankA)) )
This would be equivalent to changing the constant 400 in:
P(A wins) = 1 / ( 1 + 10^((Ra-Rb)/400)) )
EGF has a similar scheme except of course they use different
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
A few trick moves in a row can cause problems. But the cases where I am most
likely to be watching my bot's play through my fingers are when there is an
obvious (to a 20 Kyu like me) situation but it's some plys in the future. (Or
it can be pushed into the future!)
A case of seki is easy for
CrazyStone hasn't played since the initial spike to 1k in December. The
movement of the chart afterwards is rating drift.
On Jan 31, 2008 12:49 PM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote:
Don Dailey wrote:
I don't know how David figures 1000 ELO, but I would expect the
difference to
There seems to be a discrepancy: 11.5% between 2d and 5d in EGF rating system
versus 2.0% between 2d and 5d in KGS rating system.
I think this can be explained by hidden biases in the EGF statistics:
1: To be a 5d in real tournaments in Europe does not mean your rating is
between 2450 and 2550
From: Andy [EMAIL PROTECTED]
Sorry, the KGS formula uses a constant k which is different from the K-factor
in Elo.
P(A wins) = 1 / ( 1 + exp(k*(RankB-RankA)) )
This would be equivalent to changing the constant 400 in:
P(A wins) = 1 / ( 1 + 10^((Ra-Rb)/400)) )
EGF has a similar scheme except
I was shocked for a second, until I check Crazy Stone's playing record. Its
rating shot up after it stopped playing! It hasn't played a single rated
game on KGS since Dec 2, 2007.
On Jan 31, 2008 1:49 PM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote:
Don Dailey wrote:
I don't know how David
So if I get rated on KGS all I have to do is stop playing and my rank
will shoot up a few ranks?
- Don
Jason House wrote:
I was shocked for a second, until I check Crazy Stone's playing
record. Its rating shot up after it stopped playing! It hasn't
played a single rated game on KGS since
That's a crazy looking graph!It looks like CrazyStone was close to
1d last spring, then a version change (perhaps) dropped it back to 2k.
Then suddenly in Dec (a new version?) it jumped suddenly to 1d then
gradually increased to 1.5d
- Don
Gian-Carlo Pascutto wrote:
Don Dailey
A little more information on what CrazyStone's real performance on KGS has
been like during the time the graph depicts:
http://www.gokgs.com/gameArchives.jsp?user=crazystoneyear=2007month=3
http://www.gokgs.com/gameArchives.jsp?user=crazystoneyear=2007month=4
Yes, the math is attempting to model reality. :)
That's why I also included the EGF data which is based on observed
statistical upset rate. Of course those ratings are calculated using a
formula which pre-supposes an upset rate. Round and round. :)
On Jan 31, 2008 1:26 PM, terry
On Jan 31, 2008 2:20 PM, Don Dailey [EMAIL PROTECTED] wrote:
So if I get rated on KGS all I have to do is stop playing and my rank
will shoot up a few ranks?
It's a pretty common phenomenon on KGS... I've seen it happen many times
___
computer-go
Hi,
With such a large number of playouts, the tree size limit (and so
heavy pruning) is certainly a possible hypothesis. The simplest way to
test it would be to run the same MoGo_17 or _18 with a much bigger
tree (taking more memory). --collectorLimitTreeSize is by default
40 (number of
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
I'm going to call this the procrastination effect. MY claim is that, when
MC-UCT encounters a critical life and death board situation that its playout
policy consistently gets wrong, the search will naturally tend to skew the tree
so that relevant moves continue to be made during the playouts.
I mentioned nakade in a list including not filling own eyes. Perhaps,
not filling own eyes is a simpler example:
| . . . . . . .
| . # # . # . .
| . O # . # . .
| O O O . # # .
| # # O O O # .
| . # # . . . .
---
(Unless I made a mistake: Black to play and a1 is the only move
The other way around happens too: in 2006 I had a 4 month pause on KGS and my
rank dropped from 4d to 4k.
Van: [EMAIL PROTECTED] namens Jason House
Verzonden: do 31-1-2008 20:33
Aan: computer-go
Onderwerp: Re: [computer-go] Go rating math information
On Jan
On Jan 31, 2008 2:59 PM, [EMAIL PROTECTED] wrote:
I'm going to call this the procrastination effect. MY claim is that,
when MC-UCT encounters a critical life and death board situation that its
playout policy consistently gets wrong, the search will naturally tend to
skew the tree so that
At 11:44 AM 1/31/2008, David Doshay wrote:
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.
Universal binaries
At 11:44 AM 1/31/2008, David Doshay wrote:
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.
Universal binaries
Right you are. Silly me.
-Original Message-
From: Álvaro Begué [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 31 Jan 2008 3:06 pm
Subject: Re: [computer-go] not Go knowledge and UCT
On Jan 31, 2008 2:59 PM, [EMAIL PROTECTED] wrote:
I'm going to call this
This is the famous horizon effect chess programs are suckers for.
One interesting example of it happened to my program in a human
tournament years ago.
It played the classic Bxa7 getting it's bishop trapped by b6.
Computers used to be real suckers for this because it wins a pawn, but
In the tree search part, there is generaly no restriction to the moves that can
be played. So a UCT program should have no problem seeing that A1 is the best
move localy. However, A1 will be considered a 50% killing move, not 100%. This
is because UCT will have trouble looking ahead the forced
Janzert wrote:
I haven't seen anyone else mention this, although I may have missed it
in one of the previous discussions.
I find it pretty amazing that both Mogo and Fatman are leveling off at
exactly, or almost exactly, the same number of playouts (i.e. Fatman lvl
14 == Mogo lvl 18 ==
Hi,
I found the Master Thesis of Nobuo Araki is available online:
http://ark.qp.land.to/main.pdf
Abstract:
Recently in the Go program, there was a breakthrough by the Monte-Carlo
method using
a game tree search method called UCT (UCB applied to trees, UCB stands
for Upper Confidence
Bounds)
I recently upped mine from 32 bit to 64 bit. Once I put more checks in my
code, I found that stale data was getting reused. I may be an exception to
the rule though because I've never implemented a way to clear out old search
data. My engine is slow, so that's less of a problem in short CGOS
On Jan 31, 2008 4:31 PM, Don Dailey [EMAIL PROTECTED] wrote:
FatMan doesn't use a hash table to represent the tree, it actually uses
a tree with pointers and so on.
For detection of repetition in the search part, FatMan uses a 64 bit
zobrist key.
How do you find a pre-existing node to
FatMan doesn't use a hash table to represent the tree, it actually uses
a tree with pointers and so on.
For detection of repetition in the search part, FatMan uses a 64 bit
zobrist key.
- Don
steve uurtamo wrote:
how many bits are you guys using for your (presumably)
zobrist hashes? just
That's an interesting story. I just wish I hadn't precipitated it by sharing my
blinding flash of the obvious with the whole list. You are correct, of course.
I got so focused on something that I didn't see the forest for the trees.
- Dave Hillis
-Original Message-
From: Don Dailey
It has to be said that the game of Go differs from Chess in an important way.
There are many games where a skilled player can definitively say, this game is
won by so-and-so regardless of how clever the opponent may be, unless so-and-so
makes an egregious blunder.
Unlike chess, the Go board
On Thu, 31 Jan 2008, terry mcintyre wrote:
It has to be said that the game of Go differs from Chess in an
important way.
There are many games where a skilled player can definitively say, this
game is won by so-and-so regardless of how clever the opponent may be,
unless so-and-so makes an
Hello, Coulom. I'm Nobuo Araki.
Thank you for reading my thesis. However, this thesis is first version, not
final version. Therefore, there are too few experiments. And Mr. Hideki Kato
sent me many warnings about this thesis, for example English is too bad. You
may be confused while reading my
Hi Rémi and all,
It's not final version of his thesis, rather it has some (or a
lot of :) errors. Please wait for the final version.
-Hideki
Rémi Coulom: [EMAIL PROTECTED]:
Hi,
I found the Master Thesis of Nobuo Araki is available online:
http://ark.qp.land.to/main.pdf
Abstract:
Recently in
Sylvain,
These 2 parameters are confusing to me. --collectorLimitTreeSize
sounds like it limits the tree size to whatever your setting are, but
so does --limitTreeSize. What is the difference between a tree and
a collector tree?
I assume the collector is a garbage collector of some
54 matches
Mail list logo
