A Proposed Modeling Taxonomy for CSG

[Marc_Abrams5]

From [ Marc Abrams (980909.0353) ]

In lieu of the fact that I have been harping on the
_communicative_ importance of models, I would like to _open_
( that is _begin_ ) a dialog on a taxonomy of modeling
conventions to make it easier to work with and communicate
about the models. I want to stress that this is simply _my_
opening contribution into the ring.

This came about when I went into the Abbott-Marken model and
read Rick Marken's last post on it, ( 980908.1525) a reply
to Bruce G. Anyway, I took a look at Tim's last diagram,
Went into Mind Readings and B:CP and found _almost_ a
standard notation to represent the Control Process.

This notation is extremely useful when coding computer
programs. It gets a little tedious when you are trying to
"translate" the notation into "real" things. ( Don't split
hairs, I know the notations represent "real" things )
Anyway, I am going to use Bill's notation from his Vensim
Control model, & Tim's notation from his "finger" diagram.
Bill makes a distinction between "quantities" and "signals".
Those distinctions are not always consistently applied by
others, they should be.

lower case letters _only_ will be used to designate the
elements. Why?, It saves you from having to use the shift
key :-). What can I tell you. I am a lazy typist Upper
case will be used to designate a Function.

r: Reference Signal
p: Perceptual Signal
Cf: Comparator
e: Error Signal
Of: Output Function
qo: Output Quantity
CV: Controlled Variable
d: disturbing quantity
Df: Disturbance Function
qi: Input Quantity
If: Input Function

A number after the abbreviation indicates the system ID.
Following that would be L1,2,3... Indicating the level the
process is on An example:
qi1-L1 Indicates an input quantity belonging to system1 on
Level 1.

The reason for this is that with Vensim we no longer have to
be cryptic. We can tell our stories in the models. Attached
is a pdf file i did with the Abbott-Marken model to
Illustrate.

A few notes: It seems to me our models should have
_specific_ CV's noted in them as such. You can't always
assume the Perceptual signal _is_ the CV. Going throughout
he logic in this model shows why. I think it also shows how
we can be a bit "spotty" in our thinking. You need to go
around the loop several times to "play" out the story.
Further refining and defining the variables would help

MarkenAbbott2.mdl (66 Bytes)

MarkenAbbott2.2mdl (67 Bytes)

[Abbott_Bruce]

[From Bruce Abbott (980909.0635 EST)]

Marc Abrams (980909.0353) --

lower case letters _only_ will be used to designate the
elements. Why?, It saves you from having to use the shift
key :-). What can I tell you. I am a lazy typist Upper
case will be used to designate a Function.

r: Reference Signal
p: Perceptual Signal
Cf: Comparator
e: Error Signal
Of: Output Function
qo: Output Quantity
CV: Controlled Variable
d: disturbing quantity
Df: Disturbance Function
qi: Input Quantity
If: Input Function

To be consistent, "CV" should be lower case. I would drop it altogether; it
is ambiguous and in any case is already represented, either as qi (if what
you mean by "CV" is the environmental variable whose perception is to be
controlled) or as p (the controlled perception). Also, you stated how
important it is to maintain the distinction between environmental quantities
and system signals. This distinction seems to be provided by using "q" as
the first letter of a quantity symbol; to be consistent d should be qd.

The reason for this is that with Vensim we no longer have to
be cryptic. We can tell our stories in the models. Attached
is a pdf file i did with the Abbott-Marken model to
Illustrate.

Attached to the post I received were two files, MarkenAbbott.mdl and
MarkenAbbott.2mdl. (No pdf file.) When I checked Eudora's attachment
directory, I found MarkenAbbott.mdl only. (Perhaps MarkenAbbott.mdl was
split for transmission and recombined? The .2mdl is not a valid DOS
extension, but I would think this would have been truncated to .2md; if
truncated to .mdl it would have overwritten the first file.)

Comments About MarkenAbbott.mdl and the State Trooper Scenario

The model presented is Rick's minor modification of my "control of behavior"
(COB) VenSim simulation, but with added comments to suggest a relationship
between the model and the State Trooper (ST) scenario being discussed by
Rick and Bruce Gregory. Unfortunately, there is not a nice one-to-one
correspondence between COB and ST, so the suggested mapping of ST onto COB
fails.

In ST, the state trooper monitors the speeds of vehicles passing his
position; if a car is found to be exceeding the speed limit by a sufficient
amount, the state trooper pursues the offending vehicle and signals to the
driver to "pull over" by means of the traditional signal: lights and siren.
Most drivers will pull over to the edge of the road and stop when they
perceive such a signal immediately behind them.

Clearly the state trooper is attempting to control the speeds of the
vehicles (as measured by radar, for example). He may succeed in doing so
simply by being visible to passing motorists, who upon seeing the trooper's
state police car may slow down (if they are speeding) to avoid getting a
speeding ticket. He may succeed in doing so by being difficult to perceive
while monitoring for speeders and highly visible to passing motorists while
ticketing motorists who have been caught. In both cases the visible trooper
disturbs a motorist perception (something like the liklihood of being pulled
over and given a ticket) when combined with peceptions of current speed and
current speed limit. Seeing the state trooper while driving significantly
over the speed limit yields a perception of a high probability of receiving
a ticket, which the motorist can reduce to a low (reference) level by
reducing speed.

If the motorist has already been selected for ticketing, then the state
trooper attempts to control the speed of the motorist's vehicle by closely
following it with lights and sirens going. At this point a higher-level
system in the motorist may act by resetting the reference for vehicle speed
to zero, since failing to do so may be judged likely to produce a severe
disturbance of several other controlled perceptions of importance to the
motorist, such as his personal freedom and financial solvency. However,
this scenario does not match the MarkenAbbott.mdl control-of-behavior model,
which lacks any higher levels and does not alter the motorist's reference in
any way as a result of the applied disturbance.

For the state trooper scenario to fit the MarkenAbbott COB model, the
trooper might get directly in front of the speeding motorist and then begin
to apply the brakes while preventing the motorist from passing. This action
would disturb a variable the motorist was controlling (distance between his
vehicle and any vehicle in front). To correct for this disturbance, the
motorist would have to apply his brakes, thus maintaining a safe distance
between his front bumper and the trooper's rear bumper. To successfully
maintain this distance near reference, the motorist would have to slow at a
rate matching the deceleration of the trooper's vehicle, and ultimately come
to a stop. In this way the trooper controls the speed of the motorist's
vehicle by disturbing a variable (distance to vehicle in front) that the
motorist is successfully controlling.

Regards,

Bruce

[Marc_Abrams5]

From [ Marc Abrams (980909.0809) ]

[From Bruce Abbott (980909.0635 EST)]

Geez, that was quick

r: Reference Signal
p: Perceptual Signal
Cf: Comparator
e: Error Signal
Of: Output Function
qo: Output Quantity
CV: Controlled Variable ( Still up for grabs )
qd: disturbing quantity ( Changed in accordance with BA's

recommendation )

Df: Disturbance Function
qi: Input Quantity
If: Input Function

To be consistent, "CV" should be lower case. I would drop

it >altogether; it is ambiguous and in any case is already

represented, either as qi (if what you mean by "CV" is the
environmental variable whose perception is to be
controlled) or as p (the controlled perception).

Thats precisely why I did not leave it out :-). I wasn't
sure whether a cv should be treated as a function ( meaning,
a cv could have multiple components ) or as a quantity or
signal. By CV I mean an environmental variable(s) whose
perception is to be controlled. All functions are listed
because they may contain multiple components.

Also, you stated how important it is to maintain the
distinction between environmental quantities and system
signals. This distinction seems to be provided by using "q"
as the first letter of a quantity symbol; to be consistent

d >should be qd.

Seems reasonable to me. Done.

The reason for this is that with Vensim we no longer have
to be cryptic. We can tell our stories in the models.
Attached is a pdf file i did with the Abbott-Marken model

to

Illustrate.

Sorry 'bout that at 3:00 am I just attached the model file
without converting it to PDF. So you have a Vensim Model
file. Attached is the pdf file.

Comments About MarkenAbbott.mdl and the State Trooper
Scenario

The scenario was a simple attempt to show the viability of
telling a story with a model by using a notation and some
common sense variable names. It was _not_ intended as the
last word on the model. But I am interested in your
critique because _this_ is _one_ of the ways we can talk
about a model

The model presented is Rick's minor modification of my
"control of behavior" (COB) VenSim simulation, but with
added comments to suggest a relationship
between the model and the State Trooper (ST) scenario
being discussed by Rick and Bruce Gregory. Unfortunately,
there is not a nice one-to-one correspondence between >COB

and ST, so the suggested mapping of ST onto COB

fails.

OK, I don't disagree. That was what my "spotty" comment was
about. Lets take a look

In ST, the state trooper monitors the speeds of vehicles
passing his position; if a car is found to be exceeding the
speed limit by a sufficient amount, the state trooper

pursues >the offending vehicle and signals to the driver to
"pull over" >by means of the traditional signal: lights and
siren.

Most drivers will pull over to the edge of the road and

stop >when they perceive such a signal immediately behind
them.

Clearly the state trooper is attempting to control the

speeds >of the vehicles (as measured by radar, for example).
He >may succeed in doing so simply by being visible to
passing >motorists, who upon seeing the trooper's state
police car >may slow down (if they are speeding) to avoid
getting a

speeding ticket. He may succeed in doing so by being
difficult to perceive while monitoring for speeders and

highly >visible to passing motorists while ticketing
motorists who >have been caught. In both cases the visible
trooper

disturbs a motorist perception (something like the

liklihood of >being pulled over and given a ticket) when
combined with >peceptions of current speed and current speed
limit.

So far your story line is following the model. I could have
used _your_ words instead of mine but the model would stay
the same.

Seeing the state trooper while driving significantly
over the speed limit yields a perception of a high

probability >of receiving a ticket, which the motorist can
reduce to a low >(reference) level by reducing speed.

Ah, Here comes a potential sticking point. Since you did not
make this model ( i.e. the State trooper scenario ) and I
did not,we are both _assuming_ that the driver is
_controlling_ for "not getting a ticket" what if he were
controlling for "getting to the hospital quickly because my
wife is giving birth"

If the motorist has already been selected for ticketing,

then >the state trooper attempts to control the speed of the

motorist's vehicle by closely following it with lights and

sirens >going. At this point a higher-level

At this point your model critique ends and your conjectures
and speculations begin. Want to extend the conversation,
extend the model.

system in the motorist may act by resetting the reference

for >vehicle speed to zero, since failing to do so may be
judged >likely to produce a severe disturbance of several
other >controlled perceptions of importance to the

motorist, such as his personal freedom and financial
solvency.

A very nice story with _no_ backbone. It very well might be
true. It could be equally false. Nice story nothing more.

However, this scenario does not match the
MarkenAbbott.mdl control-of-behavior model,
which lacks any higher levels and does not alter the
motorist's reference in any way as a result of the applied
disturbance.

Exactly, which invalidates your story. Not Rick's. Rick's
story has no higher levels. Rick was simply pointing out
that the trooper can and does control one's behavior. The
model _clearly_ shows this. This model does not support
different _contingencies_ based upon decisions that _could_
be made with regard to these events. Those are conjectures
and speculations on your part.

For the state trooper scenario to fit the MarkenAbbott COB
model, the trooper might get directly in front of the

speeding >motorist and then begin to apply the brakes while
preventing >the motorist from passing.

Why do you say this? Where in the model does it show the
driver controlling for something that would _only_ allow a
_physical_ barrier to stop him.

This action would disturb a variable the motorist was
controlling (distance between his vehicle and any vehicle

in >front).

How do you know what the motorist is controlling for? My
story is just as good and _invalid_ as yours Again,
another reason to _spell_ out the CV.

Spelling out the CV provides the _purpose_ of the model.
_Everything_ we do, we do to either gain or maintain ( or
try to ) control of our CV(s).

To correct for this disturbance, the
motorist would have to apply his brakes, thus maintaining a
safe distance between his front bumper and the trooper's
rear bumper. To successfully maintain this distance near
reference, the motorist would have to slow at a rate
matching the deceleration of the trooper's vehicle, and
ultimately come to a stop. In this way the trooper

controls >the speed of the motorist's vehicle by disturbing
a variable

(distance to vehicle in front) that the motorist is

successfully >controlling.

Nice story. But without any foundation in the model.
_Nothing_ you have said is defined that way in the model. At
least not in my story Could you please redo my story to
reflect _your_ story? Using the _same_ variables that are
currently being used.

Actually I'm not real interested in either of our stories
:-). I was just using it as an example and I think I showed
why it's important to make a story out of it. It will help
focus the discussions and save a lot of bandwidth

Marc

MarkenAbbott2.pdf (66 Bytes)

[Bruce_Gregory]

[From Bruce Gregory (980909.0935 EDT)]

Bruce Abbott (980909.0635 EST)

Thanks for the very detailed, and very clear, description of the situation I
was trying to describe.

Bruce Gregory

[Marc_Abrams5]

From [ Marc Abrams (980909.0958) ]

[From Bruce Gregory (980909.0935 EDT)]

Bruce Abbott (980909.0635 EST)

Thanks for the very detailed, and very clear, description

of >the situation I was trying to describe.

Hi Bruce, What about the taxonomy?, and the story plus
notation way of laying out a model.

Marc

[R_Marken]

[From Rick Marken (980909.0810)]

Bruce Abbott (980909.0635 EST)--

To be consistent, "CV" should be lower case. I would drop it
altogether

I agree. Let's stick with qo.

Unfortunately, there is not a nice one-to-one correspondence
between COB and ST, so the suggested mapping of ST onto COB
fails.

I agree with this as well.

In ST, the state trooper monitors the speeds of vehicles passing
his position; if a car is found to be exceeding the speed limit
by a sufficient amount [he pulls it over]... Clearly the state
trooper is attempting to control the speeds of the vehicles...

It sounds like the trooper is controlling for the logical
relationship: if the car speeding then pull it over. The
trooper is not really controlling speed; he doesn't act to
change the motorists' speed, except when he pulls them over
to make his percception of the logical relationship TRUE.

For the state trooper scenario to fit the MarkenAbbott COB
model, the trooper might get directly in front of the speeding
motorist and then begin to apply the brakes while preventing
the motorist from passing.

Yes. The first thing the trooper has to do to fit the COB scenario
is want to control a behavior (speed) of the motorist. Sometimes
police do want to control speed; I've seen a trooper weave in
front of traffic on the freeway to keep the traffic moving at a
particular speed; the trooper doing this fits the COB scenario's
model of the "controller".

This action would disturb a variable the motorist was controlling
(distance between his vehicle and any vehicle in front).

Correct. The trooper controls speed by distrubing a perception
the driver is controlling; probably the driver's perception of
the distance between him/herself and another vehicle.

To correct for this disturbance, the motorist would have to
apply his brakes, thus maintaining a safe distance between
his front bumper and the trooper's rear bumper.

Right. Let's assume (as you do) that the trooper is controlling
the speed of one car in this way. The surprising (to me) result
of the COB modelling effort is that it shows that the trooper
can control this car's speed (keeping it at, say, 10 mph) even
if the driver of the car is continuously changing his/her reference
for the perception s/he is controlling (a safe distance between
his front bumper and the trooper's rear bumper.

Best

Rick

···

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

[Bruce_Gregory]

[From Bruce Gregory (980909.1115 EDT)]

Rick Marken (980909.0810)

It sounds like the trooper is controlling for the logical
relationship: if the car speeding then pull it over. The
trooper is not really controlling speed; he doesn't act to
change the motorists' speed, except when he pulls them over
to make his perception of the logical relationship TRUE.

I'm breaking my vow not to agree with you. This is a nice point that
resolves something that has been bothering me for a while. Thanks.

Bruce Gregory

[Abbott_Bruce]

[From Bruce Abbott (980909.1020 EST)]

Rick Marken (980909.0810) --

Right. Let's assume (as you do) that the trooper is controlling
the speed of one car in this way. The surprising (to me) result
of the COB modelling effort is that it shows that the trooper
can control this car's speed (keeping it at, say, 10 mph) even
if the driver of the car is continuously changing his/her reference
for the perception s/he is controlling (a safe distance between
his front bumper and the trooper's rear bumper.

That's because, for the trooper, the motorist's varying reference for
following distance appears merely as a disturbance to the trooper's
perception of the motorist's speed. So long as they aren't too fast or
violent, disturbances pose no special problems for a control system -- the
trooper compensates just as he would for any disturbance to his controlled
perception of the motorist's speed.

Regards,

Bruce

[Bill_Powers1]

[From Bill Powers (980909.0814 MDT)]

Marc Abrams (980909.0353)--

Anyway, I am going to use Bill's notation from his Vensim
Control model, & Tim's notation from his "finger" diagram.
Bill makes a distinction between "quantities" and "signals".
Those distinctions are not always consistently applied by
others, they should be.

lower case letters _only_ will be used to designate the
elements. Why?, It saves you from having to use the shift
key :-). What can I tell you. I am a lazy typist Upper
case will be used to designate a Function.

r: Reference Signal
p: Perceptual Signal
Cf: Comparator
e: Error Signal
Of: Output Function
qo: Output Quantity
CV: Controlled Variable
d: disturbing quantity
Df: Disturbance Function
qi: Input Quantity
If: Input Function

To make this still more systematic (thus requiring even less memorization)
we can use the convention common in the sciences that the symbol indicates
the major category and the subscript the subcategory. In the model, one
major category is Function, and the subscript designates _which_ category:
Fi, Fc, Fo, Fe, Fd. Capitalizing the first letter and making the second one
lower-case is a good way to imitate subscripts.

The distinction between signal (information carrier inside the system) and
quantity (energy-carrying physical variable outside the system) follows the
same convention: s or q to designate signal or quantity, i,p,e,o, and d to
designate input, perception, error, output, and disturbance as appropriate.
I tend to agree with Marc about writing qi instead of Qi, and sp instead of
Sp. Notice that as given in Marc's table, the designation of "signal" is
dropped. If it's not a quantity (environmental) it must be a signal? And
finally, d ought to be qd if we're also going to use qi and qo.

A number after the abbreviation indicates the system ID.
Following that would be L1,2,3... Indicating the level the
process is on An example:
qi1-L1 Indicates an input quantity belonging to system1 on
Level 1.

In previous work with hierarchical systems I just used letters to designate
the system: spb3, for perceptual signal in system b of level 3. This
translates directly into matrix notation for Pascal or C programming, very
handy.

By the way, I kept seeing file extensions like .2mdl in my own directories.
Does Vensim do something funny with these extensions to keep track of
versions or something? And my immediately-following question is, can I turn
this "feature" off? Long file names are just not universal yet.

···

===========================================================
There's another subject to cover here, while we're talking about
conventions. Way back in 1955, John Truxall wrote "Control System
Synthesis", in which he decided to use "signal flow diagrams" instead of
"block diagrams." A block diagram is the kind we use in PCT; a signal flow
diagram is something like what is used in system dynamics simulators like
Vensim, but not exactly.

I say not exactly because the signal flow diagram is actually translatable
directly into a block diagram, while a Vensim diagram is not. The problem
is with how "mechanisms" are represented. Consider a mechanism that
receives an input signal x and emits a signal y proportional to the
time-integral of the input signal. In a block diagram, we can represent
this as

                 -------
          x --->| INTEG |----> y
                 -------

The only difference in a signal-flow diagram is that the box is omitted:

                  INTEG
           x -----------------> y

Both of these diagrams show what is called a "transfer function" between an
input variable and an output variable. The label, here "INTEG" indicates
the kind of transformation that exists between x and y, transforming the
former into the latter: a time integration.

Modeling can be confusing enough without notations that make meanings
unclear. In Vensim diagrams, we have this notation for y = log(x):

             x -------------------> y

You can see the difficulty. What would be the notation for y = 3x^2 + 32?

             x -------------------> y

or for y = x if x > 2 otherwise y = 2?

             x -------------------> y

The only way to see HOW y depends on x is to click on the "Y=X2" button and
then click on y, which brings up the window holding the equation.

That's really a minor matter. In our modeling, likely as not we'd end up
writing

                      ----
              qi --->| Fi | ------> p
                      ----
or in signal-flow form,

                         Fi
              qi ------------------> p

because we don't know the actual form of the input function. But in either
case, the diagram would retain an indication that some actual physical
device is located between qi and p, receiving an infuence from qi and
converting it continuously into a value of p. The physical device is some
neural network, or a circuit with transistors and other components, or
something like that.

In Vensim, all we have are the two variables, the input and the output, and
hidden away behind the scenes, the specific equations relating them. For a
model of an electronic circuit or a brain, this is not really what we want
to see, esthetically or mnemonically. However, it is exactly what we want
to see when we're talking about the _environment_ of a control system!

In the environment, we measure some variables at specific places and other
variables at other specific places. Empirically, we find that one variable
measured in one place depends on the values of other variables measured in
other places. What we DON'T see are transistors or neural nets explaining
how one variable affects another. Acceleration is proportional to force,
but there isn't any transistor or neural network turning force into
acceleration.There's just an equation in the background telling us what the
relationship is, without telling us what it making it exist.

So the Vensim-style diagram is a good way to represent properties of the
environment, while the block diagram is a good way to represent processes
inside the brain or other control system. It would be very nice if we could
somehow switch notations when speaking about the controlling system that
handled signals transformed by neural functions into other signals, versus
physical quantities that "just are" affected by other quantities in ways we
can describe with equations.

All that's just something to mull over. No action needed now.

Best,

Bill P.

[Abbott_Bruce]

[From Bruce Abbott (980909.1045 EST)]

Marc Abrams (980909.0809) --

Bruce Abbott (980909.0635 EST)

A very nice story with _no_ backbone. It very well might be
true. It could be equally false. Nice story nothing more.

. . .

How do you know what the motorist is controlling for? My
story is just as good and _invalid_ as yours Again,
another reason to _spell_ out the CV.

These are, as you say, just stories -- hypotheses about what the state
trooper and the motorist are controlling, and the mechanism through which
this control might take place. A first step in relating a given scenario to
a particular model is to check whether the model could reasonably be viewed
as consistent with the scenario given. Is there a correspondence of
elements? The original state trooper scenario fails to map properly onto
the elements of the COB model, and for this reason COB must be rejected as a
potentially valid model of that scenario. I suggested another scenario that
would map properly onto the COB model; I was in no way suggesting that this
scenario constitutes an actual, validated explanation of any given state
trooper's or motorist's behavior.

Nice story. But without any foundation in the model.
_Nothing_ you have said is defined that way in the model. At
least not in my story Could you please redo my story to
reflect _your_ story? Using the _same_ variables that are
currently being used.

You'll have to explain what you want me to do. Defined _what_ way in the
model? How could I redo your story to "reflect" my story? I have no idea
what that means. Your story does not map onto the model. The reason I
proposed an alternate "story" was to provide one that does, just to show
what one might look like.

Regards,

Bruce

[Marc_Abrams5]

From [ Marc Abrams (980909.1129) ]

[From Rick Marken (980909.0810)]

OK, I've had it :-), Models at 90 paces

_what_ have you guys been smoking this morning

This Marken-Abbott model is taking on a life of it's own.
Sorta like the coercion stuff.

Bruce Abbott (980909.0635 EST)--

To be consistent, "CV" should be lower case. I would drop
it altogether

I agree. Let's stick with qo.

Stick with Output quantity? for what? A CV could be and is
_parts_ of a number of things. The CV should be _explicitly_
stated in _each_ model because the CV _is_ the plot for
_every_ PCT model. It's the reason the model is done. To see
what is trying to be gained or maintained. _Everything else
supports that effort. Right now it always gets real fuzzy as
to _what_ the cv is. Just check out your dialog on the
"intentions" of the trooper. _Where_ is that coming from?
His qo? I don't think so. Where in the model is the troopers
intentions _explicitly_ made clear. I'll tell you. In each
of your heads :-).

Unfortunately, there is not a nice one-to-one
correspondence between COB and ST, so the suggested
mapping of ST onto COB fails.

I agree with this as well.

Great. If you agree, why do you continue to use the model
to point out your stories. Is the model a disconfirmation of
what you think? Rick, you said the model compliments your
demo. Are you retracting that statement now? If so why?

In ST, the state trooper monitors the speeds of vehicles
passing his position; if a car is found to be exceeding

the >>speed limit by a sufficient amount [he pulls it
over]... >>Clearly the state trooper is attempting to
control the >>speeds of the vehicles...

It sounds like the trooper is controlling for the logical
relationship:

Sounds like? Is this your old trusted intuition at work
again Rick. How does the model specs back this claim up?

if the car speeding then pull it over. The
trooper is not really controlling speed; he doesn't act to
change the motorists' speed, except when he pulls them
over to make his percception of the logical relationship

TRUE.

Nonsense. He can pull them over for _anything_ and the
motorist can _perceive_ it could be for anything _but_ that
reason. Again, where is the cv?

For the state trooper scenario to fit the MarkenAbbott
COB model, the trooper might get directly in front of the
speeding motorist and then begin to apply the brakes while
preventing the motorist from passing.

Yes. The first thing the trooper has to do to fit the COB
scenario is want to control a behavior (speed) of the
motorist.

Right, what is the troopers cv? Since it is nor _explicitly_
stated in the model, lets take a vote. That seems to be
the only fair way. Rick would you like to count the ballots?

Sometimes police do want to control speed; I've seen a
trooper weave in front of traffic on the freeway to keep

the >traffic moving at a particular speed; the trooper doing
this fits >the COB scenario's model of the "controller".

Yes and sometimes they don't. Which model does that fit?

This action would disturb a variable the motorist was
controlling (distance between his vehicle and any vehicle

in >>front).

Correct. The trooper controls speed by distrubing a
perception the driver is controlling; probably the driver's
perception of the distance between him/herself and another
vehicle.

and if he weren't? What else could he possibly be
controlling for? Give me a break

To correct for this disturbance, the motorist would have

to

apply his brakes, thus maintaining a safe distance
between his front bumper and the trooper's rear bumper.

Right.

The model does not show this.

Let's assume (as you do) that the trooper is controlling

the >speed of one car in this way. The surprising

(to me) result of the COB modelling effort is that it shows
that the trooper can control this car's speed (keeping it

at, >say, 10 mph) even if the driver of the car is
continuously >changing his/her reference for the perception
s/he is >controlling (a safe distance between

his front bumper and the trooper's rear bumper.

Why is this surprising, In _your_ head ( not in the model )
CV's seem to change because they fit your story line better.
Where is the logical justification in _this_ model for
_this_ story?

Marc

[Marc_Abrams5]

From [ Marc Abrams (980909.1213) ]

[From Bruce Abbott (980909.1045 EST)]

Bruce I was simply _using_ the model as a way of _showing_
the notation and telling a story rather then simply having
variables named "r2" and "output". The model did not fit the
story. In fact it did not meet _any_ story told and talked
about by Rick and Bruce Gregory except what was in their
heads. My post _was not_ _is not_ and Guaranteed _won't_ be
about the model. Bill came back with the first reasonable
reply to my suggestion about the taxonomy. _That_ is what my
post was about, _Nothing_ else. You told me what you
disliked. Does that mean you liked the other notations and
_A_ story line. What about making the CV explicit for every
model?

Marc

[Bruce_Gregory]

From [Bruce Gregory (980909.1602 EDT)]

Marc Abrams (980909.0958)

Hi Bruce, What about the taxonomy?, and the story plus
notation way of laying out a model.

Seems perfectly reasonable to me. Note Rick's recent post as a way of
answering some of the questions you raised with Bruce.

Bruce Gregory

[R_Marken]

[From Rick Marken (980909.1310)]

Me:

I agree. Let's stick with qo.[for controlled variable]

Marc Abrams (980909.1129)

Stick with Output quantity?

Oops. Make that qi. Must be that stuff I'm smoking

The CV should be _explicitly_ stated in _each_ model
because the CV _is_ the plot for _every_ PCT model.

The CV is clearly stated in the _model_; the controllers
CV is the variable called "i2"; the controllee's CV
is the variable called "input".

Just check out your dialog on the "intentions" of the trooper.
_Where_ is that coming from?

It comes from trying to describe what a trooper and a driver
_might_ be controlling that would make the situation equivalent
to the one modelled. I think we came up with one: the trooper's
(controller's) CV is speed (the controllee's output); the
driver's (controllee's) CV is distance from the trooper.

Bruce A.

Unfortunately, there is not a nice one-to-one correspondence
between COB and ST, so the suggested mapping of ST onto COB
fails.

Me:

I agree with this as well.

Marc:

Great. If you agree, why do you continue to use the model
to point out your stories.

The "story" the model explains is the trooper controlling
the speed of the driver who is controlling his distance from
the trooper.

Is the model a disconfirmation of what you think?

No.

Rick, you said the model compliments your demo. Are you
retracting that statement now?

No.

Me:

It sounds like the trooper is controlling for the logical
relationship:

Marc:

Sounds like? Is this your old trusted intuition at work
again Rick. How does the model specs back this claim up?

The trooper was described as waiting to give a ticket to
speeders. This is not a description of a trooper controlling
speed (at least, not directly); this is a description of a
trooper controlling a logical relationship: if speed then ticket
else no ticket. The model has nothing to do with it; I'm just
trying to guess what the person telling the trooper "story"
might be thinking of as the trooper's controlled variable. I
guess I'm saying that the control of behavior model is not a
good model of the "trooper giving tickets" version of the
trooper story. The control of behavior model fits Bruce Abbott's
version of the trooper story best; the trooper controls the
speed of a driver who is controlling his distance from the trooper.

Me:

The trooper is not really controlling speed; he doesn't act
to change the motorists' speed, except when he pulls them
over to make his percception of the logical relationship TRUE.

Marc:

Nonsense. He can pull them over for _anything_ and the
motorist can _perceive_ it could be for anything _but_ that
reason. Again, where is the cv?

The trooper's cv is the logical relationship. If the trooper
is controlling this variable he is not really controlling
speed.

Me:

The first thing the trooper has to do to fit the COB
scenario is want to control a behavior (speed) of the
motorist.

Marc:

Right, what is the troopers cv?

Bruce A. and I are suggesting that the COB model applies to
the situation where the trooper's cv is the _speed_ of the
driver's car.

Me:

Sometimes police do want to control speed...

Marc:

Yes and sometimes they don't. Which model does that fit?

The one where the trooper _does_ want to control the driver's
speed.

Me:

The trooper controls speed by distrubing a perception the
driver is controlling; probably the driver's perception of
the distance between him/herself and another vehicle.

Marc:

and if he weren't?

If _who_ weren't? If the trooper were not controlling the
driver's speed then the trooper's behavior would not be
fit by the COB model. If the driver were not controlling his
perception of distance to the trooper then the trooper could
not control the driver's speed by varying his distance from
the driver.

Bruce A.

To correct for this disturbance, the motorist would have
to apply his brakes, thus maintaining a safe distance
between his front bumper and the trooper's rear bumper.

Me:

Right.

Marc:

The model does not show this.

It shows precisely this. The motorist applying his brakes
(or speeding up, if necessary) is precisely equivalent to
the controllee in the COB model varying his output to
compensate for the controller produced disturbances to his
input.

Me:

The surprising (to me) result of the COB modelling effort
is that it shows that the trooper can control this car's
speed (keeping it at, >say, 10 mph) even if the driver of
the car is continuously changing his/her reference for the
perception s/he is controlling

Marc:

Why is this surprising,

OK. I'll lay out my fallacious reasoning for you;-)

The control model says that

o = r- kd

A control system's output (o) is a function of reference
(r) and disturbance (d) variations. So this equation tells
me that I can control o (get the output I want) by varying
d (the disturbance to the variable, cv, the system is
controlling). But it looks like this is true only when r is
constant! I thought that if r varies, I could _not_ get the
output I wanted by just varying d. This was my mistake!!

As Bruce Abbott points out, r just functions as another
additive disturbance from my point of view; so I can vary
d as necessary to produce the o I want _while_ compensating
for the changes in r. I suppose I should have been able to
see this just by looking at the formula, but I didn't. The
modeling _and_ (especially) the experimnetal demo really
helped me understand how this actually works.

Best

Rick

···

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