Memory as Reference Signal (Was No Action Required?)

[From Richard Thurman (2004.12.22.1345)]

Bill Powers (2004.12.20.1640 MST)

Thanks, Bill for the references to the cruise control system. That
helps to sort out the reasoning for using memory as the reference
signal.

When I sent the previous post, I was about a week behind on email's.
Now that I have caught up (and I hope to stay caught up for the next
several weeks), I see that Bruce Gregory and I are both inquiring
about memory in the hierarchy. I'm not sure what Bruce G. is driving
toward, but I know what I want. I want to model (meaning simulate
via a computer program) a hierarchy of perceptual control systems
that use memory as the reference signal.

For some reason I've missed this crucial idea for years. It was not
until looking at the diagram on BCP page 221 a few days ago that
something struck like a bolt. (I guess I'm a late bloomer.) In the
past, I have always conceived of modeling the PCT hierarchy by just
feeding the lower control system's reference signal from the
output(s) of a control system sitting 'above'. Perhaps this was
because several standard HPCT diagrams show this simplified version.
However, it finally hit me how much more powerful the HPCT
explanation becomes if "all reference signals are retrieved
recordings of past perceptual signals" (BCP p.217), and if the
standard HPCT diagram includes control units that output an 'address
signal' to retrieve a stored (in memory) reference signal.

Hmmm... I'm not sure if that last sentence is understandable. All I
mean is that the diagram on page 221 explains so much just by adding
a 'memory' component to the hierarchy.

But how can this be implemented in simulation?

The cruise control explanation you gave helps me understand the
purpose -- but when I code up such a control system, I find that the
reference signal is already in 'memory'. That is, its already stored
as a variable named 'r'. I usually just use the variable 'r' in a
standard assignment statement such as:

e := r - p;

So 'r' is already in 'memory'.

Unless I missed your point with the cruise control system (and maybe
I did), I don't think we want to simply assign the output 'o' of a
higher control unit to 'r' of a lower control unit as in:

r1:=o2;

That way simply uses memory as a convenient way to designate that the
output form a higher control unit is now going to be used as a
reference signal in a lower control unit.

I'm pretty sure you had something else in mind than that. But what?
In BCP, (p.217) you state, "This requires giving the outputs from
higher-order systems the function of address signals, whereas
formerly they were reference signals. The address signals select
from lower-order memory those past values of perceptual signals that
are to be recreated in present time." I'm trying to figure out how
to do that in code. For example, I can interpret the above quote as
saying something like;

assign array 'Mem' the values [20,25,30,35,40,45,50,55,60,65]

do a control subroutine that outputs some value (say for example, OutPut:= 8; )

assign variable 'Ref' the value of array 'Mem' at position 'OutPut'
(in this case 'Ref' would have the value of 55 since its in the 8th
position)

use variable 'Ref' as the reference signal for the a lower order
control subroutine -- as in: Procedure CruiseControl(Ref)

So... using the above 'pseudocode' my cruise control system would get
the value '55' as the reference signal, even though the output of the
higher control system was '8'

Is this interpretation close to what you meant in BCP pp. 217-220?
If not, what did you have in mind? And if this is close, how else
could the idea of "address signal" based memory be implemented?

Best wishes,
Rich Thurman

ยทยทยท

>Bill Powers (2004.12.20.1640 MST)
>
>>Richard Thurman (2004.12.20.2100)--
>>

>>Any ideas about how an individual can use memory in the control process

would be greatly appreciated. (And any ideas on how to build such a

>>process in code would be incredibly appreciated.)

>

Start with the REASON for saying that reference signals come, or can come,

> from memory. The phenomenon I was trying to model was a very simple and

common one. We do something, we like the result, and we want to "do it
again." What is required in order to get the same result again?

The main requirement is that you have to remember what happened: that
memory is what you mean by "it" in the phrase "do it again." Then, of
course, you have to know when what IS happening matches the memory. In
short, you need a control system for controlling "it" and the memory has to
serve as a reference signal for the desired state of "it". This does not
mean repeating the action that created "it" the first time, though you may
try that. In general, generating the same act as before will not create the
same result as before. Remember disturbances -- that is why you need a
control system and not just an S-R association.

A car's cruise control works exactly this way. When you push the "set"
button, you're recording the value of a perceptual signal in memory. The
(electrical) perceptual signal represents the current speed of the car,
which is "it." To do "it" again -- make the car go at that speed -- you
have to record the speed in memory and use it as a reference signal against
which current perceptions of speed are compared. When, after stopping in
traffic, you are out on the open road again and press "resume," that
retrieves the last recorded memory of speed and plays it back as a
reference signal. And that, of course, causes the car's speed to come to
that value and stay there whether going uphill or down, in a headwind or a
tailwind -- with an accuracy depending on the gain of the control system.

> I think you can write the code for that.

> Best,

> Bill P.

[From Bill Powers (2004.12.22.1635 MST)]

Richard Thurman (2004.12.22.1345)--

However, it finally hit me how much more powerful the HPCT
explanation becomes if "all reference signals are retrieved
recordings of past perceptual signals" (BCP p.217), and if the
standard HPCT diagram includes control units that output an 'address
signal' to retrieve a stored (in memory) reference signal.

Hmmm... I'm not sure if that last sentence is understandable. All I
mean is that the diagram on page 221 explains so much just by adding
a 'memory' component to the hierarchy.

Yeah, but it's hard to work that into an actual model. I've put that off
for a long time. How does the higher system know or discover what addresses
to use? It's one of those ideas that sounds very attractive in the
abstract, but gets sticky when you look at the details. I threw the idea on
the table, but it may take someone smarter to figure out what to do with
it. One can but try -- be my guest.

But how can this be implemented in simulation?

My point exactly.

Unless I missed your point with the cruise control system (and maybe
I did), I don't think we want to simply assign the output 'o' of a
higher control unit to 'r' of a lower control unit as in:

r1:=o2;

That way simply uses memory as a convenient way to designate that the
output form a higher control unit is now going to be used as a
reference signal in a lower control unit.

I agree, that's not the way. Keep thinking of the analogy with the cruise
controller. The higher system (you, the driver) doesn't "address" the
cruise control's memory. You just push a button when what you experience at
the higher level is what you want at that level. Pushing the button stores
the perception at the lower level without even knowing what it is. Then you
can say "Do it again" by pushing that system's "resume" button, which calls
up the stored perception and uses it as a reference signal, still without
the higher system knowing what the lower perception is. (This is what I
meant by saying this model solves a "translation" problem. The higher
system knows nothing about what the lower system perceives). The higher
system never does need to experience the perception that the lower system
is controlling: it just says "do again whatever you were doing when I
pushed the Set button."

I always start with a simple-minded literal implementation of an analogy
and let things develop from there. When you code it and try it you'll find
out what the difficulties are and presumably see some solutions.

So... using the above 'pseudocode' my cruise control system would get
the value '55' as the reference signal, even though the output of the
higher control system was '8'

That's a good start. Try it out and see what happens. Don't spend too much
time at the drawing board -- imagined difficulties are always harder to
deal with than the ones you actually encounter.

Best,

Bill P.