Jason House wrote:
I use atomic increments and atomic reads. It's really simple x86
assembly. To do that, I used to have a counter for wins and a total
simulations counter, but switched to wins and losses counter. Doing
that allows independent increments to those counters.
In my
But in game 739216 the stones are the same, but the other color is moving.
That can't be a repetition...
Look at the end of the game. Move 72 is white J1, Black captures 2 stones
with 73 G1, now white wants to recapture with 74 H1. The position is the
same as on white 72, but it is black's turn.
Brian Sheppard wrote:
But in game 739216 the stones are the same, but the other color is
moving. That can't be a repetition...
Look at the end of the game. Move 72 is white J1, Black captures 2
stones with 73 G1, now white wants to recapture with 74 H1. The position
is the same as on white
2009/4/14 Brian Sheppard sheppar...@aol.com:
But in game 739216 the stones are the same, but the other color is moving.
That can't be a repetition...
Well, that's what distinguishes _positional_ superko from _situational_
superko. See http://senseis.xmp.net/?Superko .
As Jason House wrote,
Richard Brown wrote:
Positional superko, IMHO, has no such elegant rationale.
It is a ko rule that depends on only what one can see on the board.
Elegant.
It is a ko rule that depends on one type of information only: The colour
of each intersection.
Elegant.
It is the superko rule that has
2009/4/14 Richard Brown batma...@gmail.com:
Situational superko can be defined in terms of not permitting a
cycle in the game-tree, thus always preserving its acyclic nature.
[Positional superko, IMHO, has no such elegant rationale.]
Agree, situational superko seems to me much more
elegant.
In message
72e25bef0904140750n7776a8a4xb96bdc7cd34d5...@mail.gmail.com, Richard
Brown batma...@gmail.com writes
2009/4/14 Brian Sheppard sheppar...@aol.com:
But in game 739216 the stones are the same, but the other color is moving.
That can't be a repetition...
Well, that's what
2009/4/14 Andrés Domínguez andres...@gmail.com:
2009/4/14 Richard Brown batma...@gmail.com:
Situational superko can be defined in terms of not permitting a
cycle in the game-tree, thus always preserving its acyclic nature.
[Positional superko, IMHO, has no such elegant rationale.]
Agree,
Nick Wedd wrote:
the writer(s) of the Chinese rules did not
intend to specify Positional Superko.
To discuss Chinese ko rules properly, one should include the referee ko
rules, which override superko in long cycle shapes.
Andrés Domínguez wrote:
situational superko seems to me much more
On Tue, Apr 14, 2009 at 10:51 AM, Robert Jasiek jas...@snafu.de wrote:
Richard Brown wrote:
Positional superko, IMHO, has no such elegant rationale.
It is a ko rule that depends on only what one can see on the board.
Elegant.
And what is the _reason_ to leave out the information of whose
This conversation is rather futile. The CGOS website contains rules
that clearly state that positional superko is used. There is no bug.
Nothing to see here.
If you like other rules better, you can implement them in your own server.
Álvaro.
On Tue, Apr 14, 2009 at 1:21 PM, Richard Brown
Richard Brown wrote:
And what is the _reason_ to leave out the information of whose turn it is?
Elegant, but not a _rationale_.
One can do two basic things with information: use it or ignore it.
Unless we set other principles as a context, we cannot judge which of
the two is better.
You
Please take the ensuing rules argument/discussion off-list. The last
ko rules discussion resulted in way too many e-mails in everyone's
inbox.
Sent from my iPhone
On Apr 14, 2009, at 2:06 PM, Robert Jasiek jas...@snafu.de wrote:
Richard Brown wrote:
And what is the _reason_ to leave out
In message
2c004b8d0904140908g50b0c2c7rdd01d9f0985fc...@mail.gmail.com, Zach
Wegner zweg...@gmail.com writes
2009/4/14 Andrés Domínguez andres...@gmail.com:
2009/4/14 Richard Brown batma...@gmail.com:
Situational superko can be defined in terms of not permitting a
cycle in the game-tree, thus
On Apr 14, 2009, at 11:06 AM, Robert Jasiek wrote:
To offer an on-topic reason: positional superko requires less storage
and execution time than situational superko.
--
robert jasiek
Really?
Go programs already store side-to-move as part of the board state.
For ko detection, you
Jason House wrote:
Also, you've commented previously about not resizing your table. If
you're using Cliff's algorithm, how do you clear tombstones? I assume
copying the table is nearly as much work as dynamic resizing. I
imagine in-place deletions could be done with the appropriate
Jason House wrote:
In my implementation, I found that node allocation is the most
difficult part. For a tree, I suppose it may be done easily by
pre-allocating a node pool for each thread, and managing memory
allocation locally.
I was happy to hear recently that the D standard library
I personally feel that situational superko is more elegant even though I
use PSK in CGOS.I did that mainly to be more compatible with KGS
rules and Tromp/Taylor rules.
I don't believe my arguments against it make much different in practice
and I'm a practical person but ...
Here is why I
I remember seeing a paper or something on this a good while back. If I
remember correctly, it is possible to legitimately criticize both types
of superko based on some obscure corner cases that are possible. I
don't remember the details and I'm certainly no expert.
- Don
On Tue, 2009-04-14
On Apr 14, 2009, at 6:46 PM, Rémi Coulom remi.cou...@univ-lille3.fr
wrote:
Jason House wrote:
In my implementation, I found that node allocation is the most
difficult part. For a tree, I suppose it may be done easily by pre-
allocating a node pool for each thread, and managing memory
Jason House wrote:
Out of curiosity, how do you intelligently delete old nodes? Reference
counting won't always work due to cycles, and a nieve scan of the tree
could block all threads.
I store a date of birth in every node. At the beginning of a new search,
I increment time, and refresh the
Don Dailey wrote:
If you play a
game of go, it almost always matters who's turn to move it is.
This is so also for positional superko.
If it's
my turn to move it's a different position than if it's your turn to
move, even if the stones are sitting in the same exact location.
Technical
Robert, your reference to hane-seki, also called hanezeki, was new to me, so I
did a bit of googling. My head is now spinning; I figure that any program which
embodies the knowledge in the following paper should be quite interesting:
On Wed, 2009-04-15 at 02:35 +0200, Robert Jasiek wrote:
Technical remark: the position is the same, the situation differs.
I don't use the terminology correctly. To me a position is the game
state including side to move. But I know that is not accepted
terminology.
Since elegance is an
24 matches
Mail list logo
