# Misc., constant ...

**URL:** <http://discourse.iapct.org/t/misc-constant/7021>\
**Category:** CSG1996\
**Created:** [July 23, 1996, 2:34am UTC](http://discourse.iapct.org/t/misc-constant/7021 "1996-07-23T02:34:05Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Hans\_Blom](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/h/b77776/32.png) [@Hans\_Blom](http://discourse.iapct.org/u/Hans_Blom)\
**Post date:** [July 23, 1996, 2:34am UTC](http://discourse.iapct.org/t/misc-constant/7021/1 "1996-07-23T02:34:05Z")

</div>

[Hans Blom, 960722b]

(Bill Powers (960722.1315 MDT))

> Hans Blom, 960715 --
> 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bill, I received your Artificial Cerebellum program. I'd like to  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;have the equations that it implements. I hate reverse engineering!
> 
> I gave you more than you gave me! But I'll try to get to it. It's pretty  
> simple.

I remember having given a pretty thorough discussion of what the  
program did, even to the point of defining what stochastic variables  
are and how to compute with them. Anyway, I haven't gotten your  
program to run yet, because I'm pretty unfamiliar with 80x86  
assembler, both code and program. Could you get me a full Pascal  
version or ship the .obj file?

> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;An organism is twice presented with exactly the same perceptual  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;field from exactly the same position. Between the two  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;presentations, there is something like a "tracking experiment",  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;just like in my satellite example. On the second presentation, the  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;organism "sees" more because uncertainty has been removed, although  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;it \_sees\_ exactly the same.
> 
> I haven't the slightest idea what you mean by that.

Then this is a perfect example of what I mean. At this moment, it  
could still mean pretty much anything. You're very uncertain as to  
what it signifies, if anything. It could be a more or less random  
collection of words strung together.

Then I could explain to you exactly what it means, until you're fully  
satisfied. Maybe you will still think that I utter complete nonsense,  
but that will be for a different reason ;-).

After I've explained what I mean with this text, I present it to you  
a second time. This time, your reaction will be, I predict, very  
different from the first time. That's what I meant with this example.  
Reduction of uncertainty. "What does it mean?" versus "Oh, that!"

> A constant disturbance is simply a disturbing variable that happens, for  
> some period of time, to be constant.

Sure. But that was not my point. My point was whether I know it  
\_after the fact\_ or before. When I'm going to throw dice, I cannot  
predict the outcome. That's random. When I've thrown them, the  
outcome isn't random anymore: it's fixed, determined, even though  
the outcome still may be hidden under the poker cup.

If I know that some variable \_is going to be constant\_ for a while, I  
can use that knowledge in (predictive) control. If I don't know that,  
I cannot count on it and will have to reckon with all eventualities.  
If the variable turns out \_to have had\_ a constant value for a while,  
that wouldn't have helped in my design of the control system or its  
control law. It may show up in the controller's performance as better  
than normal (or possibly worse than normal) behavior, but that will  
be all. The term "random" applies to my knowledge of what a FUTURE  
outcome will be. Once it has happened, nothing is random anymore.  
(That I may not know its past values is a different problem).

> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;For a control system to be able to  
> resist disturbances, it must be able to resist them no matter how they  
> are behaving -- whether they are varying, or for the time being not  
> varying.

That's exactly my point. If a variable just HAPPENS to be constant  
for a while once in a while, it's still random -- unpredictable.

> Hans says of disturbances (960715d), "If it's not random, it's  
> predictable." But this shows the bias that comes from thinking only in  
> textbook terms of a formal mathematical system.

In the design of a control system, it is important to know the  
environment in which it will operate, just like an organism can only  
survive in its ecological niche. The more you know about the environ-  
ment, the better your control(ler) will be. If you know nothing  
about the environment, the "controller" might turn out to be an  
oscillator.

> as "unexpected" or "unforeseen." No matter how complete your model of  
> the environment, there are always potential disturbances that have not  
> been explicitly represented in the model. They are neither predictable  
> nor unpredictable; they are simply surprises.

I would equate surprising with unpredictable. If you are able to  
predict an outcome, will you still be surprised by it?

> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;If the signal changes slowly, it is highly predictable. If  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;something is highly predictable, it can be modeled with ease: just  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;discover the filter. And you need only the filter to generate the  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;best possible predictions.
> 
> That's assuming that you know what is going to cause a disturbance  
> before it does so.

Exactly! But it is not necessary to know the \_cause\_, though it may  
help. My blood pressure controller, for instance, has built-in  
knowledge that the pressure cannot vary faster than a certain rate. I  
have no idea why, and that's not important either. Knowing the cause  
wouldn't make control better! Knowing \_that\_ the signal has a certain  
bandwidth is sufficient knowledge.

> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I doubt that even in engineered plants this is  
> possible. How do you set up your model so as to take account of the fact  
> that the maintenance man will accidentally put 90-weight grease in a  
> gear box instead of 5-weight machine oil?

You don't. We cannot model everything. How do you tell yourself that  
your bank may collapse at any time, loosing all your money? We  
usually don't model (and don't control for) the fully unexpected.

What I \_do\_ design in is a "reality (self) check", where the  
controller monitors its own control quality. If it detects that it  
cannot control anymore, it issues an alarm and shuts off, so that the  
(hopefully better qualified) clinician can (must) take over.  
Controlling the unexpected is not possible; monitoring for it is.

Having said that, I must say that this is a problem, that could be  
solved by a higher hierarchical control layer. But that's a different  
discussion.

> Fine: now how about explaining this as you would to a student? What is a  
> covariance matrix? How is it computed? And in particular, what are the  
> computations by which the values of pax, pxx, and so on are found? Your  
> answer tells me that you know a great deal, but does not convey any of  
> that knowledge to me.

And I'm not willing to explain all that. As it is, my teaching load is  
large enough. I've given you a number of keywords that might point  
the way. I do not intend to design a course for a one or two person  
audience. I suggest you find an introduction to Kalman filtering (I  
suggested one in my previous post).

> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;By the way, why necessarily a SCALAR signal? Do you think that the  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;high level concepts of the human brain are scalars? Why not  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;vectors?
> 
> Vectors are simply lists of scalar variables treated, by convention, as  
> a single entity. A vector does not imply any relationship among the  
> scalar components: it is ONLY a list.

Be careful! A list is technically taken to mean an \_unordered\_ set of  
values, as in a grocery list where the ordering of the entries is not  
important. That is not true for a vector, where (1, 2) is something  
very different from (2, 1).

> Only when a vector becomes an input to some matrix operation are any  
> relationships among the elements created.

No. Draw vectors (1, 2) and (2, 1) into a common frame of reference  
and see the difference.

> We can continue this to the output function and the environment. As we  
> do each operation IN EXPANDED FORM, we find that the matrix-vector  
> notation is only that, a convenient notation. The actual physical system  
> has to perform each implied operation in full detail. It can't make use  
> of the vector-matrix notation.

That depends on the level that you intend for the "physical system".  
In some BASICs, you can write c = a \* b or c = a / b, where a, b and  
c are matrices. Unless you understand the BASIC compiler or inter-  
preter, you have no idea of how it's done. But at an even lower  
level, all that happens is that signals that represent zeroes and  
ones are inputs to gates and flipflops that produce different  
outputs. At a lower physical level still, electrons move.

But that's not what I meant. What I mean is that a vector might stand  
for a "concept". A "concept" need not necessarily have the form of a  
scalar, as in the "grandmother cell" hypothesis where the firing of a  
single cell or cell assembly is thought to represent the concept that  
I see my grandmother.

> HPCT is exactly the same as a system presented in vector-matrix form,  
> but the implied operations are simply spelled out in expanded form. Even  
> the interaction terms are represented in the forms of the individual  
> functions. As far as I can see, the ONLY advantage of using the matrix-  
> vector notation is convenience in manipulating symbols.

Yes, about in the same way as a control circuit diagram is sometimes  
more convenient to bring a meaning across than a collection of  
English words. But only if you understand the syntax and semantics of  
its "language"...

Greetings,

Hans