RE: computer-go: unmake move?

[Peter.Smith@xxxxxxxxxxxxxxxx]

> From: Don Dailey [mailto:drd@xxxxxxxxxxxxxxxxx]
> 
> Peter,
> 
> Have you ever considered not unmaking moves at all?  
> 

Yes, depending on the data structures you're using that can be a good
approach.  For me undoing most moves doesn't involve very much work - some
of the data structures involved do use a copy on change technique.

> Now to address your  problem, unmaking is completely non-existant  and
> move  MAKING becomes greately  simplified  and faster.   Suddenly your
> code simplifies and you are not going out of  your way to maintain all
> the un-move state information.  And there can  be a significant amount
> of this.
> 

I don't have a lot of undo information but this is worth considering for
anyone starting with a clean sheet.

> Note that modern processors are extremely fast at copying data that is
> layed out consecutively in  memory, believe  me, you  can have  a very
> fast   program that uses  this  technique.    I have  found that  this
> arrangement cleans up the code a lot because it  can get sloppy having
> global   state all  over the   place.    It also  simplifies  parallel
> programming if you decide to go for that later.
> 

Global state?  I have one C++ class which represents a board and most of my
code treats the board as a black box.  Internally the board is complicated
but externally simple.

My efforts are directed towards improving the evaluation of board positions
and the moves to be played, rather than optimising making and unmaking
moves.  When I've got the program making sensible moves (which may be some
time) then I will try everything I can to optimise the speed of making.
Using copy on change is a valid technique.

Regards,

Peter.