Consciousness, Inner Experiences, Artificial Intelligence and Computer Go

Copyright 2000-2004 by Mark Watson. Version 0.2 January 2004

Abstract
David Chalmers, in his book The Conscious Mind , describes the hard problem of consciousness as: Why is all of this [processing and integration of environmental information] processing accompanied by an experienced inner life? We all experience consciousness, so we know that it exists. There are no AI systems that implement this elusive strange loop feedback mechanism of self-thought and experience of qualia (i.e., inner experienced life), although there are several research and commercial systems that currently attempt to do this. In trying to develop an AI capability, it seems crucial to use a simple enough environment so that the AI can at least do the following: 1. Perceive its environment 2. Affect changes in its environment 3. Build predictive models of its environment

4. Daydream about its environment in a creative way and incorporate these day dreams into its internal state in the same way (loosely) that it incorporates external experiences No matter what its domain of "life", I would argue that an AI system that can perform these four operations is a "real AI". If I were to engage in a dialog with an AI Go player, and it showed me game patterns that it "dreamed up" during moments of reflection, then I would consider this to be "real AI". Douglas Hofstadter in Fluid Concepts and Creative Analogies makes great arguments for why creativity is crucial for AI. When we close our eyes, we can still see visual images because internal mental models can stimulate the visual cortex in a similar way that our "up front" vision system does. Using a simulated neural network metaphor: our eyes are the input layer, the visual cortex is the first hidden layer, and the remainder of our brain comprises additional hidden layers. Patterns on the visual cortex can be stimulated by either real vision processes or by daydreaming about things that we have seen before. I propose that computer Go is a very good vehicle for developing a "real AI" capability. An AI Go player need not necessarily play a good game of Go to be a success as long as it exhibits the four capabilities listed above.

Requirements for an AI Go player

From an external perspective, the AI Go player exhibits a playing board (its environment ) and visual indicators for: 1. Currently daydreaming (with dreams appearing on the

visible Go board) 2. Currently playing a game - AI's move 3. Currently playing a game - waiting for a move 4. Currently watching a game that a human is entering moves for both sides The only external stimulus to the AI Go player is: 1. Button for requesting the start of a new game (the AI may ignore this) 2. Button for requesting the start of a new training game where human plays both sides (the AI may ignore this) 3. Button for "human leaving", so day dream or whatever... 4. Clicking on the displayed Go board - registers a move if a game is being played or is otherwise interpreted as commenting on a dream game, or moves of a training game where a human plays both sides I argue that this is an expressive enough interface to the "real world" for a real AI to express its uniqueness. Of course, the difficult problem, which may be impossible with conventional computers, is developing code for the internal behavior.

Design of an AI Go Player
The following list shows the process architecture: 1. GO/AI program machine learning, web interface for web based users, socket interface to an running instance of the GNU Go program. 2. GNU Go program used for training games when human opponents and tutors are not available 3. Remote users using the web interface for tutoring

The GO/AI process will be implemented a good rapid prototyping language; I am considering Squeak Smalltalk, Common Lisp, and Java as implementation languages. The following list shows my first thoughts on required classes: 1. Game class encapulates a complete game history, opponent information, etc. 2. Stone shape template class used for machine learning: encapsulates stone patterns, and good/bad squares (hopefully will be used to learn good shape vs. bad shape). 3. DreamGame class used for day dreaming; that is, when the computer is experimenting with playing both sides in a game (occasionally using the GNU Go external program to determine good available moves when it needs help and a human tutor is not available. 4. UserWebSession class used to manage the session when a user logs on to tutor the program. 5. GnuGoWrapper class encapsulates socket connection for using an external GUN GO program