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
That information is in the autotester, but it wouldn't be accurate on
the main page since many computers of various types and with various
loads are being used in the study.
I suppose one could argue that the total conglomerate average would be
reasonably accurate according to the law of
Any chance of adding a new column to the CGOS result tables to show the average
amount of time used per game?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
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
Hi,
I don't know exactly when it begins to do bad moves. However, I know that
after several hours, the estimated winning rate converges to 1 or 0, with
crazy principal variations, and the cause is low resolution of single
floats. In this study, it should no be a big factor of unscalability given
Recently one of the things I've been doing is introducing more and
more generics in my code. In the days when I was using C++ I always
felt templates were a mixed blessing. It's a powerful concept but it
also often makes code extremely difficult to read and debug. Maybe
this has improved a
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
But
if
ever
there's
new
version
of
GTP
in
the
making
I
would
suggest
replacing
the
'komi'
and
'board_size'
commands
by
a
more
general
'set
property-
name
property-value'
command
and
turn
the
Go
Text
Protocol
more
into
a
Game
Text
Protocol.
okay,
On Wed, Jan 30, 2008 at 01:15:39PM -0200, Mark Boon wrote:
There's one bit that so far thwarts my effort to obtain maximum
modularization. And that is I have a GoEngine interface that is kind
of mirroring GTP, since GTP is the preferred communication method
between Go-playing engines. My
I didn't say there was a big difference. It's simply a matter of
elegance, if none of the commands are game-specific a large part of
the protocol implementation can be abstracted. I suppose beauty is
in the eye of the beholder.
On 30-jan-08, at 14:23, Heikki Levanto wrote:
On Wed, Jan
On Jan 30, 2008 12:02 PM, steve uurtamo [EMAIL PROTECTED] wrote:
you should rename the protocol TP then.
Or just call it game text protocol ;)
___
computer-go mailing list
computer-go@computer-go.org
On 30-jan-08, at 15:06, Jason House wrote:
On Jan 30, 2008 12:02 PM, steve uurtamo [EMAIL PROTECTED] wrote:
you should rename the protocol TP then.
Or just call it game text protocol ;)
Which is of course exactly what I said in my message. Maybe it's the
idealist in me thinking we
you should rename the protocol TP then.
s.
- Original Message
From: Mark Boon [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, January 30, 2008 11:47:32 AM
Subject: Re: [computer-go] More generic GTP
I
didn't
say
there
was
a
big
difference.
It's
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
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 doesn't do this, it would be very weak
if it didn't.
We could test this: find some nakade problems in the games, crank up the number
of simulations, and see if Mogo finds the crucial moves.
There's the question of how long eventually is.
I
Terry McIntyre [EMAIL PROTECTED]
“Wherever is found what is called a paternal government, there is found
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
Is is just my email client or does Terry's post have one word per line
when quoting others?
- Don
terry mcintyre wrote:
Someone recently posted a 19x19 example. Mogo failed to defend it's position.
Terry McIntyre [EMAIL PROTECTED]
“Wherever is found what is called a paternal government,
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,
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 per line
when quoting others?
- Don
terry mcintyre wrote:
Someone recently posted a 19x19 example. Mogo failed to
Someone recently posted a 19x19 example. Mogo failed to defend it's position.
Terry McIntyre [EMAIL PROTECTED]
“Wherever is found what is called a paternal government, there is found state
education. It has been discovered that the best way to insure implicit
obedience is to commence tyranny
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
Le mercredi 30 janvier 2008, David Fotland a écrit :
3 kyu at this level is a lot for a person. I've know club players who never
got better than 9k, and people who study and play may still take a year or
more to make this much improvement.
Many club players stall somewhere between 7k and 4k
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
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, which is
the center of three; the group dies.
I think yahoo changed something. I first saw this on Steve's posts, and he also
uses Yahoo. I haven't changed anything on my preferences, so blame Yahoo for
tinkering with their software.
Terry McIntyre [EMAIL PROTECTED]
“Wherever is found what is called a paternal government, there is found
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
Alain Baeckeroot wrote:
Le mercredi 30 janvier 2008, David Fotland a écrit :
3 kyu at this level is a lot for a person. I've know club players who never
got better than 9k, and people who study and play may still take a year or
more to make this much improvement.
Many club players
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
That particular position is indeed complex, but there are many simpler
variations which are not at all difficult to construct.
20kyu human players eventually learn to recognize when their 10 kyu opponents
trap them via the simpler positions. 1dan amateur players play still subtler
versions.
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
terry mcintyre wrote:
That particular position is indeed complex, but there are many simpler
variations which are not at all difficult to construct.
20kyu human players eventually learn to recognize when their 10 kyu opponents
trap them via the simpler positions. 1dan amateur players
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
I was not talking about the study. I was talking about the main CGOS servers.
Don Dailey wrote:
That information is in the autotester, but it wouldn't be accurate on
the main page since many computers of various types and with various
loads are being used in the study.
I suppose one could
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
See the handtalk's winning rates on cgos 9x9
(http://cgos.boardspace.net/9x9/cross/handtalk.html).
He won agains MoGo at 60% but his rating is about 200 ELO behind
it. This happened probably because he know MoGo's weakpoint,
misunderstanding of LD at corners (including Nakde) very well,
...
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
Darren Cook: [EMAIL PROTECTED]:
See the handtalk's winning rates on cgos 9x9
(http://cgos.boardspace.net/9x9/cross/handtalk.html).
He won agains MoGo at 60% but his rating is about 200 ELO behind
it. This happened probably because he know MoGo's weakpoint,
misunderstanding of LD at
Cgos 19x19 is down, I'm trying to fix
that (more serious trouble
than usually, it is seemingly a
trouble on the machine, which
is the only one allowed
to be connected from outside
the university).
Olivier
___
computer-go mailing list
65 matches
Mail list logo
