Lukasz,
I have an implementation of your circular list in place, but I'm having
a difficult time dealing with the single point eyes which my program
does not allow as well as suicide which I don't allow either.
I built a little circular list and I put captured points back into the
circular
list
It would be interesting to see how your implementation performs on a
Core2 architecture. So how many 9x9 games does it currently play per
second? What about 19x19 games?
I don't know how many games it plays. As I said, I'm not really
interested in MC GO now. I played a few days with this c
At 07:53 PM 12/3/2006, you wrote:
A note: we're working on converting Orego back from C++ to Java, ...
this is probably a silly idea, but i was recalling how you defined
location in some of your previous code. also, you had arrays of
boards and neighbors. something like board[], north[], sou
I never finished this email.
I'm wondering how you handle the eye thing. I don't allow the program
to move to a single point eye but you said nothing about this. But if
you skip over that point now it might become legal later.
Those eyes must be put back into the pool. To get truly rando
Łukasz Lew,
I'm trying to implement this now. I think I see why our average moves
per game do not match.
First of all, suicide is illegal in my program, I do not allow it.
On Thu, 2006-12-07 at 16:05 +0100, Łukasz Lew wrote:
> I really do randomize a whole vector of empty intersections befor
I had been including pass as one of the possible random moves, just
as likely as any other. I reasoned that, if there is a seki on the
board, passing might be the best move.
On further thought, it's almost certainly more important to avoid
leaving dead stones on the board. I changed this an
112 moves on average in a 9x9 game? You are doing something a little
different than I am and others have reported the same number I get,
about 107.3 - 107.4
What is your eye avoid rule?
- Don
P.S. 30K on 1.4 Celeron is almost too good to be true. If this is
correct that's very impressive a
I found myself doing not simple or obvious elections
on the board/game implementation.
I found a couple of places where different approaches
would impact on perfomance:
- Liberties: maintain a list of chains, and liberties.
"Union set" when a stone is placed in the board.
Floodfill is another ap
Hi!
Many people are spending a lot of effort on creating fast board implementation.
I am considering releasing the one written by me.
I get 30 k playouts / s (112 moves on avg) on Celeron M 1.4Ghz. So I
consider it quite good.
If there is an interest in joint development, then I will do it.
Wha
A Hashtable is the "natural" solution to this. In a Hashtable it does not
matter if its a tree or a DAG. The hashtable works just better if it is a
DAG.
Chrilly
- Original Message -
From: "Peter Drake" <[EMAIL PROTECTED]>
To: "Computer Go"
Sent: Thursday, December 07, 2006 11:46 PM
S
Crikey -- it worked!
Incorporating moves into the tree with a transposition table, I'm
still getting 10,000 games per second with the dual cores. The games
are still purely random -- UCT is tomorrow's job.
I went ahead and (*shudder*) created the TwinNode objects on the fly,
rather than m
11 matches
Mail list logo
