Introduction to Artificial Intelligence Programming

by A.T. Murray based on the AI4U Concept-Fiber Theory of Mind

1. THINK DIFFERENT: VIABLE IS VALUABLE

A programmer's manual for artificial intelligence differs from
a book about, say, a global operating system that must be kept as
uniform and standard as possible for the sake of running as wide
a variety of applications as possible on the would-be standard OS.
Although there are standards in AI, just as there are standards
in health and safety practices and standards in civil engineering,
there are no predictable standards in what kind of AI Mind ought
to be selected by artifice or nature to evolve and fill the void.
The test of good AI programming is viability out on the wild Web,
not proximity to specifications issued by a Bureau of Conformity.

2. CHANGE AT THE TOP IS SLOW AND CURIOUS

The architectural hierarchy of pre-maspar AI Mind Modules is slow
to change at the top where the oldest and most stable mechanisms
of Mind have been operating for the longest time. The principle
of the unprincipled applies here: If it ain't broke, don't fix it.

Conservatives clamor for keeping the status quo until along comes
a challenger too mighty to suppress and oppress. In AI technology,
the curious and adventurous will one day overthrow the cautious
and obstructionist. The seeds of a new Seed AI are awaiting water
and daylight in the fields of massively parallel processing (MPP).
When maspar AI becomes possible, the current paradigm will fall.
Meanwhile, things fall apart at the bottom of the AI architecture
where the rodents of evolution challenge the lumbering dinosaurs.

3. CHANGE AT THE BOTTOM IS FAST AND FURIOUS

The lower Mind modules are often broken and therefore need fixing.
Some of them are inherently so experimental and so bodaciously
Band-Aid (tm) in nature that they cannot long survive in Nature.
This Mind manual covers a particular release of the AI software
and must be rewritten almost as often as each AI is rewritten,
but change at the bottom is too fast and furious for publishers.
Therefore we call upon the dregs of Usenet and the cacophony of
forums to fill the info void with the dross and gloss of the good,
the bad and the ugly in terms of useful AI troubleshooting help.

4. STRUCTURED PROGRAMMING

Whereas functions and subroutines in many programming languages
may be ordered in any arbitrary sequence as decided by the coder,
the Forth language of Mind.Forth requires that any higher function
may call only previously declared lower functions. Thus the
sequence of functions called in Mind.Forth prevents chaos in code
by suggesting a sequential order by default for modules of the
AI Mind implemented in a wide range of programming languages.

The rationale here is, if the sequential order of the modules
does not matter for a particular programming language -- say,
JavaScript -- then why not adopt the sequence from the Forth
language where the order does indeed matter? In that way,
a person studying the software expression of the Mind algorithm
across a range of programming languages will be able to look for
any given module in roughly the same place in all implementations.

Within Mind.Forth and its associated flow-chart diagrams,
there is a primitive order imposed by the series of calls
to functions from the main aLife program loop and dictated
by considerations of functionality in a not-yet-parallel Mind.
That is to say, the main aLife loop calls the modules in
a sensible, utilitarian sequence. First Tabularasa and
enBoot are called one time only, and then dropped
from the loop after the AI Mind is up and running.
The other modules are called in a sensible order that
permits the functions of mind to build one upon another.
For example, Sensorium is called before Think,
so that the AI Mind may first receive sensory input and
then think about its sensory input from the outside world.
The stub of the Emotion module is placed after
Sensorium but before Think so that the AI Mind
may experience an emotional reaction to its sensory input
and then think thoughts that include an emotional component.
The stub of Volition (free will) comes after Think
because thinking informs and creates the free will.
The stub of Motorium comes after Volition
because a robot must think and form its will in order
to issue motor commands to all its robotic muscles.
In summing up, the basic sequential order of the modules
in the AI Mind follows a sensible plan carefully crafted
in Mind.Forth AI and suggested for adoption in other Minds.

A further and also careful consideration adopted in Mind.Forth
was to place all "housekeeping," diagnostic and troubleshooting
modules as early as possible in the program listing, even if
the module would not be invoked until far down in the AI code.
The rationale here is at least twofold. Firstly, a software "tool"
should not appear only in proximity to its calling module, but
should make an early appearance as a quasi-announcement of its
availability on an as-needed basis for calling by any AI module.
Secondly, the higher-level AI modules should remain in the groups
decreed by the organizing principles evident in the main aLife loop,
with no distractions or interruptions on the part of low-level tools
which deserve only a low-level priority in the program listing order.

5. A COMMENT ABOUT COMMENTS

Comments are inert, inactive messages inserted into
the AI Mind source code either for the benefit of the
current programmer trying to test or troubleshoot the code,
or for the benefit of other persons, such as students trying
to understand the program or new programmers maintaining the code.

There are both experimental and maintenance comments.
Experimental or troubleshooting comments briefly serve only
a temporary purpose, while maintenance comments are a part
of the permanent record of how the program does what it does.

If you adopt a voluntary guideline of using an odd version number
(such as Mind-1.1) for rapidly changing, developmental releases and
an even version number (such as Mind-1.2) for stable releases,
you may try to let experimental or troubleshooting comments
appear only briefly and in the odd-numbered developmental releases.

Such brief, transitory appearance of nitty-gritty comments
about highly creative and experimental coding serves to
preserve the record not only of how a more stable version
came about, but also of how to do the more creative work --
what things to try; what diagnostic messages to display; etc.

There are often several good reasons to turn source code itself
into lines of code that have been "commented out." One reason
for commenting out some code might be to keep the code available
while an alternative is tried or tested. In the case of
diagnostic code, it may be helpful to turn diagnostic messages
on or off simply by commenting out the diagnostic code at will.
Since the diagnostic code has a certain residual value even
when commented out, one way to preserve the information for
future use is to comment out the code but leave it visible
within a print-out of a developmental release numbered X.1 or
X.3 or whatever number comes up naturally within the guidelines.
When the valuable but rejected code has appeared in at least
one print-out as part of the history of your software project,
you may delete the commented-out code from stable releases.

6. VARIABLES

Please be aware that the AI Mind variables have been listed
alphabetically by name in a Table of Variables that explains
the function of each variable and what module it is used in.

7. AI MIND-MODULES

Flowchart (essential for programming the AI in a new language)