X-Envelope-to: CSG-L@vmd.cso.uiuc.edu
X-VMS-To: @CSG
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.csg-l
Date:         Mon, 16 Nov 1992 15:30:08 -0700
From:         "William T. Powers" <POWERS_W%FLC@VAXF.COLORADO.EDU>
Subject:      Modeling and linguistics

[From Bill Powers (921116.1400)]

Avery Andrews (161128.1028) --

>Why not just require that the actual perceptions fit the text
>directly?

You can't compare text with a visual image. Text is perceived as a
string of letters or phonemes. A tree on top of a hill looks like a tree
on top of a hill, not like a string of letters or phonemes.

To make the comparison, you must either continuously translate what
you're looking at into text and compare it with the original text, or
translate the text into an image of a suitable kind and continually
compare the image with what you're looking at. You have to have a
reference signal of the same kind as the perceptual signal it's to be
compared with -- that is, it has to be the right sort of perception.

The least ambiguous way to do this, it seems to me, is to translate the
text into an image, which you can then compare with the actual perceived
images. When I hear "large tree at the top of a hill next to the path" I
construct something like an imagined top of a hill with an imagined big
tree next to the path. As I travel along I keep comparing what I see
against the reference image. I'm on the top of a hill, so that error is
close enough to zero. But the biggest tree I'm looking at is sort of
middle-sized, and it's farther from the path than my image says it
should be -- this probably isn't the top of the right hill. Keep going.

After you've given me a long set of directions, I doubt that I could
repeat the text back verbatim. But I could paraphrase, because as you
gave me the directions I was building up a mental image. If you asked me
to repeat back the directions, I would simply imagine the mental images
in the order I built them, and describe them. I might use some of the
same words, but I wouldn't have to. I might say "Got it -- big tree, on
the right, hanging over the path, up at the top of a hill," whereas what
you actually said was "Look for place on the path at the top of a hill
where there's a large tree nearby." You might want to tell me the tree's
on the left, and that it doesn't overhang the path, and thus tweak my
mental image. But what I will carry along in my head isn't the exact
words, but the images they led to.

If an ambiguity comes up, I might replay the words. Wait a minute, this
is the top of a hill and there's a big tree next to the path, but it's
on this side instead of that side. What did he say? "A large tree
nearby." Oh, he didn't say which side. So if I revise my mental image,
it will match what I'm seeing. I'm there.

RE: the engineering approach.

I would prefer to call it the modeling approach, but the modeling I do
is like what engineers do so maybe it's the same thing.

The main thing about a model is that it describes underlying mechanisms,
not surface appearances. The model is something such that when it
operates according to the way you defined it, its behavior creates thephenomenon
 you're trying to model. This is why, in a control-system
model, you won't find any "controller." Control is a phenomenon that
arises when you hook up an input function, a comparator, an output
function, and an environment in a particular way.

What modeling is NOT is simply describing how things seem to work.
Harris's operator grammer is not a model. It's a description of a
phenomenon, in which some words (operators) appear always to be used
with other words (arguments). That is what we have to explain with a
model, but it's not a model in itself. It's a proposed description of a
phenomenon. A model would provide the underlying mechanisms that lead to
this result. And in that model we would not have "operators" or
"arguments". Instead, we would have elements which, when they interact
in the ways we propose, would create words that function as operators
and others that function as arguments, and such that the way they are
used fits the observations.

In a way, modeling as I see it is much like the kind of programming you
probably do in implementing the grammatical or syntactic rules that you
propose. When you're programming, you have in mind a certain phenomenon
that you're trying to reproduce, and your problem is how to get a
computer to do that. To get the computer to parse a sentence, you can't
just write the instruction "parse." You have to think of a series of
operations which, when carried out, will produce something that you
recognize as "parsing." None of those operations is parsing; parsing is
an emergent phenomenon relative to the program steps. Nowhere in those
steps will there be any operation called "parsing."

The difference in my kind of modeling is that I'm building a machine
that is supposed to do what is required, not using one that's already
defined. My machine is made of input functions, comparators, memory, and
output functions, and its parts aren't all fully defined yet. When I try
to construct an explanation of a phenomenon, however, I use the machine
that I've been building, patching it up as necessary to get it to run.
Those patches are to be treated with suspicion because they're ad-hoc,
and one has to keep in mind that they require further work before they
really become part of the machine. That's why I mention "unofficial"
parts of the model now and then. But basically the process is done
within the constraints of the conceptual machine components that are
available.

The modeling process is then that of hooking up components of the kind
that have already been defined to see if they can be made to behave in a
way that matches the phenomenon to be explained. Their behavior isn't a
matter of choice; that's a fixed property of the model. The only choices
are in how we connect those parts. Once we commit to a connection scheme
and define properties like perception and action to fit a particular
case, the model will behave as it behaves. It the result doesn't match
the phenomenon, we have to try again. We may have to find a better
hookup; we may have to add new components and modify old ones.

When you use a computer to implement a rule or process, you're using a
machine whose parts are already defined: adders, subtractors, index
registers, logical comparisons, storage, retrieval, and so forth: the
basic instruction set. You probably use a higher-level language, so
 each"elementary" operation is really a collection of machine-language
instructions. But at whatever level you're programming, this model is
still a digital computer. Your basic proposal is that the phenomenon is
created by the operation of a digital computer. Or, at a higher level,
you're saying that the underlying mechanisms consists of the basic
operations you can perform in C, or Basic, or Pascal, or Common Lisp, or
Prolog.

The conventional models of behavior that I have seen have been heavily
influenced by the fact that the basic model is a digital computer or a
language with fixed properties running on a digital computer. The
influence of Lisp on AI is enormous; you could say that AI has been
exploring the properties of an organism whose components are the basic
operations of Lisp. Most conventional models have assumed that once a
command is given, it will be carried out exactly -- because that is how
computers work. The operations of these models have been conceived as
tasks that are carried out stepwise, in sequence -- because that is how
computer programs are written. It's assumed that one task can't begin
before the previous one has ended, and that output always occurs after
input. At best, you get time-sharing or subroutines. And that is because
the underlying model is a digital computer or a programming language.

PCT is based on a different kind of machine having different components.
It doesn't yet have all the components it needs, but that's just a
matter of time. Each component, once defined, can be simulated on a
computer, but the functions of the components are not dictated by what
computers or programming languages can do. And there is no suggestion
that the computer operations involved in such simulations are the same
as the means by which the organism carries out the same operations.

To make a model of language, the first thing that has to be done is to
get away from analyzing specific words, and to look for machinery that
can handle words in general. There are certain basic operations on words
that consitute the machine that produces language phenomena. These
operations have to be independent of what the words are or what they
mean, because they have to work with all words. There are certain basic
phenomena that need modeling; these are the phenomena with which most
linguistic models I have seen start, and which they seem to treat as
explanatory. Given (father-of John Penni), what kind of underlying
machinery can convert a perceived relationship into that or any related
way of denoting the relationship in words? The underlying operations are
clearly taking place in the linguist. But we need to get them into the
model, if we're to have a true model. The "knowledge base" is the tip of
the iceberg. What we need to know is what kind of machine can construct
a knowledge base out of experiences?

Text appears to constrain experience. But that is just a surface
appearance. To explain these appearances, we have to look at a deeper
level, to operations that are of a more fundamental nature than word-
manipulations. PCT is an attempt to construct that kind of model.
-------------------------------------------------------------------
Best,


Bill P.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU