On Dec 7, 2006, at 11:08 AM, Don Dailey wrote:
On Thu, 2006-12-07 at 09:17 -0800, Peter Drake wrote:
I do have the undo ability, but I think it's done in (I think) a
very
efficient way. For example, when I want to undo a bunch of move at
once (e.g., after a MC run) I just reduce a stack pointer.
BINGO! I'm pretty sure that is your problem.
My program does this too, but not during the random games. I make
single copy of the current state then play a random game from that
copy.
Obviously, it's faster to place a single stone on an existing board -
than to make a copy and then place a stone on the copy.
I'm not sure that would be true for Orego; playing moves involves a
bunch of operations on bit vectors, so there's plenty of writing to
memory anyway. The amount of copying I'm doing is pretty trivial; I'm
copying the 9 (or 19) ints that represent the board, but I'm not
copying a HashSet or anything silly like that.
In the search tree part of the game, (not the random simulation
part) I
make state copies, do Zobrist hashing and full repetition checks and
other stuff - the tree part is cheap.
Agreed -- the playing of moves is the expensive part.
No matter how you implement undo - it will cost you dearly whether by
state copy or keeping stacks of information updated.
Are you one of those who advocates ignoring the ko rule during MC
searches?
I'm actually pretty happy with 10,000 runs/second (9x9). I'm not so
happy with my tree data structure, so I'm going to go mess with that...
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
