Re: computer-go: Authenticating the identity of a remote go-playing computer program

[Steve Korfhage <korfhage@xxxxxxxxxxxxx>]

> You make it  sound as if avoiding
> deterministic  behavior is some kind
> of virtue and  allowing it   allows  you to
> write  more  sophisticated
> higher level AI programs.  This is nonsense and has nothing to do
> with
> AI.

I am not portraying any "virtues", Please don't label me.


> The only reason a computer  based
> algorithm might be non-deterministic
> is if you do not, or are not able to  document all it's
> inputs.  

An algorithm may be deterministic, but it is not necessary that its
results are.  If you don't believe this,  check into stochastic
methods.  The most common of these is "simulated
annealing", which attempts to model a natural random process. 
This class of methods, which definitely has something to do with AI, are
most commonly used for solving optimization and constraint based
problems, and they *intentionally* introduce non-deterministic
behavior.  They have been proven to be beneficial for many types of
problems. 

Stochastic methods and learning algorithms are the non-deterministic
behaviors which I am concerned about eliminating.  These approaches
can be successfully used in solving problems with exponential search
space, like Go.

> These inputs  might include flaky
> hardware or  even  software bugs where you
> access   uninitialzed   
> memory.     Some  parallel  
> algorithms   are
> non-deterministic,  but only because it's  not possible to
> predict the
> state of the  hardware at every given  instance of
> execution.  Even in
> this case, it's no virtue, it's an undesirable side affect.  
>
> I think we all agree that we don't wish  to require all programs to
> be
> properly deterministic in this respect, but having said that, I'll
> bet
> most are.  Since programs  are  deterministic by nature,
> you  actually
> have to program  them  explicity to  change this 
> behavior.   Or if  a
> program   is complex  enough  it  will
> have  enough   bugs to make  it
> nondeterministic,  which  might mean   it is
> accessing  un-initialized
> memory or some other goof like this.
>
> Don

Obviously, programming/design errors are excluded from the definition of
non-deterministic behavior for the purpose of this discussion. Like you
said, most programs will probably have errors, but this is not
intentional. I prefer to leave the implementation open to any method
desired, and instead prevent or detect inputs coming from outside the
algorithm. 



-----------------------------------------------------------------
Steve
s_korfhage@xxxxxxxxxxxxxxxxx
korfhage@xxxxxxxxxxxxxxxxx