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 pr
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 usin
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 MC
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 in
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]
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 play-ou
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
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 req
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 mo
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 tha
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:
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 co
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
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
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 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
>
>
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 yo
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:
> > 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 met
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 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
positional
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
Sent: Sat, 11 Oct 2008 9:11 am
Subjec
On Sat, 2008-10-11 at 09:13 -0700, David Fotland wrote:
> If you don't have sueperko, I think you need a maximum moves stopping
> criteria too.
Yes, I just thought of that myself before I even saw your email and I
sent out an email addendum.
Superko would of course solve the problem, but I'm try
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 som
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 prop
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 rul
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 M
> 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
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 e
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
> 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 p
> 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
t
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 an
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
34 matches
Mail list logo
