hi, eric cotsen (sponsor of the cotsen open) is having a go party at
his house on the beach in mailbu on saturday, july 26'th. mr. yang
(7p) will be there. anyone on this list that is in the area is welcome to come.
send me an email off the list for the details.
thanks
---
vice-chair http://o
The dates for the Cotsen Go Tournament have been decided. The
tournament will be held on September 20 and 21 at the Tom Bradley
International Hall on the UCLA campus. This is the same location
where the Toyota Denso North American Oza was held this past January.
thanks
---
vice-chair http://o
In message
<[EMAIL PROTECTED]>,
Ray Tayek <[EMAIL PROTECTED]> writes
The dates for the Cotsen Go Tournament have been decided. The
tournament will be held on September 20 and 21 at the Tom Bradley
International Hall on the UCLA campus. This is the same location where
the Toyota Denso North Ame
At 03:08 AM 7/11/2008, you wrote:
In message
<[EMAIL PROTECTED]>,
Ray Tayek <[EMAIL PROTECTED]> writes
The dates for the Cotsen Go Tournament have been decided. The
tournament will be held on September 20 and 21 at the Tom Bradley
International Hall on the UCLA campus. This is the same locati
I tracked down a rare hang/crash in my bot and I'm curious how others
handle this.
I use simple ko state as part of my hash lookup, but I don't use super
ko. I can't store the whole graph history because then there would be
no transpositions at all. I can't really update legal moves to excl
My sense is that most programs ignore superko except for checking
right before a "real" move (as opposed to a playout move) is played.
The way out of the infinite loop is to set a maximum number of moves
in a playout; abort the playout if you reach this threshold.
On Jul 11, 2008, at 9:03 A
I had the same issue in UCT tree. What I did is to check if the current
node is a ko move, then compare it with its latest 6 ancestors. If any match
is found, then consider the move is a loss. So it cuts off the infinite
loop.
On Fri, Jul 11, 2008 at 12:08 PM, Peter Drake <[EMAIL PROTECTED]> wrot
On Jul 11, 2008, at 12:08 PM, Peter Drake <[EMAIL PROTECTED]> wrote:
My sense is that most programs ignore superko except for checking
right before a "real" move (as opposed to a playout move) is played.
That was my preference too, but...
The way out of the infinite loop is to set a maximum
Since the tree is of finite size, you will eventually get to the
nondeterministic part of the playout. The moves here will probably
finish the playout (one way or another) before hitting the maximum
move threshold, so the playout will not be aborted but will update the
tree.
On Jul 11, 20
On Jul 11, 2008, at 12:43 PM, Peter Drake <[EMAIL PROTECTED]> wrote:
Since the tree is of finite size, you will eventually get to the
nondeterministic part of the playout.
Unforunately, no. A graph cycle has finite size, in the case I
debugged yesterday, it took only 4 nodes. I'm not sure h
Ah, I forgot that you had a transposition table. (Orego currently does
not.)
I, too, will be interested to hear the solution to this problem.
Peter Drake
http://www.lclark.edu/~drake/
On Jul 11, 2008, at 10:49 AM, Jason House wrote:
On Jul 11, 2008, at 12:43 PM, Peter Drake <[EMAIL PROTECT
2008/7/12 Jason House <[EMAIL PROTECTED]>:
> I tracked down a rare hang/crash in my bot and I'm curious how others handle
> this.
>
> I use simple ko state as part of my hash lookup, but I don't use super ko. I
> can't store the whole graph history because then there would be no
> transpositions at
Another possibility would be to keep a list of nodes visited in the
"tree" on each playout. In the rare event where the length of this
list exceeds some max game length threshold, go back through the list
looking for repetitions. Mark the first move that led to a repetition
as a loss for th
I can operate a couple of robots, and probably find more operators if
needed.
If someone wants/needs Mac, I can provide that. If Linux required, I
can probably bring a linux computer if you notify me before Tuesday
July 16.
We now have around 700 participants in the main tournament which
I guess you missed my message.
I solved this by comparing the current node with its ancestors in the path.
On each walking down the tree, I pass the list of nodes in the same path.
Then I check whether the current node already appear in the path. If yes, I
assign a loss there. To speed it up, I o
I will be attending the US Congress in Portland, OR from Aug 2-10. Will be
bringing a core 2 duo laptop running Linux.
Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
MemTotal: 2034016 kB
If anyone needs an operator for the Computer Go tournament, let me know. Can
use my laptop or (if you
Do you always check it? Would it be faster to hold off on this check
until you realize that you're in a cycle?
On Jul 11, 2008, at 12:06 PM, John Fan wrote:
I guess you missed my message.
I solved this by comparing the current node with its ancestors in
the path. On each walking down the
I checked it whenever the current move is ko. And I think I only checked
against the latest 6 (or 8) ancestors. And only check it against the node
with even distance in the tree. And I am passing down the list of pointers,
so the comparison is not that much work. It is only pointer comparison, only
On Jul 11, 2008, at 4:42 PM, "John Fan" <[EMAIL PROTECTED]> wrote:
I checked it whenever the current move is ko. And I think I only
checked against the latest 6 (or 8) ancestors. And only check it
against the node with even distance in the tree. And I am passing
down the list of pointers, s
I agree that the check against two moves back is not necessary.
As for the solution, I think it is good enough to prevent the infinite loop
at least for the current level of my engine. StoneGrid had relatively often
crashes due to superko by running out of stack. But there is no crashes due
to the
20 matches
Mail list logo
