Control of behavior: Real and Illusory?

CSGnet Archive CSG1998
1

[From Bruce Abbott (980903.1055 EST)]

Rick Marken (980903.0900) --

I now think the distinction I am trying to make is
between _real_ and _illusory_ control of behavior.

I think you're going to get into trouble calling one form of control "real"
and the other "illusory." In both cases the control exerted by the
controller on the controlee's finger position is real, real, real, real, real.

The distinction you are trying to make has only to do with the nature of the
feedback path between the controller's outputs and the position of the
controlee's finger. When the controller is directly manipulating the
controllee's finger, the finger moves (if it does) because of the forces
developed on the finger by the controller's muscles. When the controller is
acting by disturbing the controllee's cv, the disturbance is a true
independent (causal) variable which, through the closed-loop mechanism of
the controllee's cv control system, causes forces to be developed on the
finger-arm system which move it back toward its reference position.

In the first case, there is little the controllee can do to interrupt the
feedback path in the controller's system. In the second case, the feedback
path _can_ be eliminated by the controllee, _if_ the controllee is willing
to give up controlling the cv (or can find another way of controlling it
that doesn't involve finger postioning).

But imagine a slightly different situation for case one. Instead of
positioning the controllee's finger by pushing directly on the finger, the
controller tugs on a string tied to the finger. So long as the string
remains securely fastened, the controller can successfully control the
position of the controllee's finger. This is true control and would pass
any test for control. But let us add that, at any moment, the controllee
can release the knot securing the string to her finger. Surely you would
not now claim that the controller's control over the position of the
controllee's finger is, so long as the string remains tied, only illusory.
Yet this situation is essentially the same as that provided by case two: In
both cases, preservation of the necessary feedback path depends on
maintaining a third variable in an appropriate state (string tied in case
one, controllee controlling her own cv in the case two). That in case two
this involves a control system is immaterial. The distinction you are
trying to make hinges only on whether the controllee does or does not have
control over whether the feedback path exists. When the feedback path does
exist, the control exerted by the controller over the controllee's finger
position is as real as it gets. When the feedback path is eliminated, that
control ceases to exist. In neither case does it become "illusory."

Regards,

Bruce

2

[From Rick Marken (980904.0820)]

Bruce Abbott (980903.1055 EST)--

I think you're going to get into trouble calling one form
of control "real" and the other "illusory."

Predicting that I will get into trouble is as safe as
predicting that the sun will rise in the morning.

The distinction you are trying to make has only to do with the
nature of the feedback path between the controller's outputs
and the position of the controlee's finger.

Yes. That's true. But I still think it's legitimate to call
control of the output of a control system "illusory" because
the controller can't really control that variable. If there is
a disturbance to the controlled variable, the controller has
no way to compensate for that disturbance (without resorting to
"real" control over the variable). In the finger tracking
demo, if the subject's finger stops staying close to the
controller's finger there is nothing the controller can do to
compensate for this change in the controlled variable other
than grab the subject's finger and force it to follow.

When the feedback path does exist, the control exerted by the
controller over the controllee's finger position is as real
as it gets. When the feedback path is eliminated, that
control ceases to exist. In neither case does it become
"illusory."

Control doesn't _become_ illusory when the output of a control
system stops behaving as desired; this autonomous change in
the behavior of the control system's output _reveals_ that your
control was illusory all along. You don't _lose control_ when
the subject in the finger tracking demo stops tracking your
finger; you just see that you were never really _in control_.

This is quite different from what happens in the situation you
describe -- where a causal feedback path is broken. In that
case we go from real control (when the feedback path is in
place the controller can control the controlled variable,
protecting it from disturbance) to _no control_ (when the
feedback path is broken the controller can't control the
controlled variable _at all_).

So I think the distinction between real and illusory control
is valid and _useful_. It is useful because, if it is understood,
it can keep people from being fooled into thinking that they
_can_ control behavior by non-coercive means. I think it's
important for people to understand that the only way they can
_really_ control the behavior of a living system is through
the use of coercive force.

It's difficult to convince people that a controlling approach
to dealing with human behavior is a problem if these people
believe that they _can_ successfully control human behavior
by non-coercive means (such as by offering "incentives" and
"rewards"). So I think the message of PCT should be clear: you
_cannot_ control human behavior non-coercively; when it seems
like you _are_ controlling behavior non-coercively (through the
use of rewards and incentives) this is an _illusion_; it's best
to stop _trying_ to control human behavior (when possible; it's
still appropriate to use coercion to pull your 6 year old out
of traffic) and to start trying to cooperate with each other.

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken

3

[From Bruce Abbott (980904.1245 EST)]

Rick Marken (980904.0820) --

Bruce Abbott (980903.1055 EST)

The distinction you are trying to make has only to do with the
nature of the feedback path between the controller's outputs
and the position of the controlee's finger.

Yes. That's true. But I still think it's legitimate to call
control of the output of a control system "illusory" because
the controller can't really control that variable. If there is
a disturbance to the controlled variable, the controller has
no way to compensate for that disturbance (without resorting to
"real" control over the variable). In the finger tracking
demo, if the subject's finger stops staying close to the
controller's finger there is nothing the controller can do to
compensate for this change in the controlled variable other
than grab the subject's finger and force it to follow.

Let's put this in the context of the "rubber band" demo. Person 1 is
attempting to keep the button centered over the coin (by moving her end of
the rubber band) while Person 2 tugs at the rubber band from the other end
(which disturbs the position of the knot). By moving his end of the rubber
band in the right way, Person 2 can cause person 1's finger (which is
holding her end of the rubber band) to trace out a circle on the table.
Now, Person 3 pushes gently on the hand Person 2 is using to hold his end of
the rubber band. You are saying that Person 2 has no way to resist this
disturbance?

What you really mean to say is that Person 2 has no way to reassert control
over Person 1s finger position if Person 1 stops controlling for keeping the
button over the coin. That is not a disturbance to Person 2's cv, that is a
loss of control over the cv by Person 2, resulting from the loss of feedback
via the path through Person 1. The control system has ceased to exist.

While that feedback circuit remained intact, Person 2 had real control over
Person 1s finger position. Real control, Rick, not illusory. When the
circuit was broken, Person 2 had no control over Person 1's finger position.

Control doesn't _become_ illusory when the output of a control
system stops behaving as desired; this autonomous change in
the behavior of the control system's output _reveals_ that your
control was illusory all along. You don't _lose control_ when
the subject in the finger tracking demo stops tracking your
finger; you just see that you were never really _in control_.

You're speaking nonsense. No wonder so many folks get the idea that PCT is
extremely difficult to understand.

What you should be saying is that you really _were_ in control, but only
because Person 1 permitted you to be in control by maintaining the feedback
connection through her. You weren't _forcing_ her to behave as you wished,
as would have been the case if you grabbed her finger and forced it to go
where you wanted it.

But even that assumes that Person 1 was willing and able to give up control
over coin position. If coin position were Person 1's means of staying alive
(and Person 1 dearly wanted to stay among the living), then Person 1 would
have no choice but to continue to control for coin position, and Person 2
could make her move her finger anywhere he wanted it to go.

So I think the distinction between real and illusory control
is valid and _useful_. It is useful because, if it is understood,
it can keep people from being fooled into thinking that they
_can_ control behavior by non-coercive means. I think it's
important for people to understand that the only way they can
_really_ control the behavior of a living system is through
the use of coercive force.

I think I've just shown how they _can_ control behavior through non-coersive
means. It's no illusion. I can't "make" you do it noncoersively, but I can
sure set up conditions so that you will do as I wish, because otherwise you
will have to give up control over certain things that matter to you, or go
through a great deal of inconvenience which simply isn't worth the trouble.
For example, you will continue to perform your job (doing as your employer
wishes) because (a) this does not seriously conflict other variables whose
control is important to you and (b) doing so allows you to control other
variables (like making your house payments and saving for your kids' college
education).

It's difficult to convince people that a controlling approach
to dealing with human behavior is a problem if these people
believe that they _can_ successfully control human behavior
by non-coercive means (such as by offering "incentives" and
"rewards").

Here is a case of wishes dominating over objective logic. You don't want to
believe that incentives can work, so you come up with this peculiar analysis
to justify that belief. Real control is only an illusion . . . . Come on,
Rick, wake up and smell the coffee.

Regards,

Bruce

4

[From Rick Marken (980904.1230)]

Bruce Abbott (980904.1245 EST) --

Thanks for showing me what my next demo and publication should be
about: "Control of Behavior: Illusion and Reality". It's really
great to have you around. You gave me the idea for "The Dancer
and the Dance" paper, too. Thanks.

Now, Person 3 pushes gently on the hand Person 2 [the controller]
is using to hold his end of the rubber band. You are saying that
Person 2 has no way to resist this disturbance?

No. I said Person 2 [controller] has no way to control Person
1's [controllee's] output.

What you really mean to say is that Person 2 has no way to
reassert control over Person 1s finger position if Person 1
stops controlling for keeping the button over the coin.

No. I mean that Person 2 has no control over Person 1's output
even when Person 1 is controlling for the button being over
the coin.

That [stopping control] is not a disturbance to Person 2's cv,

I know. A disturbance variable would be Person 2's reference for
the controlled variable. The feedback function (Person 1's
control system) is still in place; there is just nothing Person
2 can do to compensate for variations in this disturbance variable.

While that feedback circuit remained intact, Person 2 had real
control over Person 1s finger position. Real control, Rick,
not illusory.

I guess I'll have to develop a demo to show that this control
is illusory. I'm sure it won't convince you (any more than my
"Dancer.." paper convinced you to start testing for controlled
variables) but it will be useful to people who are not already
committed to believing in the reality of behavior control.

Me:

Control doesn't _become_ illusory when the output of a control
system stops behaving as desired; this autonomous change in
the behavior of the control system's output _reveals_ that your
control was illusory all along. You don't _lose control_ when
the subject in the finger tracking demo stops tracking your
finger; you just see that you were never really _in control_.

Bruce:

You're speaking nonsense.

God, I love having you around!

No wonder so many folks get the idea that PCT is extremely
difficult to understand.

I have tried to tell these people that PCT is actually
extremely easy. The only thing that makes it difficult for
anyone to understand PCT is _prior committments_. I think
you are living, posting proof of that statement.

I think I've just shown how they _can_ control behavior through
non-coersive means.

I think not.

I can't "make" you do it noncoersively, but I can sure set up
conditions so that you will do as I wish

When you "set up the conditions" you are using real control
(coercion). You're committment to behavior control apparently
blinds you to your own coercive ways. You can control a rat's
bar press behavior because you can control (real control) the
rat's physical location; you can lift it up and put it in a cage
and prevent it from getting food; you can shave it's back to make
sure it can't avoid getting shocked. You maintain the illusion
that you can control behavior non-coercively by using coercion
big time.

Real control is only an illusion . . . . Come on, Rick, wake
up and smell the coffee.

No. Illusory control is an illusion; real control (like the
stuff you do to your animals) is control.

I'd be happy if you would just wake up, but it looks like you
are enjoying your dogmatic slumbers. Nighty night.

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken

5

[From Bruce Abbott (980904.1555 EST)]

Bruce Abbott (980904.1245 EST)

Rick Marken (980904.1230) --

Now, Person 3 pushes gently on the hand Person 2 [the controller]
is using to hold his end of the rubber band. You are saying that
Person 2 has no way to resist this disturbance?

No. I said Person 2 [controller] has no way to control Person
1's [controllee's] output.

You seem to have skipped over the bulk of my post -- you know, the part
where I demolish your argument. In retribution, I'll skip over the rest of
yours.

Just listen to yourself, Rick. Your writing is riddled with contradictory
assertions (from your first post on the subject):

Illusory control of behavior occurs when I
control the movement of your finger by disturbing a variable
(the distance between our fingers) that you want in a particular
state (zero distance).

So illusory control is when you control (really control) my behavior . . .

Illusory control is illusory because there is not a causal
feedback path from action to controlled behavioral result;
the feedback path goes through a closed loop control system.

The causal path between disturbance and action runs through a closed loop
control system. It is still a causal path. Put the control system in a
black box and, if the reference is constant, all you will observe is what
appears to be a nice, ordinary input-output function that would make any S-R
system proud.

In illusory [control], the controller takes advantage of the closed-loop
characteristics of a control system to control its behavior; but
these characteristics actually make real control of a control
system impossible.

Ah, so the controller . . . _controls_ the (other) control system's
behavior, but by some miracle this real control, which actually occurs, is
impossible. Anyone who enjoys sophism will _love_ this one.

The behavior of the control system can only be
controlled as long as the control system itself creates no
"disturbance" to the controlled behavioral variable (by changing
it's references, abandoning control of a variable, taking control
of the variable or whatever autonomous little things it decides
to do).

Now you're saying that the control system _can_ be controlled (real
control). Didn't you say that it couldn't, that the control is only
illusory? (Yes, you did; I just checked.)

In both real and illusory behavior control, the controller
is _controlling_ behavior, in the sense that the controller
is organized as a closed - loop control system with respect
to the controlled behavioral variable.

Arrgh! You said it again: you just said that in both cases the controller
_is_ controlling (real control) behavior. So it's not an illusion, is it?

So whether the control we exert is real or illusory (in terms
of the effect we have on the controlled variable) we can
really be _controlling_ (or, in the illusory case, really be
_trying_ to control). And whether or not we are really
controlling can be established by Test.

So now, even if the control is illusory, we are _really_ controlling. Whew.
Rick, you are the king of self-kontradiction.

I rest my case. Thanks Rick, I really enjoyed this one -- it was so _easy_.

Really, really controlling, but only in an illusory manner,

Bruce

P.S. I'd _love_ to see your VinSim model of this, where you prove that real
control is illusory (an illusion, not real) and that even though it's
illusory it's still real. Bring on the model!!!

6

[From Rick Marken (980904.1600)]

Bruce Abbott (980904.1555 EST) --
Bruce Abbott (980903.1055 EST) --

Bruce, you are absolutely right. The distinction I was
trying to make between real and illusory control is
incorrect. Both are real control -- real real real, as
you say.

My intuition about this was completely wrong. I thought
that it would be impossible to control a person's output
if their reference was changing randomly. In fact, such
random variations in reference signals create no control
problems at all.

I wrote up a "pursuit" tracking task where you could use
either of two cursors to track the target. One cursor (c1)
was just a regular cursor; it's position was determined by
the position of the mouse and a fixed or variable disturbance.
The other cursor (c2) was the output of a computer simulated
control system that was trying to keep an invisible cursor in a
fixed or varying reference state (the reference signal was
exactly the same variable as that used as the disturbance to c1).
My mouse movements were simply a disturbance to the position of
this invisible cursor.

It turns out that I had no problem keeping either c1 or c2
on the _moving_ target; that is, I could control the output
(c2) of a control system with a varying reference signal just
as well as I could control the output of a causal system (c1).
I was able to control these variables equally well in the
sense that I was able to protect my perception of the distance
between c1 or c2 and the target from disturbance, whether that
disturbance was an actual, physical effect on the controlled
variable (as with c1) or the effect of variations in the
reference signal of a control system (as with c2).

I thought control of c2 would be lost when the reference signal
in the control system _varied_. That's why I thought it was
appropriate to call control illusory when controlling the output
of a control system. But the control is _not_ illusory; as Bruce
said (and as the Test shows) the output of a control system
can be kept under control (protected from disturbance) just as
a variable that is just a plain old physical variable.

The only time you lose control of the control system output
variable (c2) is when the gain of that system goes to zero.
But, as Bruce notes, that's equivalent to cutting the physical
feedback connection to phyical variable; you simply no longer
have an effect on the output variable via the control system.

The only situation I can think of where the term "illusory
control" applies is the one I mentioned in my original post on
this topic; the case where you surreptitiously remove the
connection between controller and controlled variable (as I
did in the experiment described in _Mind readings_, p. 67) so
that the controller continues to believe that his actions
have an effect on the controlled variable.

I will try to develop the "control of output" demo and put it
up on the net. I think the result is relatively surprising. And
then there would be one demo that shows that Bruce Abbott was
right: operant conditioners really _can_ control behavior.

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken

7

[From Bill Powers (980905.0713 MDT)]

Rick Marken (980904.1600)--

Bruce, you are absolutely right. The distinction I was
trying to make between real and illusory control is
incorrect. Both are real control -- real real real, as
you say.

Please work up your simulation in Vensim so everyone on our simulations
list can run it (17 people so far, believe it or not). It's not Vinsim,
everyone -- Vensim stands for Ventana (Inc) Simulator.

Since you can't have a mouse input, try making the controller's reference
signal be

reference = smooth3i(random uniform(-10,10,0),slow,0)

The arguments of "smooth3i" are input, slowing factor (as we call it) and
initial value. This is a three-stage filter just like the one we use to
make random disturbances.

The arguments of "random uniform" are minimum, maximum, seed.

This is the ONLY way to settle arguments about control systems. All other
methods are just playground squabbling.

Best,

Bill P.

8

[From Rick Marken (980905.0930)]

Bill Powers (980905.0713 MDT) --

Please work up your simulation in Vensim

Ok. But you might be getting a few phone calls since I have no
idea how to do that. One problem is that I have used a very
similar language -- Stella -- and there is a lot of "negative
transfer", sort of like going from a Mac to a PC or a Sun.

I don't think I can get to the Vensim until Monday, though; Linda
has some serious culture planned for me and I want to get the
Java version up first so people with browsers can "feel" how it
works.

This is the ONLY way to settle arguments about control systems.
All other methods are just playground squabbling.

Ain't that the truth. I wish I could remember it;-)

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken/

9

From [ Marc Abrams (980905.1540) ]

[From Rick Marken (980905.0930)]

Ok. But you might be getting a few phone calls since I have
no idea how to do that. One problem is that I have used a
very similar language -- Stella -- and there is a lot of
"negative transfer", sort of like going from a Mac to a PC

or >a Sun.

Bullshit. If you can model it in Stella you can do it in
Vensim. Your demos are _inaccesssable_ ( at least the
underlying code ) to me. I don't understand it and so they
are _useless_ to _my_ gaining a better understanding of
_how_ the model works and relates to PCT . Seeing model
outputs don't mean squat to me either, and listening to
_descriptions_ of _your_ tracking experiments mean even
less. I'd like to learn PCT. I'd also like to be able to
explore it through the use of modeling. _I_ will not learn
PCT through _your_ demos because I can't begin to understand
the _dynamics_ of the components of the system through your
or Bills programming efforts. I can't organize the code to
"see" the "flow".

I don't think I can get to the Vensim until Monday, though;
Linda has some serious culture planned for me and I want to
get the Java version up first so people with browsers can
"feel" how it works.

You are wasting your time. What exactly does "getting the
feel of how it works" mean? You mean another
"interpretation" by you of something you and Bill and
possibly a few others on the net understand. Getting to
Vensim on Monday is not the problem. Neither you or Bill
seem to understand that SD is a way of representing,
modeling, and simulating systems. It's based on control
theory but has _significant_ differences between how you
_have_ represented a control process ( with block diagrams )
and how you _might_ represent the _same_ process with SD.
Judging from Bills first attempt, either he doesn't
understand or doesn't care. Either way I think you are
_both_ missing the boat. To bad. Vensim, or more accurately,
SD provides a larger audience with similiar ideas to PCT. I
believe _both_ could benefit from PCT, but I don't think
_that_ is going to happen.

Ok Rick. It's put up or shut up time for you. For 25 years
you have been making demos that people have largely ignored.
Here is a chance to be able to _expose_ your logic and have
people see what is under the hood and to be able to discuss
it with you. I _don't_ think you will learn SD. It doesn't
serve your purpose of being a high priest if others have
access to the same insight and knowledge. Imagine Rick,
having to share, rather then Preach ( I mean teach ) PCT.

I don't think you have half the desire to help people learn
PCT as you do in remaining and maintaining your position as
a high priest of PCT.

Your more concerned with being _right_ ala Bruce Abbott,
Bruce Gregory, Bruce Nevin, et al. then you are about
helping us understand ( by making a model visible to all
_before_ you open up your mouth ) the concepts involved.
Btw, Why are Tim's diagrams any better or worse then Bruce
Nevin's?

This is the ONLY way to settle arguments about control
systems. All other methods are just playground squabbling.

Ain't that the truth. I wish I could remember it;-)

If you _wanted_ to you would. Your full of shit.

Marc

10

[From Bill Powers (980905.1524 MDT)]

Marc Abrams (980905.1540)--

Wow. This is the first I've heard that you didn't like my control system
model. What didn't you like about it? Could you show how to do it better?

Best,

Bill P.

11

[From Rick Marken (980905.2210)]

Marc Abrams (980905.1540)--

I put the Java demo up at my web site as "Control of Behavior"
so that people can feel free to continue ignoring my demos to
their heart's content (I've only been at it for 20 years, by
the way, so I've got plenty of room for more ignorers -- or
is that ignoramaces;-)).

I see that Bruce Abbott did the Vensim simulation. I haven't
looked at it in detail yet but based on the description it
looks like it should be a nice match to my demo.

And try to avoid the potty mouth;-)

Love

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken/

12

From [ Marc Abrams (980905.1202) ]

[From Bill Powers (980905.1524 MDT)]

Wow. This is the first I've heard that you didn't like my
control system model. What didn't you like about it? Could
you show how to do it better?

Actually, your control system model was ok. Can I show you
how to do it "better". I don't know. But I can show you how
to do it _differently_. But that was _not_ the basis for my
post.

My issues with _you_ are the fact that you do not know the
SD paradigm, and I think you could care less. If you did you
would have spent more then 5 minutes looking at the web
sites I referenced for you, so you would have _some_ idea
about the SD Paradigm and how people are using it. Your
control process model does not conform to that convention.
Is that bad? I don't know. But I certainly think it's worth
discussing. You asked for feedback on your Simulation Phase
I so I am giving you mine. I have _no_ idea where you are
going. I do not know Where the starting point is and where
the ending point ( That is what are we supposed to be
accomplishing? ). Is what you explained in Phase I have
something to do with How to model in Vensim ( I don't think
so ) Did it have something to do with the nature of
understanding Feedback Loops ( both positive and negative )
the backbone of systems structure. ( I don't think so ) Were
you perhaps talking about the kinds of modeling elements in
the SD paradigm and how they matched up with the way _you_
have done your modeling? ( I don't think so ) Were you
talking about the pros and cons of styles of different
modeling methods? ( I don't think so ) Now here is the big
one Bill. _How_ is this tool ( _Any_ SD modeling tool )going
to help anyone model anything any better then what you have
already done?

These are _some_ of my questions. Not all.

I think PCT is important. I also think that _many_ people on
this list have some outstanding ideas that could be and
should be explored. If they are willing to learn to model
with SD or not ) they can _do_ that exploring and hopefully
contributing to the overall cause. Learning to model in SD
will not be easy. It will take effort and time. One thing it
won't take is a background in mathematics or physics. It
will take a sound foundation in algebra. As your modeling
skills increase so can your mathematical skills. The point
is only _you_ can determine whether the benefits outweigh
the costs.

Attached is a copy of a page from Jay Forresters book
_Principles of Systems_ first published in 1968. Reprinted
in 1990. The diagram should look familiar. Just as an aside.
one reason the loop tool in Vensim does not seem to work is
that you are not constructing your loops properly. ( i.e.
according to SD modeling conventions ). It has nothing to do
with one way or two way flows as previously stated.

I happen to think that having a _basic_ understanding of the
SD paradigm is important. Not necessarily because it's
"better". But because it has a 40+ year track record that
can help us understand what has and hasn't worked and what
might and might not work for us. Why reinvent the wheel?

Marc

SD.doc (55 Bytes)

13

From [ Marc Abrams (980905.0209) ]

I think "get a life " comes to mind when i start spending
time at 2:10 am to answer e-mail. :slight_smile:

[From Rick Marken (980905.2210)]

I put the Java demo up at my web site as "Control of
Behavior" so that people can feel free to continue ignoring
my demos to their heart's content (I've only been at it for

20 >years, by the way, so I've got plenty of room for more

ignorers -- or is that ignoramaces;-)).

Rick, people don't _ignore_ them. They don't understand the
_significance_ of them. Very few people actually understand
what is happening when a demo is run. Your "descriptions" do
not hold the same "discovery" that "playing" with the
parameters of a model will allow ala Powers and Abbott

I see that Bruce Abbott did the Vensim simulation. I

haven't

looked at it in detail yet but based on the description it
looks like it should be a nice match to my demo.

OK, I have seen your demo, I have seen Bruce's model. Where
is the match? What is the match? and what is the
significance of it? Are the two complimentry? If so how? Can
we extend the model to show cooperation and coercion? How
would this match with your demo? How can i "see" it in your
demo

And try to avoid the potty mouth;-)

I usually don't talk that way in front of religious shaman
and I will mind my tongue in the future in your presence, oh
great holy one. :slight_smile:

Marc

14

[From Bill Powers (980906.0426 MDT)]

Marc Abrams (980905.1202) ]

[From Bill Powers (980905.1524 MDT)]

Wow. This is the first I've heard that you didn't like my
control system model. What didn't you like about it? Could
you show how to do it better?

My issues with _you_ are the fact that you do not know the
SD paradigm, and I think you could care less. If you did you
would have spent more then 5 minutes looking at the web
sites I referenced for you, so you would have _some_ idea
about the SD Paradigm and how people are using it.

I spent a bit more than 5 minutes looking at the MIT pages, and at Gene
Bellinger's "Outsights". It was all pretty familiar stuff -- people have
been making analog models of this kind for 50 years or so, and more if you
count doing it with pencil and paper instead of automatic computing
machinery. If I didn't spend more time at it, it was because I'm not
vitally interested in production decisions or hiring practices (etc). The
positive and negative feedback loops are not new to me.

If you'll look at Bellinger's "Archetypes" paper, the Balancing Loop
diagram is exactly the control system model I presented. Bellinger doesn't
use the "Stock-and-Flow" symbols, either, by the way. I didn't download the
actual model to see what parameters he used, but it's clear from his
description that he didn't realize how special this particular kind of loop
is.

As to the other interactive loops, what they would do depends very
critically on the parameters you put into them. The verbal descriptions are
not really very useful. This is not to say that such diagrams are not
useful, or that the models behind them would not be revelevant to real
situations. But I don't like to let the models get too far ahead of the
data. If you start analyzing a real system into basic variables and the
functions relating them, as I outlined in the first session, the loops will
show up if they are really there.

When you refer to the SD "paradigm" I'm not sure what you mean. To me, the
main importance of Vensim is that it is an analog computer implemented on a
digital system, like Wolfgang Zocher's "Simcon" and "SimPCT" programs.
Wolfgang abandoned those programs mainly because he found that others had
done the same thing, only in a more advanced form (MATLAB and SCILAB). I've
looked at SCILAB and it won't run on my computer, so I would have preferred
the programs Wolfgang was developing. I've also seen Stella, and a more
advanced analog-computing setup called Tutsim, by Korn and Korn, pioneers
in the old days of analog computing and amazingly still around (at least
one of them). Basically these programs all do the same thing: provide the
user with an analog computer that can run on a PC (or a Mac).

Once you have the analog computer available, I don't see any particular
"paradigm" in how you use it. The diagrams you come up with, and the
computing setups, depend on the system you're analyzing. As near as I can
see, "systems thinking" is simply the forgotten lore (in this digital
world) of analog computing.

You asked for feedback on your Simulation Phase
I so I am giving you mine. I have _no_ idea where you are
going.

Good. Then you are probably learning something, unless not knowing what you
don't yet know is enough to make you hold back from learning it.

I am trying to start at the beginning, with the methods of representing
observations that underly all approaches of this kind including SD and
other forms of analog computing -- the _real_ "paradigms" of systems
thinking. How do you go from observing a real working hunk of reality to a
model that represents it? How do you get actual predictions of behavior out
of such models? What do you do when you have to model a system but don't
have data about the whole system? How can you use simulations when you
don't know how to handle the math?

I do not know Where the starting point is and where
the ending point ( That is what are we supposed to be
accomplishing? ).

The ending point is the point where you can look at any behaving system and
propose a testable, runnable model of it using Vensim. That will bring you
(generic "you") as far as I have gone, and you will then, I hope, go beyond
that point.

Is what you explained in Phase I have
something to do with How to model in Vensim ( I don't think
so )

It has to do with how to model ANY system -- how to get your understanding
in shape to lead to a Vensim model. There's nothing special about modeling
in Vensim, as opposed to any similar language (as you know). I don't know
everything about this subject, but I do know some things that are learnable.

Did it have something to do with the nature of
understanding Feedback Loops ( both positive and negative )
the backbone of systems structure. ( I don't think so )

It has to do with setting up diagrams to represent some real system. Those
diagrams will often prove to contain "Causal loops." But whether they do or
not, you can still convert them into an analog computing setup and run a
simulation to help you understand the system (as Bellinger says). I
disagree with the idea that positive or negative loops are the backbone of
systems structure. That is true only for systems that really contain
positive or negative loops. How do you find out if they do? You start
tracing how one variable depends on other variables, then how those
variables depend on still other variables, and continue until, to your
surprise, you find you have arrived back at the beginning of a loop. Then
you can simulate the system and learn how these closed causal loops will
behave, and why.

Were
you perhaps talking about the kinds of modeling elements in
the SD paradigm and how they matched up with the way _you_
have done your modeling? ( I don't think so )

There is no difference: the modeling elements are identical. They are just
variables and functions, exactly as I have described them. Bellinger's
"Balancing Loop" is a control system, although he didn't know enough about
real control systems to recognize one when he saw it.

Were you
talking about the pros and cons of styles of different
modeling methods? ( I don't think so )

I'm talking about the basics of analog computing, which is what we are all
doing. There is nothing different about the SD style except some of the
pictorial representations of functions and the rules about capitalization.

Now here is the big
one Bill. _How_ is this tool ( _Any_ SD modeling tool )going
to help anyone model anything any better then what you have
already done?

It isn't. It's exactly the same method of modeling, using analog
computations (or in more advanced cases, "hybrid" analog-digital
computations, as they were called in the 1950s). The difference is not in
HOW the modeling is done, it is in WHAT IS MODELED. The underlying method
of modeling is the same no matter what kind of system you're trying to
understand: set up your network of variables connected by functions to
match the organization of the real system, then turn it on and see what the
simulation does as you vary the parameters.

I think PCT is important. I also think that _many_ people on
this list have some outstanding ideas that could be and
should be explored. If they are willing to learn to model
with SD or not ) they can _do_ that exploring and hopefully
contributing to the overall cause. Learning to model in SD
will not be easy. It will take effort and time. One thing it
won't take is a background in mathematics or physics. It
will take a sound foundation in algebra. As your modeling
skills increase so can your mathematical skills. The point
is only _you_ can determine whether the benefits outweigh
the costs.

True, all true.

Attached is a copy of a page from Jay Forresters book
_Principles of Systems_ first published in 1968. Reprinted
in 1990.

By 1968 PCT (or the work leading to it) was 15 years old. I had been doing
analog computing for at least 12 years.

The diagram should look familiar.

Unfortunately, I still can't read any Word document for a version later
than 2.0. I will see if I can get a discount on Word97, which will probably
handle it. I can read PDF up to Acrobat Reader version 3.0. I'm having
expenses trying to get my new-old desktop computer to run, so may not see
it right away.

Just as an aside.
one reason the loop tool in Vensim does not seem to work is
that you are not constructing your loops properly. ( i.e.
according to SD modeling conventions ). It has nothing to do
with one way or two way flows as previously stated.

There's nothing wrong with the loops. Using the Stock-and-Flow convention
has absolutely no different effect: you still end up with an integrator and
a Level variable. The stock-and-flow modeling convention, as far as I can
see, is purely cosmetic.

The problem with the loops isn't in the model; it's in the real system,
where the apparent feedback path (in the bucket example) is really just the
forward path traversed backward, rather than a physically distinct path.
The model is just as happy to show the feedback path as separate, whether
it really is or not. Only the modeler knows whether the model is telling
the truth.

I happen to think that having a _basic_ understanding of the
SD paradigm is important. Not necessarily because it's
"better". But because it has a 40+ year track record that
can help us understand what has and hasn't worked and what
might and might not work for us. Why reinvent the wheel?

I'm not; I'm using the same wheel. I was around when the wheel was
invented. Jay Forester learned to use it at the same time I did (or
perhaps a little earlier), but he didn't invent it, either.

What we have here is an unfortunate case of collective amnesia, which has
affected several generations of students, and has caused the thread of
analog computing to be temporarily lost (for about 30 or 40 years). Those
old codgers who have managed to keep some uses of it alive therefore seem,
to later generations, to have discovered something wonderful and new.
Unfortunately, to rediscover what is really going on will take more than
learning to program in Vensim or some similar language. But learning that
will help, especially if we're patient enough to look somewhat below the
surface of Vensim to see how and why it's used the way it is.

Best,

Bill P.

15

From [ Marc Abrams (980906.2057) ]

[From Bill Powers (980906.0426 MDT)]

I spent a bit more than 5 minutes looking at the MIT pages,
and at Gene Bellinger's "Outsights". It was all pretty

familiar >stuff --

I pointed to his site mostly because of the diversity of
views and his archetypes models. These archetypes are a
cause for great debate. Some feel ( the systems thinkers )
these provide useful tools for understranding _how_ systems
work. Others ( SD Dynamists, the hard core modelers ) think
of them as _possible_ pedagogical_ devices. Bob Eberlein is
a dynamist. he believes that all that systems thinking stuff
is a bunch of mush :slight_smile: He believes ( and I agree with him )
that _any_ diagram can be too ambiguous to use before, but
might be extremely helpful _after_ the modeling effort to
help explain it to others.

people have been making analog models of this kind for 50
years or so, and more if you count doing it with pencil and
paper instead of automatic computing machinery.

Bill, if you mentioned "Analog models" people would look at
you kind of weird :slight_smile:

>If I didn't spend more time at it, it was because I'm not

vitally interested in production decisions or hiring

practices

(etc).

That wasn't what i was talking about. It wasn't _what_ was
modeled. It was _how_ it was modeled.

Bill, certain things to you, seem self evident. Those same
things to me don't. I have struggled for years with some of
these concepts mathematically and "learned" them ( at least
conceptually ) in a relatively short period of time with
this different structure ( SD ) For me SD has been a
revalation. A way to play, discover, and learn _without_
being a _technically_ astute mathematician.

The positive and negative feedback loops are not new to me.

No, but they might be to others, and modeling how they
interact _might_ be of some interest. Although we (PCTers)
are interested in _negative feedback_ only, systems are
generally inbedded in _other_ systems. Having a solid
understanding of _General Systems_ theory wouldn't hurt.

If you'll look at Bellinger's "Archetypes" paper, the

Balancing >Loop diagram is exactly the control system model
I >presented.

That's the problem. In Gene's paper, he presented a Causal
Loop Diagram ( CLD ) to represent the balancing loop. If you
downloaded the actual Vensim model you would notice a few
important differences between the CLD and actual model.
CLD's are currently ( and have been for 40+ years ) a "hot"
topic in SD. See my statements above about diagrams. Your
models _do not_ include rate variables. Auxillary variables
are used to sub-define and refine the rate equations. I also
believe that The control process as _you_ have defined it is
_not_ neccessarily a balancing loop as most SD people use
it. ( the big difference is that the reference level is
environmental ) Please see my attached pdf paper by George
Richardson on the _Problems with causal loop diagrams_

Bellinger doesn't use the "Stock-and-Flow" symbols,

He does in his model.

either, by the way. I didn't download the actual model to

see >what parameters he used,

You should have :slight_smile:

but it's clear from his description

Your starting to sound like Rick :-). What happened to
"without a model it's all school yard squabble" :-). A CLD
_is NOT_ a model. It is a _diagram_. Like Tim's, and Bruce
Nevin's. No more no less. It has it's uses and limitations,
like _everything_ :slight_smile: else in life.

that he didn't realize how special this particular kind of

loop

is.

That is for _certain_, Yep. That's _exactly_ my point. Gene
and a whole bunch of other SDers :-). You _should_ have
downloaded the model ( it's never to late :slight_smile: ). CLD
diagrams do not tell you a lot about what the _model_
actually looks like, or what it should look like. Again,
look at George's attached paper. :slight_smile:

As to the other interactive loops, what they would do
depends very critically on the parameters you put into

them. >The verbal descriptions are not really very useful.

Don't disagree. The opportunity provided by this kind of
user interface and organization and structure in my mind,
provides a minimally acceptable form of logic
representation. Working out the details of the equations are
minor compared to the ability to organize the problem
system ) correctly. I may _never_ be on your level
mathematically but _logically_ I can provide _equal_
insights ( maybe not as often :slight_smile: ) _given_ the opportunity.
I am not interested in modeling like Bill Powers. I am
interested in modeling like Marc Abrams. _Where ever_ that
might wind up. :slight_smile:

This is not to say that such diagrams are not
useful, or that the models behind them would not be
revelevant to real situations.

Agreed, no questions about it.

But I don't like to let the models get too far ahead of the
data. If you start analyzing a real system into basic

variables >and the functions relating them, as I outlined in
the first >session, the loops will show up if they are
really there.

Bill, The loops don't just "show" up. It took 300 years for
people to see the "feedback" in Newton's equations. In
Richardson's Book _Feedback Thought in Social Systems_ He
talks about how painstakingly slow progress was until the
early part of the 20th century. What I am trying to say is
that feedback loops are _not_ self evident in the
mathematical equations that create them. And to me Feedback
loops _are_ the basic _structural_ elements in a system.
Feed back loops are made up of constants and variables.

When you refer to the SD "paradigm" I'm not sure what you
mean.

Glad you asked. :slight_smile: Forrester's genius was in the way he
_organized_ and _structured_ thinking _about_ systems. he
didn't _invent_ SD any more then you invented control
theory, but he brought the analysis of continuous systems
to a new level of understanding, a way to think about
systems that were largely dealt with _analytically_ before
and by only a handful of people, rather then with
simulation. His premises are sound and straight forward. A
lot like the game of chess. The rules are relatively easy to
understand but _mastering_ the game requires time and
effort. The great thing is that _anyone_ can play. Not
neccessarily at the same level, but it's avaiable to all.

To me, the main importance of Vensim is that it is an

analog >computer implemented on a digital system, like
Wolfgang >Zocher's "Simcon" and "SimPCT" programs.

Bill, you are not everyone else. If you think others are
interersted in learning how to model _your_ way I think you
will be sorely disappointed. the main importance of Vensim
is _not_ that it is an "analog" computer on a digital
system. The main importance is that it allows non
mathematicians and programmers to analyze systems.

Wolfgang abandoned those programs mainly because he >found

that others had done the same thing, only in a more

advanced form (MATLAB and SCILAB). I've
looked at SCILAB and it won't run on my computer, so I
would have preferred the programs Wolfgang was >developing.

I've also seen Stella, and a more advanced >analog-computing
setup called Tutsim, by Korn and Korn, >pioneers in the old
days of analog computing and amazingly >still around (at
least one of them). Basically these programs >all do the
same thing: provide the user with an analog >computer that
can run on a PC (or a Mac).

Your missing the point. Have you seen _Mathematica_? Have
you ever tried _using_ it :-). You are already programming
in Pascal. I am _not_ interested in learning how to write
simulations in assembler. I am not interested in learning to
simulate in the Mathematica environment. I am not interested
in becoming a mathematician or a programmer. In fact, I am
not interested in learning how to model the way Bill Powers
learned to model 50 years ago. I don't _have_ to. _That_ is
the beauty of these programs.

Once you have the analog computer available, I don't see
any particular "paradigm" in how you use it. The diagrams
you come up with, and the computing setups, depend on the
system you're analyzing. As near as I can see, "systems
thinking" is simply the forgotten lore (in this digital

world) of >analog computing.

Bill, SD says _all_ continuous systems can be modeled in SD
and in SD there are basic structures and elements that are
used. Your world view is different? Fine. But your wasting
your time with SD. You'd be better off with Mathematica.or
continuing with your pascal approach.

Forgotten?, not quite. It's been well and thriving for 50
years. "Systems Thinking" ( as it is currently used in
general management literature ) is a relatively recent
phenomenon ( last ten years or so ) and branched off from SD
modeling ( they conference together ) when Peter Senge
popularized the notion ( i.e. systems thinking _without_ the
modeling ) in the _5th Discipline_. Modeling has come a
_long_ way since you first encountered it in the 40's. On
one level you are absolutely correct. In the end It's _all_
the same. But, it's _how_ you get there ( or don't ) that
really matters.

You asked for feedback on your Simulation Phase
I so I am giving you mine. I have _no_ idea where you are
going.

Good. Then you are probably learning something, unless not
knowing what you don't yet know is enough to make you >hold

back from learning it.

I am missing the _context_ Bill. What's the big picture?
Again, where do you hope to go with this? I am largely
interested in using todays technology ( doesn't much matter
to me whether it is analog or digital ) to help me better
see and understand the world I live in. I am not interested
in becoming a programmer or a mathematician. Can you help?,
How? I am not asking for the details. Just an overview of
the approach. Do I need any additional reading materials?
Etc, etc.

I am trying to start at the beginning, with the methods of
representing observations that underly all approaches of

this >kind including SD and other forms of analog computing

An alternative might be in talking about how things are
structured and organized. Whether the world is analog or
digital. Our world is organized and structured into
continually changing systems and sub-systems of feedback
loops. The feedback loop is the back bone of that structure.

-- the _real_ "paradigms" of systems thinking. How do you
go from observing a real working hunk of reality to a model
that represents it?

Great question. If you start with a basic definition of a
system as:
1) An entity that maintains it's existence through the
mutual interactions of it's parts
    a) Systems are relative and exist and operate in time
and space.
    b) Dealing with systems takes the focus and concern away
from the parts and puts it on the organization and
interaction of those parts and the patterns of behavior
between them.
    c) A Systems behavior depends on it's _entire_ structure
and not just on adding up the behavior of it's different
pieces
    d) The key word is _interaction_. If one part has an
effect on the rest of the system and the system as a whole
has an effect on that one part then a "circular"
relationship or "loop" has been created.
    e) Systems can be classified as being either "open" or
"Feedback". The distinguishing characteristic is in "open
systems" is, that outputs respond to inputs but where the
outputs are isolated from and have no influence on the
inputs. An "open system" is not aware of it's own
performance.
    f) Whether a system should be classified as an open
system or a feedback system is not instinsic to the
particular assembly of parts but depends on the observer's
viewpoint in defining the purpose of the system.

Given the above the answer to your question is;
Formulating the model of a system should start from the
question "Where is the boundry, that encompasses the
smallest number of components, within which the dynamic
behavior under study is generated?"

How do you get actual predictions of behavior out of such
models?

By understanding and knowing the patterns of behavior
generated by the structure.

What do you do when you have to model a system but don't
have data about the whole system?

You _never_ model a _system_ ( whatever that happens to
be ). You _always_ model an aspect, a problem, a particular
question about a system. Then you take your best shot and
see if you can produce the behavior over time the real thing
does.

How can you use simulations when you don't know how to
handle the math?

Not easily :-). But you don't have to be Euclid either. You
do need to be able to think algebriacally, and this modern
software helps you go quite a ways.

The ending point is the point where you can look at any
behaving system and propose a testable, runnable model of
it using Vensim. That will bring you (generic "you") as far

as >I have gone, and you will then, I hope, go beyond

that point.

What's your definition of a "behaving" system. Is it the
same as mine? If different, in what regard and why?

It has to do with how to model ANY system -- how to get
your understanding in shape to lead to a Vensim model.

Ok, seems reasonable.

There's nothing special about modeling in Vensim, as
opposed to any similar language (as you know).

No problem here.

I don't know everything about this subject, but I do know
some things that are learnable.

Bill, I guess, I wished you knew more about SD. You
certainly don't need it. Your modeling efforts don't require
anything SD could offer _you_. But there _are_ a bunch of us
that could and would benefit from it's use.

It has to do with setting up diagrams to represent some

real >system. Those diagrams will often prove to contain
"Causal >loops." But whether they do or not, you can still
convert >them into an analog computing setup and run a

simulation to help you understand the system (as Bellinger
says). I disagree with the idea that positive or negative

loops >are the backbone of systems structure. That is true
only for >systems that really contain positive or negative
loops. How >do you find out if they do? You start tracing
how one variable >depends on other variables, then how those
variables >depend on still other variables, and continue
until, to your

surprise, you find you have arrived back at the beginning

of >a loop. Then you can simulate the system and learn how

these closed causal loops will behave, and why.

Not always. :slight_smile: Sometimes those nice neat diagrams don't
quite show ( after you simulate ) what you thought they
would. Ask Rick, he's becoming a semi expert at it :slight_smile:

There is no difference: the modeling elements are

identical. >They are just variables and functions, exactly
as I have >described them.

Right, and since _everything_ is made of atoms why bother
beyond that. We _know_ what everything is made of don't we.
_Atoms_.

Bellinger's "Balancing Loop" is a control system, although

he >didn't know enough about real control systems to
recognize >one when he saw it.

Bellinger's balancing loop is _NOT_ a control system as
_YOU_ define it. There is _NO_ internal reference level.

I'm talking about the basics of analog computing, which is
what we are all doing. There is nothing different about the
SD style except some of the pictorial representations of
functions and the rules about capitalization.

This is hubris talking not knowledge.

It isn't. It's exactly the same method of modeling, using
analog computations (or in more advanced cases, "hybrid"
analog-digital computations, as they were called in the
1950s).

What is an analog computation? and what difference does it
make? Integration is intergration.

The difference is not in HOW the modeling is done, it is in
WHAT IS MODELED.

Really?, What was modeled then? What is modeled now? Why
wasn't what is being modeled today done then? If analog
computers were so superior in doing it, why are they not
flourishing as tools for systems analysis today?

The underlying method
of modeling is the same no matter what kind of system
you're trying to understand: set up your network of

variables >connected by functions to match the organization
of the real >system, then turn it on and see what the
simulation does as >you vary the parameters.

I disagree _completely_.

What we have here is an unfortunate case of collective
amnesia, which has affected several generations of
students, and has caused the thread of
analog computing to be temporarily lost (for about 30 or 40
years). Those old codgers who have managed to keep some
uses of it alive therefore seem,
to later generations, to have discovered something
wonderful and new. Unfortunately, to rediscover what is
really going on will take more than learning to program in
Vensim or some similar language. But learning that
will help, especially if we're patient enough to look

somewhat >below the surface of Vensim to see how and why
it's used >the way it is.

Bill, SD has not been rediscovered. It's been in continouous
use for close to 50 years. The advent of the micro and the
speed gains over the last serveral years have made
simulations an affordable enterprise. Unfortunately it still
takes a $100,000 education to be a professional SD modeler.
Meanwhile I continue to play my electronic keyboard,
oblivious to the reality that one day i might perform in
Carnegie hall. :slight_smile:

Marc

CLD.pdf (56 Bytes)

16

[From Rick Marken (980907.1400)]

Marc Abrams (980905.0209) --

OK, I have seen your demo, I have seen Bruce's model. Where
is the match?

I've attached a slightly revised version of Bruce's Vensim model.
The system called CONTROLLER in Bruce's model corresponds to the
person (you) controlling the cursor in my Java demo; the
CONTROLLEE in Bruce's model corresponds to the computer simulated
control system who's output (called "output" in Bruce's diagram)
corresponds to the position of the _upper_ cursor in my Java demo.

When you are controlling the position of the upper cursor in
my Java demo, you are acting just like the CONTROLLER in Bruce's
Vensim model; you are trying to keep the CONTROLLEE's "output"
in a fixed reference state (at the target position in my Java
demo; equal to zero in Bruce's Vensim model).

I have changed Bruce's model so that the CONTROLLER's reference
(ref2) is a constant (zero). I have also made the CONTROLLEE's
reference a smoothed time varying random waveform, as it is
for the computer control system in my Java demo.

I have also added a couple graph's to Bruce's simulation; these
graphs correspond to the results you see in my Java demo. The
top graph in my Java demo corresponds to the graph called
CONTROLLEE BEHAVIOR in Bruce's Vensim model. Both graphs show
the CONTROLLEE's perceptual input variable and the reference
for that input. What you see (in both cases) is two lines
that are almost exactly on top of each other. What this shows
is that the CONTROLLEE can control his input perception even
though his output is being controlled by the CONTROLLER who is
controlling this output by producing disturbances to the
CONTROLEE's controlled input.

The bottom graph in my Java demo corresponds to the graph called
CONTROLLER BEHAVIOR in Bruce's Vensim model. At least, it does
when you are controlling the _upper_ cursor ( the CONTROLLEE's
output) in the Java demo. Both of these graphs show the CONTROLLER's
perceptual input and reference for that input (the later being
a horizontal line since it is a constant). What this shows
is that the CONTROLLER can control the CONTROLLEE's output,
even though the CONTROLLEE's reference for his input is varying
all over the place (as shown in first set of graphs).

This was the result I did not expect based on my intuition. I
thought (based only on intuition) that a CONTROLLER could not
control a CONTROLLEE's output by disturbing the CONTROLLEE's
perception when the CONTROLLEE's reference for that perception
was varying unpredictably. As this modeling exercise proves,
a CONTROLLER _can_ control a CONTROLLEE's output even if the
CONTROLLEE is always "changing his mind" about what he wants
(the intended state of the controlled perceptual input variable).

Hope this helps.

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken/
disturbance=
        -o2
        ~
        ~ |

i2=
        output
        ~
        ~ |

e2=
        ref 2-p2
        ~
        ~ |

p2=
        i2
        ~
        ~ ~ :SUPPLEMENTARY
        >

ref 2=
        0
        ~
        ~ |

o2= INTEG (
                (100*e2 - o2)*0.05,
                                50)
        ~
        ~ |

error signal=
        reference signal-perceptual signal
        ~
        ~ |

input=
        output+disturbance
        ~
        ~ |

output= INTEG (
        (100*error signal - output)*0.05,
                100)
        ~
        ~ |

perceptual signal=
        input
        ~
        ~ |

reference signal=
                 10*SMOOTH3i(random uniform(-200,200 , 10),5,0)
        ~
        ~ |

********************************************************
        .Control
********************************************************~
                                Simulation Control Paramaters
        >

FINAL TIME = 50
        ~ Second
        ~ The final time for the simulation.
        >

INITIAL TIME = 0
        ~ Second
        ~ The initial time for the simulation.
        >

SAVEPER = 0.1
        ~ Second
        ~ The frequency with which output is stored.
        >

TIME STEP = 0.01
        ~ Second
        ~ The time step for the simulation.
        >

\\\---/// Sketch information - do not modify anything except names
V300 Do not put anything below this section - it will be ignored
*View 1
$0,0,Times New Roman|12||0-0-0|0-0-0|0-0-0|-1--1--1|-1--1--1
10,1,reference signal,304,299,39,8,0,3,0,0,0,0,0,0
10,2,perceptual signal,403,220,43,8,0,3,0,0,0,0,0,0
10,3,error signal,305,255,29,8,0,3,0,0,0,0,0,0
10,4,output,191,170,19,8,0,3,0,0,0,0,0,0
10,5,input,410,169,15,8,0,3,0,0,0,0,0,0
10,6,disturbance,410,105,30,8,0,3,0,0,0,0,0,0
1,7,2,3,1,0,0,0,0,64,0,-1--1--1,1|(382,242)|
1,8,1,3,0,0,0,0,0,64,0,-1--1--1,1|(304,284)|
1,9,3,4,1,0,0,0,0,64,0,-1--1--1,1|(230,235)|
1,10,4,5,1,0,0,0,0,64,0,-1--1--1,1|(295,169)|
1,11,5,2,1,0,0,0,0,64,0,-1--1--1,1|(405,191)|
1,12,6,5,0,0,0,0,0,64,0,-1--1--1,1|(410,130)|
10,13,ref 2,102,47,13,8,0,3,0,0,0,0,0,0
10,14,p2,31,103,9,8,0,3,0,0,0,0,0,0
10,15,e2,101,103,8,8,0,3,0,0,0,0,0,0
10,16,o2,210,104,8,8,0,3,0,0,0,0,0,0
10,17,i2,32,172,7,8,0,3,0,0,0,0,0,0
1,18,13,15,0,0,0,0,0,64,0,-1--1--1,1|(101,68)|
1,19,14,15,0,0,0,0,0,64,0,-1--1--1,1|(59,103)|
1,20,15,16,0,0,0,0,0,64,0,-1--1--1,1|(148,103)|
1,21,17,14,1,0,0,0,0,64,0,-1--1--1,1|(30,138)|
12,22,0,207,277,42,8,0,4,0,0,-1,0,0,0
CONTROLLEE
12,23,0,242,66,42,8,0,4,0,0,-1,0,0,0
CONTROLLER
1,24,16,6,0,0,0,0,0,64,0,-1--1--1,1|(292,104)|
1,25,4,17,0,0,0,0,0,64,0,-1--1--1,1|(112,170)|
12,26,0,301,224,164,90,3,0,0,2,-1,0,0,0,0-0-0,0-0-0,|12||255-0-0
12,27,0,297,24,126,9,0,4,0,10,-1,0,0,0,0-0-0,0-0-0,|14||255-0-0
CONTROL OF BEHAVIOR SIMULATION
///---\\\
:GRAPH CONTROLLER_BEHAVIOR
:TITLE Controller Behavior
:SCALE
:VAR ref 2
:Y-MIN -50
:Y-MAX 50
:SCALE
:VAR output
:Y-MIN -50
:Y-MAX 50
:GRAPH CONTROLLEE_BEHAVIOR
:TITLE Controllee's Behavior
:SCALE
:VAR reference signal
:Y-MIN -100
:Y-MAX 100
:SCALE
:VAR input
:Y-MIN -100
:Y-MAX 100
:L <%^E!@
1:Current.vdf
9:Current
15:0,0,0,0
19:100,0
5:ref 2

17

From [ Marc Abrams (980907.1705) ]

[From Rick Marken (980907.1400)]

Hope this helps.

Yes, thank you. You delivered and I really appreciate it.

Marc

18

[From Bruce Gregory (980907.2050 EDT)]

Rick Marken (980904.1600)

Bruce Abbott (980904.1555 EST) --
Bruce Abbott (980903.1055 EST) --

Bruce, you are absolutely right. The distinction I was
trying to make between real and illusory control is
incorrect. Both are real control -- real real real, as
you say.

My intuition about this was completely wrong. I thought
that it would be impossible to control a person's output
if their reference was changing randomly. In fact, such
random variations in reference signals create no control
problems at all.

I want to make sure I understand your point. Are you telling me that even if
I vary my speed, a state trooper can pull me over for speeding? This
conclusion does not seem quite as revolutionary to me as it apparently does
to you. But then, you live in California.

Bruce Gregory

19

[From Rick Marken (980907.1940)]

Me:

My intuition about this was completely wrong. I thought
that it would be impossible to control a person's output
if their reference was changing randomly. In fact, such
random variations in reference signals create no control
problems at all.

Bruce Gregory (980907.2050 EDT)

I want to make sure I understand your point. Are you telling
me that even if I vary my speed, a state trooper can pull me
over for speeding?

No. I mean that I can control a person's output by disturbing
a variable that person is controlling even if that person's
reference for that variable is changing randomly.

I think my Java demo and Bruce Abbott's Vensim simulation (as well
as my revision) make the point pretty well.

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken/

20

[From Bruce Gregory (980908.0620 EDT)

Rick Marken (980907.1940)

Me:

> My intuition about this was completely wrong. I thought
> that it would be impossible to control a person's output
> if their reference was changing randomly. In fact, such
> random variations in reference signals create no control
> problems at all.

Bruce Gregory (980907.2050 EDT)

> I want to make sure I understand your point. Are you telling
> me that even if I vary my speed, a state trooper can pull me
> over for speeding?

No. I mean that I can control a person's output by disturbing
a variable that person is controlling even if that person's
reference for that variable is changing randomly.

I see. So the trooper cannot control my output if my reference speed is
varying randomly. Is this correct? If so, what if anything, _can_ the
trooper control?

Bruce Gregory