sorry to be pedantic, but:
13. Chinese scoring.
s.
On Sat, Oct 11, 2008 at 9:11 AM, Don Dailey [EMAIL PROTECTED] wrote:
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
I think I already add a 13, so you must mean 14 :-)
- Don
On Mon, 2008-10-13 at 09:48 -0400, steve uurtamo wrote:
sorry to be pedantic, but:
13. Chinese scoring.
s.
On Sat, Oct 11, 2008 at 9:11 AM, Don Dailey [EMAIL PROTECTED] wrote:
On Sat, 2008-10-11 at 13:33 +0100, Claus Reinke
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
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
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 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
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
19 matches
Mail list logo
