\documentstyle[a4,epsf,alltt]{article}
\begin{document}


\include{commands}
\newcommand{\ital}[1]{{\it #1}}

\title{Production systems (2)}
\author{Jocelyn Ireson-Paine}
\maketitle


\section{Production systems and working memory}

In the previous handout on {\it Production systems}, I introduced the
general idea of a production system, and then demonstrated one
particular type of production system --- one functional architecture of
bug cognition --- applied to two bugs. In some ways, the demonstration
was a bit of a cheat. I introduced production systems as working mainly
on symbols in a short-term memory, but the two bugs didn't use STM at
all. They worked entirely on perceptual predicates and actions, and
their STMs remained empty throughout. In this handout, I'll remedy that,
with some bugs that think a bit before reacting.       


\subsection{Holidays}                   

In order to think, you need something to think about. In the context of
Eden, this means that you must be able to gather data before being able
to use it. This introduces issues of learning, navigation, and so
on, which I don't want to complicate matters with. I'm therefore going
to start with an example that has very little to do with Eden.

Please look at the rules below, in figure~\ref{ps2:holidays}.
\vfigstart
\begin{verbatim}
resolve [p,s,r].


stm [ mp,
      hot
    ].


stm_predicates all.


computer_hacker => rich.
management_consultant => rich.
mp => rich.

hairdresser => poor.
teacher => poor.
toilet_cleaner => poor.

poor => near.
rich => far.

near, hot => costa_del_sol, done.
near, cold => aberdeen, done.
far, hot => egypt, done.
far, cold => switzerland, done.

done => exec([forward]), exec([wait]).
\end{verbatim}
\vfigend{ps2:holidays}{Where to go for holiday}

In this program, we have the statement \verb/stm_predicates all/. Like
the \verb/resolve/ statement, this is something that programmers call a
{\it declaration} --- a statement that isn't itself obeyed as the
program runs, but that alters the way other symbols are interpreted or
other statements are executed. The declaration \verb/stm_predicates all/
tells Eden that all the names in rules refer to symbols in STM and not
to perceptual predicates or motor commands. Actually, there is one
exception to this: this is \verb/exec/ which is always taken as obeying
an action.

The initial contents of STM is given by the symbols after \verb/stm/:
that is, \verb/mp/ and \verb/hot/.

What do these symbols mean? The production system does not care, and
would work equally well if they were all meaningless names. However,
you can see that they have something to do with choosing holidays. The
idea is that you start the STM off by telling it what your job is, and
whether you like hot or cold weather. The job must be one of
\verb/computer_hacker/, \verb/hairdresser/,
\verb/management_consultant/, \verb/mp/, \verb/teacher/,
or \verb/toilet_cleaner/. The weather must be either \verb/hot/ or
\verb/cold/. The production system then runs a few rules, and eventually
comes up with the name of a country or resort, which it puts into STM.
It then obeys the bug-actions \verb/forward/ and \verb/wait/.

You can test the production system for yourself by doing
\begin{verbatim}
eps( holidays, psworld0 ).
\end{verbatim}
\verb/psworld0/ is set up so that the bug is standing just in front of a
quicksand. Once it has reached a conclusion, the rules make it obey the
\verb/forward/ and \verb/wait/ actions. These cause it to move onto the
quicksand and turn left: as described in the table of objects in {\it
How to run Eden}, this kills it! That's really just a nasty trick for
ending the life once a country has been chosen.

How do the rules work? I hope this is clear from my original discussion
of production systems. If not, you can follow it in Eden by looking at
the view window. This time, the diagnostics are quite long, so you will
almost certainly want to scroll through them with the editor, or to
print the window. How to do this was described in the {\it Editing the
view window} section in my editor handout. Briefly, you type the Eden
control command \verb/v/, and then give the editing command ENTER
\verb/ctcprint/ RETURN. This will print the window on the printer on the
first floor of CTC. To help with following the rules, the figure below,
figure~\ref{ps2:holidays_stm}, shows successive snapshots of the bug's
STM. Next to each fact is an annotation showing when it was added. The
number before the point identifies the production-system cycle; the
number after it shows when during that cycle.
\vfigstart
\begin{verbatim}
hot (0.2)
mp (0.1)

rich (1.1)
hot (0.2)
mp (0.1)

far (2.1)
rich (1.1)
hot (0.2)
mp (0.1)

done (3.2)
egypt (3.1)
far (2.1)
rich (1.1)
hot (0.2)
mp (0.1)
\end{verbatim}
\vfigend{ps2:holidays_stm}{The holiday-bug's STM}

If you want to experiment with changing these rules, or the initial
contents of STM, you may, provided you know how to edit and run your own
programs. For instructions on how to do this, see my handout on
{\it Editing your own programs}.


\subsection{Another example}

I will add another example sometime. In the meantime, why not try
writing your own. Some kind of diagnostic system is best, that starts
off with symbols denoting ``symptoms'' (in the broadest sense, e.g. they
could be the names of geological features, or of pop groups, from which
you infer the type of rocks present underground, or the type of rock
music someone likes). If you imitate the example above you should have
no problem. The handout on {\it Editing your own programs} gives, at its
end, some info on program structure.


\section{Production systems, predicates, and logic}

In the examples above, all the rules' primitive conditions were simple
``words'' like \verb/hot/ and \verb/mp/. It is possible to have more
complex conditions, which is where a connection with logic comes in. For
an example, have a look at the first two rules below. Ignore the third
one for the moment: it's another trick for killing the bug once enough
inferences have been made.
\begin{verbatim}
likes(mary,wine) => loves(john,mary).
likes(mary,beer) => loves(bill,mary).
loves(_,_) => exec([forward]), exec([right]).
\end{verbatim}

You will find a copy of these in the file \verb/l1.pl/, with the STM
initialised to \verb/likes(mary,wine)/. Try running them with
\verb/psworld0/:
\begin{verbatim}
eps( l1, psworld0 ).
\end{verbatim}
You will see that the final contents of STM is as shown below.
\begin{verbatim}
loves(john, mary) (1.1)
likes(mary, wine) (0.1)
\end{verbatim}
That is, the symbols \verb/loves(john,mary)/ have been added. This was done
by firing the first rule. So groups of symbols can have a more
complicated structure than in the holidays example.


\subsection{Predicates and arguments}

In fact, this structure will be familiar if you have studied logic. A
group starts with a name followed by an open bracket. This is called the
{\it predicate}. After the bracket come a sequence of names or numbers
separated by commas. These are called the {\it arguments} of the
predicate. Finally, there comes a closing bracket. Note that the word
``argument'' is used in a technical sense peculiar to mathematics; this
sense has nothing to do with its everyday meaning.

Predicates can have any number of arguments, so groups like these are
all valid:
\begin{verbatim}
job(mp)
loves(john,mary)
pub(prince_of_wales,walton_street,oxford,morrells) 
\end{verbatim}

If a predicate has no arguments, then you just write its name:
\begin{verbatim}
mp
hot
\end{verbatim}
Prolog will not allow you to have the name followed by an empty pair of
brackets, though some other languages do.


\subsection{What do they mean?}

I have repeatedly emphasised that, as far as the production system is
concerned, the groups of symbols are completely arbitrary. Only their
form matters to the program that runs the matching, resolution, and
firing processes, not their content. However, when we write programs, we
usually do intend each name to have some content --- to refer to
something. Here are some examples of two-argument predicates, where the
meaning should be clear.
\begin{verbatim}
event( 1756, mozarts_birth )
loves( joe, mary )
teaches_at( joseph, st_annes )
colour( grass, green )
legs( sheep, 4 )
costs_pence( mars_bar, 21 )
is_a( sheep, mammal )
\end{verbatim}

For such predicates, the predicate usually names a relation that
holds between its arguments. This is easiest to see with spatial
predicates, such as
\begin{verbatim}
on( block_a, block_b )
\end{verbatim}
You can also use predicates to say that an object has a certain
property, to say that an object belongs to a certain class, or to give
the result of operating on the object in a certain way. The last use is
like that of a function in maths, where one argument is the input and
the other is the result.

Predicates of fewer or more than two arguments can also be interpreted
as relations, though this is less obvious to non-logicians.

In most programs, the names appearing as arguments are used in one
of three ways:
\begin{center}
\begin{tabular}{llll}
To name individuals &   \verb/john/   &  \verb/egypt/ \\
To name properties  &   \verb/rich/   &  \verb/hot/   \\
To name classes     &   \verb/teacher/&  \verb/wine/
\end{tabular}
\end{center}

A predicate and its arguments form a {\it proposition}: a logical
statement. This may be either true or false, depending on the meaning of
all the names and the state of the real world. Here are some
propositions and possible meanings:
\begin{center}
\begin{tabular}{ll}
\verb/mp/                  & I am an MP. \\
\verb/egypt/               & I should go to Egypt on holiday. \\
\verb/rich /               & I am rich. \\
\verb/loves( john, mary )/ & John loves Mary.
\end{tabular}
\end{center}

When writing a program, you should always keep the intended meanings of
your predicates and arguments in mind. It is not always clear from the
names alone. For example, does \verb/gold/ refer to gold as a chemical
entity in general, or to gold in finance at a particular time, or to a
particular chunk of gold? Compare its meaning in the sentences ``Gold
does not dissolve in water'', ``Gold rose by \pounds 2.45 today'', and
``The gold in this ring was mined in 1847''.

As another example, of a different kind, does \verb/on(block_a,block_b)/
mean that A is standing on B, or that B is standing on A? Be careful
about the order of your arguments.


\subsection{Rules, inference, implication, and logic programming}

When we think of groups of symbols as propositions, we can see that a
production rule is a device which, given the fact that its left-hand
propositions are true, makes explicit the fact that the right-hand
propositions are true. We can therefore view production rules as {\it
rules of logical inference}: rules which, given one set of true
propositions, {\it infer} another set of true propositions. The rule in
\verb/l1.pl/ infers the proposition \verb/loves(john,mary)/ from the
proposition \verb/likes(mary,wine)/. That is, if you tell the rule that
\verb/likes(mary,wine)/, it will infer that \verb/loves(john,mary)/.

This is what {\it logic programming} is all about. In languages such as
Pascal and Basic, you program by telling the computer how to accomplish
some task. Your program consists of a sequence of little instructions,
which if obeyed in the right order will (hopefully) do the right thing.

But in logic programming, you describe your program in logic. Your
program consists of an initial set of propositions, plus a set of rules
which infer new propositions from old. In our production system, the
initial set of propositions is the initial STM, and the rules are the
production rules.

Logic programming became famous at the start of the 80's, with the
growth of interest in expert systems, Prolog, and the Japanese Fifth
Generation Project. For background reading on this, see {\it The Guide
to Expert Systems}, by Alex Goodall (Learned Information, 1985;
somewhere in PSY). Look at the chapters on logic programming (number 6,
I think), and on the history of AI. The most famous logic programming
language is Prolog, and in fact the Eden production system is built on
Prolog. They therefore share a number of similarities, particularly in
the syntax of predicates and in the way conditions are handled.

One of the important things about logic programming is that you can view
the rules, as well as the propositions, as logical statements. The rule
\begin{verbatim}
likes(mary,wine) => loves(john,mary).
\end{verbatim}
can be read as an implication: ``If Mary likes wine then John loves
Mary'' or ``Mary likes wine implies John loves Mary''.  Similarly, the
rule
\begin{verbatim}
far, hot => egypt, done.
\end{verbatim}
can be read as the implication ``If you can go somewhere far, and you
like it hot, then Egypt would suit you''.

You should note that not all production systems can be used for logic
programming. The Eden one can because it has facilities for grouping
symbols into predicates and arguments, and because the matching and
rule-firing were designed (with help from Prolog) to model logical
inference. However, matching and rule-firing don't have to work this
way.

Note also that, even in this production system, it's hard to interpret
some rules logically. This is particularly true of rules which create
symbols denoting a stage in the computation, or which obey actions.
You see both in the rule
\begin{verbatim}
loves(_,_) => exec([forward]), exec([right]).
\end{verbatim}
I used this to trigger an action once a \verb/loves/ fact had been
derived.


[The rest of this handout remains to be written. Ask me what to do
next. You could have a look at the bug \verb/skier.pl/, try running
it in \verb/psworld0/, and try making sense of it with the notes
at the end of the {\it Editing your own programs} handout.]


\end{document}
