[From Rick Marken (2009.04.09.0930)]
Bruce Abbott (2009.04.08.1750 EDT)--
HPCT (Hierarchical Perceptual Control Theory) proposes a hierarchical set of
control systems in which higher-level systems control their perceptual
inputs by setting reference levels for systems immediately beneath them in
the control hierarchy. One of those proposed higher levels is the "program
control" level, which executes programs much as a computer does.
On the output side, yes. But on the input side what the theory says (I
think) is that the program level _perceives_ a program. I think of the
program level as perceptual functions that (somehow) produce
perceptual signal whose magnitude varies in proportion to the degree
to which a particular program is occurring.
Bill notes that "programs can be hierarchical in nature, in a way that has
nothing to do with the hierarchy of perception and control we have developed
so far." (p. 260). In a previous post I gave the example of a rat in an
operant chamber pressing a lever for food pellets...Here we have a series of control systems that come into play in sequence
And it could be seen as a program as well: if <no food> then press
else no press. The question would be whether the sequence and/or the
program of activities that _we_ see is actually under control by the
organism itself. Probably not, in the case of the rat with the lever,
but that would have to be tested.
Bill recognized in B:CP that this "program control" level introduces a
conceptual difficulty for HPCT (see B:CP, p. 163, last paragraph). For other
levels it seems reasonable to imagine a reference specification that matches
the character of the perception to be controlled. Thus, for example, one can
imagine a sequence of perceptions that can be compared to an existing
reference sequence. Is the same true for programs?
I don't see that this is a particular problem. All perceptual signals
(according to PCT) are neural signals. So the perceptual signal that
represents the state of a sequence is the same as the perceptual
signal that represents the state of a program; it's just a neural
signal firing at a particular rate. The reference for a sequence and a
program is also just a signal of a particular frequency. The
conceptual difficulty, it seems to me, is figuring out how to design a
perceptual function that maps the occurrence of a program (or
sequence, but a program seems harder) into a perceptual signal where
the magnitude of the signal represents the degree to which the program
is occurring. Maybe at the program level the perceptual signal is
essentially binary; low means that the program is not occurring and
high means that it is.
I have done experiments (like the one in my Hierarchical Control demo:
http://www.mindreadings.com/ControlDemo/HP.html) where the subject can
control a program (just like the subject can control a sequence in the
existing demo). For example, the subject sees an integer between 1 -
10 on the left and then an integer between 1-10 on the right. The
program to be controlled is: if left is odd then right is >5 else
right <5; if right is odd then left is <5 else left >5. The numbers on
the left and right come on alternately. As long as the program is
occurring the subject does nothing; but when the program changes the
subject must press the mouse button to restore it (keep the program
under control). People can do this but obviously the rate of
presentation of the program must be quite slow -- slower then the
presentation rate that allows control of sequence -- suggesting that,
indeed, program perceptions are higher level perceptions than
sequences.
In most cases it seems that we develop the program "on the fly," according to
whether it seems to be succeeding or not to bring about the desired
end-state.
I agree. But in this case I don't think we're controlling a program;
we're just reorganizing and it looks like "changing the program". I
think when we control a program we are controlling a very well learned
program; there is no modification of the program itself going on; the
program has been compiled, so to speak. Examples are hard to think of
because a lot of what we see as "dealing with contingencies" could be
ordinary disturbance resistance or reorganization. Any example I give
is just a guess; I don't know if it _really_ involves program control.
But I suspect that one example of program control (from my own
experience) might be following a _very_ familiar recipe. In this case
I think I am doing more than carrying out a sequence of operations; I
am controlling a program where I know what to do in case of
contingencies.
Another aspect that needs to be considered is what roles perceptions may
play, in addition to being things controlled. As Bill noted in B:CP,
"perceptions are a part of the if-then tests that create the network of
contingencies which is the heart of the program." (p. 164)
I think what's hard to get one's head around is the idea that a
program is itself a perception. But if it weren't, how would we know
what people are talking about when they say "Get with the program"?
Obviously, in order to say this a person has to be perceiving the
current program you are carrying out, comparing it to their reference
for the program they think you should be carrying out and making the
exclamation when there is a discrepancy between the perceived and
reference program.
That's my thoughts on it, anyway.
Best regards
Rick
ยทยทยท
--
Richard S. Marken PhD
rsmarken@gmail.com