Re: computer-go: unmake move?

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

   Don Dailey wrote:

   > Yes,  my evaluation  is very  simple, almost  all of it  is calculated
   > before the search begins.   I do have a  specific move ordering I  use
   > but it  doesn't involve a full   blown sort.  The  program does little
   > serious work (and it probably shows  because it doesn't play very well
   > either!)
   >
   > I  think this is   a  good argument  in favor  of  copying  state.  My
   > program, because  it does  very little, should   show state copying at
   > it's very worst  if it's  in fact a    bad idea.

   How so?  It seems to me that the very opposite is true -- because your program
   "does little serious work", there is little state to maintain.  A program with
   a more sophisticated evaluation function is likely to maintain much more
   state.  And it seems to me that the *more* state that is maintained, the
   bigger the performance penalty for copying rather than writing the code in
   such a fashion as to facilitate rapid undos.

Hi Ray,

Your point is an assertion that it is faster to maintain state than to
copy it.  I'm sure that depends on  the specifics of the implemenation
and of course the hardware.  

I made my statement  in the context of  talking about programs that do
less than 100 nps and that was what I was thinking about.  I am pretty
happy to do  300,000 nps so  if I add a lot  of knowledge, I can  only
assume that I will spend less time making moves as  a percentage of my
execution time.  That's  the sense in which   I felt my program  was a
kind of worst case  example  of being  "overwhelmed" with state  copy.
And my  point is  that  it seems  unlikely  this will  be any kind  of
limiting factor to my performance.


Don