# Unsent Message Returned to Sender

Notice to Sender

···

================

This message was received by this installation but could not be
delivered to its intended cc:Mail recipient(s).

Original subject: Re: MCT = PCT ?

Intended recipient(s) who DID NOT receive this message:

robinson_dan@dsmc1

The following cc:Mail error(s) were recorded:

*** Unknown message recipient ***

-------- Original Message Text --------
[Hans Blom, 970221d]

(Bill Powers (970220.1445 MST))

A misunderstanding which deserves correction:

The comparator in my diagram computes an error signal, e[k+1], which
is

e[k+1] = r(k+1) - x(k), so that

u(k+1) = e(k+1)/(A*dt)

(I think your equation should have referred to u(k+1)).

No, Bill, my equations were correct. Let me explain where your
confusion comes from.

It is important to distinguish between what is observed at time k and
what at time k+1 (or k+dt). Your static diagram does not capture
that. It is also standard procedure to call the reference for x(k) by
the name of r(k), and to call the reference for x(k+1) by the name of
r(k+1). Seeing you write down the difference r(k+1) - x(k) hurts my
eyes ;-). Also, at time instant k you cannot compute e(k+1), which
would be the difference of r(k+1) and x(k+1); the latter is not known
yet!

So let's get the indexes right. At time instant k, you perceive x(k)
and have to compute u(k). It is only at time instant k+1 (or k+dt, if
you prefer) that you can discover the result x(k+1) and the control
error e(k+1) = r(k+1) - x(k+1).

The problem with diagrams is that they do not capture the incremental
nature of time of a model expressed as a difference equation. They
are nice for differential equation-type models such as implemented in
electronics or in an analog computer, but become confusing (or rather
insufficiently informative) for discrete-time models.

Actually, MCT models are even more fine-grained. They distinguish
between the two different "times" t where (1) x(t) has been observed
but u(t) not computed yet; and (2) where x(t) has been computed and
u(t) computed and output.

For comparison, the PCT model would be formally identical, except
that we would use the integral equation

x[t+dt] = x(t) + A*u(t)*dt

Where is the integral? This is a _difference equation_ as well, and
it is indeed exactly the formula I used, be it with a substitution of
variables.

... in computing u we would use a gain factor G instead of 1/(A*dt):

u(t+dt) = [r(t+dt) - x(t)]*G

The correct expression (remember that we are at time t!) would be:

u(t) := [r(?) - x(t)]*G

which says that the output u that we compute at time t depends on the
difference between our _current_ perception and some reference level.
This constitutes the basic difference with the MCT control law.

In MCT, your formula would be nonsense: x(t) has been observed
already and cannot be influenced anymore; we need to compute a u(t)
such that a _future_ x, namely x(k+1), will have some specified
value. Thence the MCT expression would be

u(t) := [r(t+dt) - x(t+dt)]*G

with a suitably chosen (model-derived) G.

Let's switch to using the cruise control as the example.

No, let's not change horses in mid-stream. Exactly the same
differences would show up again.

Greetings,

Hans

Notice to Sender

···

================

This message was received by this installation but could not be
delivered to its intended cc:Mail recipient(s).

Original subject: Re: Oh, no! Feedback too slow!

Intended recipient(s) who DID NOT receive this message:

robinson_dan@dsmc1

The following cc:Mail error(s) were recorded:

*** Unknown message recipient ***

-------- Original Message Text --------
[Martin Taylor 970221 12:00]

Rick Marken (970220.1240)]

Martin Taylor (970220 13:20) --

> I'm assume Hans is enough of an engineer to recognize the speed
> advantages negative feedback systems can have over straight-through
> systems, and isn't referring to that.

Huh?

It sounded to me like Hans' statement implies something like the
following:

When you command a fast movement, the feedback from the
movement is too slow to influence each phase of the movement;
so feedback from the commanded movement is not available to
modulate the details of the command while the movement
occurs. Since there is no feedback available to modulate
commands, these rapid movements are a good example of a
behavior where model-based command generation would be

This is the argument made by people who talk about feedback being "too
slow". The essential problem with this argument (as you know) is that
it is based on the idea that events in a control loop occur
sequentially, one after the other.

Yes, and I'm almost certain Hans is not at all thinking like that. That's
why I suggested you recognize that he is an engineer who has dealt with
real-life control systems in which everything acts simultaneously.

> On that basis I have to ask whether you have forgotten your own
> signal in tracking a sinusoidally varying disturbance. That sinusoidal
> reference presumably came from a model of the disturbance, though you
> introduced it in a rather ad-hoc way.

Indeed, I don't recall any demonstration of this sort. Could you give
me some more details? And what does it have to do with feedback being
"too slow"?

You presented some data about tracking a sinusoidal disturbance, and pointed
out that the fit (or was it the control--I forget, but it doesn't matter for
this particular situation) was better if the reference varied sinusoidally
with a phase advance when compared with the disturbance sinusoid. You
challenged people to estimate how much the phase advance should be, and
expressed surprise when my estimate came out to be of the right order of
magnitude (in fact, was almost right before I "fixed" a computational
mistake:-(.

What it has to do with feedback being too slow is that you used what
amounted to a predictive model of the disturbance to improve fit (or
control, perhaps both). It's a good demonstration of the value of an
internal model even in the lowest-level type of tracking control that
is taken to exemplify all control in most of these discussions.

And it is a very close analogue to the much higher-level situation I
used as an example--putting up plywood protection for your windows in
anticipation of a forecast hurricane.

Martin

Notice to Sender

···

================

This message was received by this installation but could not be
delivered to its intended cc:Mail recipient(s).

Original subject: Re: Purposeful evolution, slow feedback

Intended recipient(s) who DID NOT receive this message:

robinson_dan@dsmc1

The following cc:Mail error(s) were recorded:

*** Unknown message recipient ***

-------- Original Message Text --------
[From Rick Marken (970220.1030)]

Bruce Gregory (970220.0940 EST)

The problem may be the term "selection". Sexual selection is
true selection, and hence purposeful, but natural selection is
not. (The sexual selector resists disturbances, the natural
selector does not.)

Bingo!

Yes. I have suggested that the process called "natural selection" be
called "natural filtering" instead (I have not seen "natural filtering"
used much in the recent literature on evolution so I take it that no one
has taken my advice;-)). There is no _selection_ going on in natural
selection,of course; just passive filtering -- survival of those who
happen to make it through the "holes" in the environmental sieve.

Rupert Young (970220.1130) -

At the recent workshop on autonomous behaviour I went to I heard
people (biologists, I think) giving an example of model-based
response. I can't remember the exact explanation but it went
something like this. The body responds to stimuli/disturbances
on the hand in under 300ms, but it takes 700ms for the info from
the stimulus to reach the brain so "therefore" there must be some
model involved 'cos the feedback's too slow. What's the PCT
explanation ?

engineering anaysis.

1. The actor is influencing sensory input WHILE responding to it.
Control occurs in a LOOP. There are transport lags in this loop (and, as
you note above, these transport lags can be of substantial duration in
the NS). These transport lags influence the behavior of the loop
(stability, gain, phase lags, etc); but they have nothing to do with
feedback coming "too fast or too slow". In a control loop, feedback is
ALWAYS THERE.

2. What PCT (actually, control theory in general) explains is how
transport lags influence the controlling done by a control loop.
Moving an arm, say, at a rate faster than the transport lag is
certainly possible but PCT would predict (I think) considerably
more overshoot and oscillation than if the arm were moved more
slowly. PCT might also predict that control (disturbance resistance)
would be poor _during_ the movement.

To know exactly what PCT would predict, you would have to know exactly
what the subject was doing (controlling) and the characteristics of the
environment (including the mass and strength of the muscles themselves)
in which it was done. Bill has developed such a model (the Little Man).
Using that model you should be able to predict exactly what an arm
movement (say) should look like if it is made at a rate faster than the
transport lags in the model.

3. The idea that "feedback can be too fast or too slow" was a hopeful
myth aimed at protecting a causal model of behavior. One version of the
causal model says that behavior is output that is computed by "motor
programs" on the basis of an internal model of the environment (sound
familiar?). In fact, as we all (save Hans) know, behavior is the
control of perception.

Best

Rick