It is important to know about potential blind spots introduced by pseudo-eye
variations, or any
other rules.
Borrowing from Eric S Raymond, the more eyes inspecting the ideas, the
shallower the bugs.
Thanks! Here goes another attempt, this time trying to construct an
example where
On Sat, 2008-10-11 at 13:33 +0100, Claus Reinke wrote:
I have a rough idea of what that might be. And I suspect that keeping
this
de facto standard implicit has been hiding some actual differences
in what
different people think that standard is. Some of my questions arise
from trying
to pin
There is a de facto standard light playout policy (algorithm).
I have a rough idea of what that might be. And I suspect that keeping this
de facto standard implicit has been hiding some actual differences in what
different people think that standard is. Some of my questions arise from trying
to
During the last few days I have been meditating a lot about
the questiion whether taking into account the margin of
win into MCTS (UCT) may help or hurt.
I do not have a go program by my own, so for the moment
I have to believe what programmers are saying, namely
that MCTS with margin of win as a
Reminder - it's tomorrow.
The October 2008 KGS computer Go tournament will be on Sunday October
12th, in the Asian evening, European morning and American night,
starting at 08:00 UTC (GMT) and ending soon after 12:00 UTC (GMT).
The Formal division will be a 6-round Swiss with 13x13 boards
Don's draft standard reminded me of the corner cases. So here's
an even simpler example, this time trying to show that dead invading
stones can poison playout analysis depending on which definition of
pseudo-eyes is used ('a' is A1, 'b' is C1).
That makes three attempted examples so far (are the
Thanks! Here goes another attempt, this time trying to construct an
example where pseudo-eyes prevent a necessary fill-in ('a' is J15,
'b' is L17, 'c' is F12, and 'd' is K16).
..
GN[playout-eyes2]
Sorry about that one! I must have been thinking of some form of
Carpenter's square or square
If you don't have sueperko, I think you need a maximum moves stopping
criteria too.
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Don Dailey
Sent: Saturday, October 11, 2008 6:11 AM
To: computer-go
Subject: [computer-go] simple MC
Yes, it's understood that the eye rule most of us use is not perfect and
we have identified bad cases before on this list.
My analogy is that you wouldn't put expensive leather seats in a cheap
economy car. A simple eye rule is more than sufficient for random
play-outs. A more sophisticated
I found one specified issue that must be handled and requires an
additional specification.
What to do to limit the length of the playout games? As was discussed
in the last couple of days or so there are possible cases with multiple
ko threats.
Please not that the solution I am about to
On Sat, Oct 11, 2008 at 8:11 AM, Don Dailey [EMAIL PROTECTED] wrote:
I'm going to publish a real simple java reference program and some docs
to go with it and a program to test it for black box conformance.
(Actually, it will test 2 or more and compare them.) I would like to
get someone who
11. When selecting moves to play in the actual game (not playouts)
superko is checked and forbidden.
positional superko (as opposed to situational superko).
- Dave Hillis
-Original Message-
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sat,
On Oct 11, 2008, at 2:40 PM, [EMAIL PROTECTED] wrote:
11. When selecting moves to play in the actual game (not playouts)
superko is checked and forbidden.
positional superko (as opposed to situational superko).
Whatever is used by the rules... I know CGOS and KGS Chinesee use
On Sat, 2008-10-11 at 13:34 -0500, Zach Wegner wrote:
Wouldn't it make more sense to run an equal number of playouts for
each root move?
No, because with AMAF you will get different game counts ANYWAY.
And also I believe most programs are viewing the level in playouts as a
fixed number of
On Sat, 2008-10-11 at 13:34 -0500, Zach Wegner wrote:
7. In the case of moves with even scores a random selection is
made.
I think maybe this should be something deterministic.
That of course is clearly a possibility. However I'm trying to
approach this with a certain consistent
The 2nd GPW Cup Gomputer Go Tournament will be held as a night event
of Game Programming Workshop 2008.
GPW2008: http://sig-gi.c.u-tokyo.ac.jp/gpw/2008/ (in Japanese)
#Those who can't read Japanese and have interests in paticipating GPW
Cup Computer Go Tournament, please mail me.
The 13th Game
On Sat, 2008-10-11 at 13:34 -0500, Zach Wegner wrote:
11. When selecting moves to play in the actual game (not playouts)
superko is checked and forbidden.
That's fine for this spec, but I don't do this and don't plan on it.
You don't have to do it, it's just a provision to allow your
On Sat, 2008-10-11 at 14:40 -0400, [EMAIL PROTECTED] wrote:
11. When selecting moves to play in the actual game (not playouts)
superko is checked and forbidden.
positional superko (as opposed to situational superko).
Thank you. I forgot to specify which.
- Don
- Dave
On Sat, 2008-10-11 at 14:48 -0400, Jason House wrote:
Whatever is used by the rules... I know CGOS and KGS Chinesee use
positional super ko. I don't know which rule sets would use
situational. Situational makes more sense to me.
I've always personally preferred situation super ko (probably
On point 13.
1 stone captures, may eventually be hard for some implementation.
I think using game length as a criterion gives more freedom.
Then you have to specify what to do with those pathological games anyway.
Do you score them as they are, or do you drop them. I do count them.
The rule for
On Sat, 2008-10-11 at 21:46 +0200, Denis fidaali wrote:
On point 13.
1 stone captures, may eventually be hard for some implementation.
I think using game length as a criterion gives more freedom.
I definitely considered that. My own program returns the number of
stones captured (and a list
Don Dailey wrote:
Are there any MC programs out that cannot detect whether they made a one
stone capture and it would be unduly difficult to fix this?
They would have to detect that to detect simple Ko.
Speaking of which, wouldn't it be better to limit consecutive Kos instead of
limiting
On Sat, 2008-10-11 at 16:32 -0400, Michael Williams wrote:
Don Dailey wrote:
Are there any MC programs out that cannot detect whether they made a one
stone capture and it would be unduly difficult to fix this?
They would have to detect that to detect simple Ko.
That's a good point.
Don Dailey wrote:
Speaking of which, wouldn't it be better to limit consecutive Kos instead of
limiting consecutive 1-stone captures?
Wouldn't this definitely slow down most if not all light implementations
and require code changes to existing programs? My own programs do not
really know
On Sat, 2008-10-11 at 16:55 -0400, Don Dailey wrote:
To fix this I would have to test every move just to see if there is a
ko
situation (although there are no doubt some shortcuts.)
One shortcut is to simply not test for this until after you make a 1
stone capture, then test all possible
On Sat, 2008-10-11 at 17:01 -0400, Michael Williams wrote:
Don Dailey wrote:
Speaking of which, wouldn't it be better to limit consecutive Kos instead
of limiting consecutive 1-stone captures?
Wouldn't this definitely slow down most if not all light implementations
and require code
Ingo Althöfer wrote:
During the last few days I have been meditating a lot about
the questiion whether taking into account the margin of
win into MCTS (UCT) may help or hurt.
I do not have a go program by my own, so for the moment
I have to believe what programmers are saying, namely
that MCTS
David Fotland suggested another rule, tell me what you think.
His rule is to stop the game at or beyond move N*N*2 where N is the
board size and score the board no matter what. But in the play-outs he
first plays 1 move before making this test.
If a game actually lasts that long, the
Google translate does a pretty god job of translating these pages.
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Hideki Kato
Sent: Saturday, October 11, 2008 12:13 PM
To: computer-go@computer-go.org
Subject: [computer-go] 2nd
On Sat, 2008-10-11 at 22:33 +0100, Raymond Wold wrote:
Ingo Althöfer wrote:
During the last few days I have been meditating a lot about
the questiion whether taking into account the margin of
win into MCTS (UCT) may help or hurt.
You are not alone! I think most of us have looked into
Don Dailey wrote:
Are you speculating that if enough play-outs are done, the idea might
prove to be superior?I never actually considered that. So perhaps
with 5000 playouts using the win/loss score wins, but at 50,000 using
the margin might be better? This is easy to test with simple
On Sat, 2008-10-11 at 23:49 +0100, Raymond Wold wrote:
Don Dailey wrote:
Are you speculating that if enough play-outs are done, the idea might
prove to be superior?I never actually considered that. So perhaps
with 5000 playouts using the win/loss score wins, but at 50,000 using
On 11-okt-08, at 20:32, Don Dailey wrote:
I believe there have been many attempts to make this work. These
attempts are based on the intuition that the margin approach should be
better even though it is clearly inferior. So in my opinion they
start
with a wrong premise. And this wrong
33 matches
Mail list logo
