# Program Control

**URL:** <http://discourse.iapct.org/t/program-control/9146>\
**Category:** CSG1994\
**Created:** [June 15, 1994, 4:00pm UTC](http://discourse.iapct.org/t/program-control/9146 "1994-06-15T16:00:21Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Marken\_Richard\_S1](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/m/977dab/32.png) [@Marken\_Richard\_S1](http://discourse.iapct.org/u/Marken_Richard_S1)\
**Post date:** [June 15, 1994, 4:00pm UTC](http://discourse.iapct.org/t/program-control/9146/1 "1994-06-15T16:00:21Z")

</div>

[From Rick Marken (940615.0900)]

Bob Clark (940614.2205 EDT) --

> Your demonstration of controlling programs by simply pressing buttons  
> was neat!

Thanks 🙂

> YOU (not some modelled version of you), pushed a button to select the  
> program to be displayed.

Yes.

> YOU monitored (observed) the perceptions composing the displayed sequence of  
> numbers.

Yes.

> YOU compared these perceptions to the perceptions as YOU imagined them.

I would say that I compared these perceptions to a reference for what I  
wanted them to be -- at least, that's what the model says I was doing; I was  
only aware of keeping the program (perception) happening. I was not imagining  
anything (well, this kind of experiment can get a bit boring so I suppose I  
might have been imagining \_something\_ but it sure wasn't programs;-).

> This process could be described as: "a comparison of this [sequence of  
> numbers]" with a remembered (imagined) preselected [sequence of  
> numbers].

Yes. Except that in both cases it is neural signals (not actual sequences)  
that are compared and the perceptual signal does not represent a particular  
sequence; it represents a \_program\_. So two very different sequences could  
still be examples of the same program, which was "if odd then \>5 else =\< 5".  
So both of the following sequences are the "same" at the program level:

1 10; 2 4

8 3; 3 9

> If YOU perceive an exact match, zero error, hence no "disturbance,"

> If YOU perceive a mismatch, there is an error, YOU perceive a "disturbance,"

You are making "Martin's mistake". What I perceive is the state of the  
(program) perception; if that state is not at the intended level then it's  
not; but the system controlling the program perception doesn't know why the  
perception is not at the intended level; it could be due to the effects of  
the disturbing variable but it could also be due to my own output (pushing  
the button) or it could be due to \_both\_ disturbance and output at the same  
time. The disturbance (the disturbing variable or it's effect on the  
controlled perception) cannot be perceived by the system controlling the  
disturbed perception.

> YOU appear to have controlled your perception of a sequence of numbers by  
> "generating a program (sequence of perceptions) of outputs used to push the  
> button."

Not at all. I have controlled the perception of a \_program\_ of numbers  
by generating outputs that are opposed to a disturbance that changes the  
program. There is no program of button press outputs; my outputs, o, simply  
mirror the disturbance variable, d, so that o = -d. The relationship between  
o and d is not a program (though it could be \_described\_ as one --ie.  
"if o then -d"); but the relationship between o and d is really just a  
functional relationship that results from the operation of a negative  
feedback perceptual control loop.

> How could YOU manage to "push a button" without generating a "program  
> of [button-pushing] outputs?"

Here is a model of what's going on:

S----\> |f| -- \> p --\>|c|\<--r

> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\>  
> \<-------------o\<-----|

d

S is the sequence of numbers occuring out there on the computer screen. The  
sequence goes through a perceptual function, f, (in me) that determines  
whether this sequence is consistent with the program "if odd, then \>5 else  
=\< 5". The function f is the crucial part of the model; I imagine that it's  
output is binary, being 1 as long as S is consistent with the program and 0  
otherwise. So p (the perceptual signal that indicates whether or not the  
program is occurring) is either 1 or 0 . The reference signal is set to 1 (if  
I want to see the program) or 0. When the program perception, p, doesn't  
match the reference signal there is an output -- ie. a button press. The  
actual sequence, S, that appears on the screen depends on both the  
disturbance and the output. In my experiment both are binary variables; the  
distrubance is either 1 or -1 and the output is either 1 (button not pressed)  
or -1 (button pressed). The product o x d determines whether or not the  
sequence, S, is being generated by the program "if odd, then \>5, else =\<5" or  
not. If o x d = 1 then S is being generated by the program; if o x d = -1  
then it is not.

Actual implementation of this model would probably require some integration  
of variables in order to achieve the proper dynamics. But it should work --  
and when it does work, it will be keeping the perceptual signal equal to the  
reference signal (approximately) and it will be doing so by generating  
outputs that oppose any changes in the disturbing variable. Behavior (in this  
case, the behavior of producing a particular program of numbers on the  
screen) is the control of perception.

I have not yet built this model; I thought that it might be difficult to  
build the function f that detects programs. But, now that I think about it,  
it's probably pretty easy to just cluge it up. So maybe I will build this  
just to show how a control system can control a perceptual variable that  
happens to represent a complex environmental event -- a program.

> Where do you put all this within HPCT?

At the program level. Obviously, if I actually built the simulation I would  
not be simulating the lower level perceptual functions that produce the  
perceptions that go into the program detection function. So my cluge "program  
detection" function, f, would unquestionably NOT be perceiving the occurance  
of the program the way people do. But I think that would be fine; our line  
control models don't perceive line position the way people actually do it  
either.

> And how do YOU account for YOUR independence?

God just made me that way 😉

Best

Rick

---

<div class="post-metadata">

**Author:** ![R\_Marken](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/r/8797f3/32.png) [@R\_Marken](http://discourse.iapct.org/u/R_Marken)\
**Post date:** [July 26, 1998, 7:05pm UTC](http://discourse.iapct.org/t/program-control/9146/2 "1998-07-26T19:05:42Z")

</div>

[From Rick Marken (980726.1110)]

Bruce Gregory (980725.0836 EDT)

> It appears that when you adopt a Plan, the level that activated  
> the plan no longer experiences the error that it did before the  
> Plan was adopted, even though perception that the upper level  
> goal has been reached may be many years away.

Yes. I'm a list-maker myself and I find that making these kinds  
of Plans can be very stress-reducing. But I don't think that making  
these kinds of Plans is an example of actually controlling a  
program perception. I think what I am doing when I make these  
Plans is controlling an \_imagined\_ perception of a program: first  
I'll pay all the bills, then I'll work on project X at work and  
then I'll solve world hunger. Doing this gives me the sense that  
I are working to achieve whatever higher level goal (like "living  
a satisfying life") that I am trying to achieve by adopting the  
Plan. But I know that when I actually get down to trying to control  
for the Plan (program), things are not as they were when I made  
the Plan; I might carry out the "paying bills" program and then  
find that project X has been temporarily shelved and sex scandals  
replaced world hunger as the most immediate policial concern.

My point is that "adopting a Plan" is probably an imagination  
phenomenon. Controlling a program is a very different phenomenon;  
it is the real-time process of controlling a program perception  
(like the recipe for apple pie or the process of solving a  
differential equation).

> This seems to me at least a very good reason for paying attention  
> to the program level, as MGP do.

I think it's important to pay attention to the program level because  
people \_do\_ seem to control program perceptions. I think MGP did  
pay attention to the program level of their \_own\_ perceptions;  
they saw \_all\_ behavior as a process of carrying out a particular  
program -- TOTE. What they didn't see was that the people they were  
observing were controlling \_program perceptions\_. This is some-  
thing they could not possibly have seen because they did not have  
PCT. In order to determine whether or not a person is controlling  
a program perception it is necessary to \_test\_ to determine whether  
a program is \_under control\_. This is basically what I did in my  
prgram control study; I tested (by introducing disturbances) to  
determine whether a person would act to maintain the perception  
of a particular program.

It's necessary to test for program control because it can \_look  
like\_ a person is controlling for a particular program when they  
are \_not\_. For example, a person might be controlling for seeing  
the sequence 3,7,6,2. This sequence is consistent with the  
program:

if N\>5 then N = Even else N = Odd

so an observer could (incorrectly) conclude that this person  
is controlling this program, In fact, the person is only  
controlling for the sequence 3,7,6,2, a fact that would become  
obvious when the observer disturbs the sequence and have 1 follow  
2; the number 1 at that point is consistent with the program but  
a violation of the sequence. Since the person is controlling the  
sequence he will try to correct the "error"; if he were controlling  
the progran there would be no error.

By the way, I thought of a conventional research study that  
seems to demonstrate control of program perception; it is the  
study of "problem solving set" (I forget the name of the person  
who did it). He had people learn to solve water jar problems.  
First, he had people solve an initial set of problems that could  
all be solved by the same \_algorithm\_ (program): for example,  
the algorithm might be "fill jar A, remove jar C amount from  
jar A, fill jar B and add to jar A". Once people had learned to  
solve the problem using this algorithm (the capacities of jars  
A, B and C were always different during the learning trials)  
they was very reluctant to give it up (this was called problem  
solving set). What people seem to have been "set" on in this study  
was perceiving a particular \_program\_ -- the algorithm that  
solved the initial set of problems.

Best

Rick

> **···**
>
> ---
> 
> Richard S. Marken Phone or Fax: 310 474-0313  
> Life Learning Associates e-mail: rmarken@earthlink.net  
> [http://home.earthlink.net/~rmarken/](http://home.earthlink.net/~rmarken/)

---

<div class="post-metadata">

**Author:** ![Bruce\_Gregory](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/b/4bbf92/32.png) [@Bruce\_Gregory](http://discourse.iapct.org/u/Bruce_Gregory)\
**Post date:** [July 26, 1998, 8:09pm UTC](http://discourse.iapct.org/t/program-control/9146/3 "1998-07-26T20:09:58Z")

</div>

[From Bruce Gregory ((80726.1607 EDT)]

Rick Marken (980726.1110)]

> My point is that "adopting a Plan" is probably an imagination  
> phenomenon. Controlling a program is a very different phenomenon;  
> it is the real-time process of controlling a program perception  
> (like the recipe for apple pie or the process of solving a  
> differential equation).

Yes, I think that's an important distinction. In the example I gave a while  
back about pedaling your bike into the village to get milk, I originally  
thought of the perception "no-milk" error signal as driving the cycling  
motion. I now suspect that the cycling is being driven by a program called  
"getting more milk". If the cycling stopped, the perception "I am getting  
milk" would experience a significant error. Cycling keeps this error from  
increasing. Somehow the error associated with "no milk" is not intrusive  
once control shifts to the "I am getting milk" program.

> \> This seems to me at least a very good reason for paying attention  
> \> to the program level, as MGP do.
> 
> I think it's important to pay attention to the program level because  
> people \_do\_ seem to control program perceptions. I think MGP did  
> pay attention to the program level of their \_own\_ perceptions;  
> they saw \_all\_ behavior as a process of carrying out a particular  
> program -- TOTE. What they didn't see was that the people they were  
> observing were controlling \_program perceptions\_. This is some-  
> thing they could not possibly have seen because they did not have  
> PCT.

Yes, they clearly lacked this fundamental insight.

> In order to determine whether or not a person is controlling  
> a program perception it is necessary to \_test\_ to determine whether  
> a program is \_under control\_.

Yes, but presumably the person knows if he or she is controlling a program,  
even if we don't.

> By the way, I thought of a conventional research study that  
> seems to demonstrate control of program perception; it is the  
> study of "problem solving set" (I forget the name of the person  
> who did it). He had people learn to solve water jar problems.  
> First, he had people solve an initial set of problems that could  
> all be solved by the same \_algorithm\_ (program): for example,  
> the algorithm might be "fill jar A, remove jar C amount from  
> jar A, fill jar B and add to jar A". Once people had learned to  
> solve the problem using this algorithm (the capacities of jars  
> A, B and C were always different during the learning trials)  
> they was very reluctant to give it up (this was called problem  
> solving set). What people seem to have been "set" on in this study  
> was perceiving a particular \_program\_ -- the algorithm that  
> solved the initial set of problems.

Thanks for the example.

Bruce Gregory

---

<div class="post-metadata">

**Author:** ![Bill\_Powers1](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/b/8e7dd6/32.png) [@Bill\_Powers1](http://discourse.iapct.org/u/Bill_Powers1)\
**Post date:** [July 27, 1998, 11:39am UTC](http://discourse.iapct.org/t/program-control/9146/4 "1998-07-27T11:39:21Z")

</div>

[From Bill Powers (980727.0536 MDT)]

Rick Marken (980726.1110) --

Nice discussion of Plans. Another thing that MGP didn't understand is that  
plans consist of a series of perceptions to be achieved, not a series of  
actions to be generated in the hopes that they will produce the wanted  
results. There is no way to predict what actions you will generate when the  
time comes actually to carry out a plan.

Best,

Bill P.

---

<div class="post-metadata">

**Author:** ![Bruce\_Gregory](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/b/4bbf92/32.png) [@Bruce\_Gregory](http://discourse.iapct.org/u/Bruce_Gregory)\
**Post date:** [July 27, 1998, 1:36pm UTC](http://discourse.iapct.org/t/program-control/9146/5 "1998-07-27T13:36:16Z")

</div>

[From Bruce Gregory (980727.0935 EDT)]

Bill Powers (980727.0536 MDT)

> Rick Marken (980726.1110) --
> 
> Nice discussion of Plans. Another thing that MGP didn't understand is that  
> plans consist of a series of perceptions to be achieved, not a series of  
> actions to be generated in the hopes that they will produce the wanted  
> results. There is no way to predict what actions you will  
> generate when the  
> time comes actually to carry out a plan.

This is certainly true, but should not detract from the importance of  
control at the program level. Most of our actions seem to be the result of  
control exercised at the program level of perception.

Bruce Gregory

---

<div class="post-metadata">

**Author:** ![Bill\_Powers1](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/b/8e7dd6/32.png) [@Bill\_Powers1](http://discourse.iapct.org/u/Bill_Powers1)\
**Post date:** [July 27, 1998, 4:29pm UTC](http://discourse.iapct.org/t/program-control/9146/6 "1998-07-27T16:29:33Z")

</div>

[From Bill Powers (980727.1027 MDT)]

Bruce Gregory (980727.0935 EDT)--

> This is certainly true, but should not detract from the importance of  
> control at the program level. Most of our actions seem to be the result of  
> control exercised at the program level of perception.

I hope so, since that's the basis of HPCT. Also, all actions organized by  
the program level are also organized by the principle and system concept  
levels, since they are hierarchically above the program level and account  
for the choice of programs to be run.

Best,

Bill P.

---

<div class="post-metadata">

**Author:** ![Bruce\_Gregory](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/b/4bbf92/32.png) [@Bruce\_Gregory](http://discourse.iapct.org/u/Bruce_Gregory)\
**Post date:** [July 27, 1998, 5:55pm UTC](http://discourse.iapct.org/t/program-control/9146/7 "1998-07-27T17:55:37Z")

</div>

[From Bruce Gregory (980727.1355 EDT)]

Bill Powers (980727.1027 MDT)

> Bruce Gregory (980727.0935 EDT)--
> 
> \>This is certainly true, but should not detract from the importance of  
> \>control at the program level. Most of our actions seem to be the  
> result of  
> \>control exercised at the program level of perception.
> 
> I hope so, since that's the basis of HPCT. Also, all actions organized by  
> the program level are also organized by the principle and system concept  
> levels, since they are hierarchically above the program level and account  
> for the choice of programs to be run.

Indeed. My concern is that we sometimes seem to forget about these higher  
level and concentrate on a controlled variable without paying attention to  
the higher levels that account for the fact that this particular perception  
is being controlled. The speeding motorist may be motivated by a variety of  
principles. The TEST may show that she is intentionally speeding without  
giving us a clue as to why. To understand why, we have to conduct the TEST  
on still higher level perceptions. Some exchanges on CSGnet suggest that it  
is easy to lose sight of this fact.

Bruce Gregory

---

<div class="post-metadata">

**Author:** ![Chris\_Cherpas](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/c/a3d4f5/32.png) [@Chris\_Cherpas](http://discourse.iapct.org/u/Chris_Cherpas)\
**Post date:** [July 27, 1998, 7:03pm UTC](http://discourse.iapct.org/t/program-control/9146/8 "1998-07-27T19:03:16Z")

</div>

[From Chris Cherpas (980727.1200 PT)]

Bill Powers (980727.1027 MDT)--

> ...all actions organized by the program level  
> are also organized by the principle and system  
> concept levels, since they are hierarchically  
> above the program level and account for the  
> choice of programs to be run.

Bruce Gregory (980727.1355 EDT)--

> Indeed. My concern is that we sometimes seem to  
> forget about these higher level(s)...

Designing educational programs, which explicitly  
aim towards developing control systems above  
the program level, seems very difficult when  
it gets down to specifying the details, including  
designing relatively optimal sequencing of  
educational experiences.

Who hasn't heard of the confusions in math education  
wherein students can perform algorithmically, but  
don't seem to automatically be able to choose  
the correct programs? Typically, the education of  
these higher levels amounts to 1) sink-or-swim problems  
that overwhelm the student, and 2) overly-guided  
problems which can be solved without any new  
or improved principles or system concepts. I haven't  
seen anything that advances beyond, or greatly builds  
in detail upon, Polya's heuristics. In the best  
efforts to date, it seems the spirit is willing,  
but the science is weak.

Regards,  
cc

---

<div class="post-metadata">

**Author:** ![R\_Marken](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/r/8797f3/32.png) [@R\_Marken](http://discourse.iapct.org/u/R_Marken)\
**Post date:** [July 28, 1998, 5:07am UTC](http://discourse.iapct.org/t/program-control/9146/9 "1998-07-28T05:07:03Z")

</div>

[From Rick Marken (980727.2110)]

Bill Powers (980727.0536 MDT) --

> Another thing that MGP didn't understand is that plans consist  
> of a series of perceptions to be achieved, not a series of  
> actions to be generated in the hopes that they will produce  
> the wanted results. There is no way to predict what actions  
> you will generate when the time comes actually to carry out a plan.

Bruce Gregory (980727.0935 EDT)--

> This is certainly true, but should not detract from the  
> importance of control at the program level.

I don't see how what Bill said could be construed as in any way  
detracting from the importance of program control. In fact, before  
PCT (and my little unpublished experiments) no one even knew that  
program control \_existed\_. They knew that people carry out what  
can be seen as programs of action but they had no idea that people  
\_controlled\_ for program perceptions. So rather than detracting  
from the importance of program control. Bill's discussion of  
program control (above and in B:CP) is, to my knowledge, the  
first recognition of the \_fact\_ of "control at the program level".

> Most of our actions seem to be the result of control exercised  
> at the program level of perception.

Yes. That is the illusion that MGP fell for; actions seem to be  
the result of program control if this is the level of your  
\_own\_ perceptions of the behavior to which you attend. You can  
even see a program of actions when a person controls a cursor;

if cursor moves left then move hand right  
if cursor moves right then move hand left

Of course, this apparent program of action exists as a perception  
in the observer; it is not controlled by the person controlling  
the cursor. And, as I'm sure you know, when people do control a  
program perception, the program that is controlled is a program  
of lower level \_perceptions\_, not actions.

Bruce Gregory (980727.1355 EDT) --

> My concern is that we sometimes seem to forget about these  
> higher level and concentrate on a controlled variable without  
> paying attention to the higher levels that account for the  
> fact that this particular perception is being controlled...Some  
> exchanges on CSGnet suggest that it is easy to lose sight of  
> this fact.

Could you give an example of what you mean. Are you suggesting  
that there is something wrong with some exchanges on CSGNet  
because the participants in those exchanges lose sight of the  
fact that perceptions at one level are controlled as a means  
of achieving higher level goals? Could you explain this?

Best

Rick

> **···**
>
> --  
> Richard S. Marken Phone or Fax: 310 474-0313  
> Life Learning Associates e-mail: rmarken@earthlink.net  
> [http://home.earthlink.net/~rmarken/](http://home.earthlink.net/~rmarken/)

---

<div class="post-metadata">

**Author:** ![Bruce\_Gregory](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/b/4bbf92/32.png) [@Bruce\_Gregory](http://discourse.iapct.org/u/Bruce_Gregory)\
**Post date:** [July 28, 1998, 10:44am UTC](http://discourse.iapct.org/t/program-control/9146/10 "1998-07-28T10:44:58Z")

</div>

[From Bruce Gregory (980728.0635 EDT)]

Rick Marken (980727.2110)

> Bill Powers (980727.0536 MDT) --
> 
> \> Another thing that MGP didn't understand is that plans consist  
> \> of a series of perceptions to be achieved, not a series of  
> \> actions to be generated in the hopes that they will produce  
> \> the wanted results. There is no way to predict what actions  
> \> you will generate when the time comes actually to carry out a plan.
> 
> Bruce Gregory (980727.0935 EDT)--
> 
> \> This is certainly true, but should not detract from the  
> \> importance of control at the program level.
> 
> I don't see how what Bill said could be construed as in any way  
> detracting from the importance of program control. In fact, before  
> PCT (and my little unpublished experiments) no one even knew that  
> program control \_existed\_. They knew that people carry out what  
> can be seen as programs of action but they had no idea that people  
> \_controlled\_ for program perceptions. So rather than detracting  
> from the importance of program control. Bill's discussion of  
> program control (above and in B:CP) is, to my knowledge, the  
> first recognition of the \_fact\_ of "control at the program level".

Point taken.

> \> Most of our actions seem to be the result of control exercised  
> \> at the program level of perception.
> 
> Yes. That is the illusion that MGP fell for; actions seem to be  
> the result of program control if this is the level of your  
> \_own\_ perceptions of the behavior to which you attend.

Are you speaking metaphorically? If I am watching you control a cursor I am  
not sure how I can perceive you at the level of program control. Is this  
different from saying that I interpret your actions as if you were following  
a program? It is also unclear to me why the fact that I am controlling at  
the program level should necessarily lead me to interpret your actions as  
demonstrating control at the program level.

> You can  
> even see a program of actions when a person controls a cursor;
> 
> if cursor moves left then move hand right  
> if cursor moves right then move hand left
> 
> Of course, this apparent program of action exists as a perception  
> in the observer; it is not controlled by the person controlling  
> the cursor.

Unless, of course, the person \_is\_ controlling the cursor via such a  
program. This would have to be determined by using the TEST. (This is not to  
say that actions are being controlled, but rather that perceptions of  
actions might be controlled by such a program.)

> And, as I'm sure you know, when people do control a  
> program perception, the program that is controlled is a program  
> of lower level \_perceptions\_, not actions.

Yes, indeed, that does sound familiar.

> Bruce Gregory (980727.1355 EDT) --
> 
> \> My concern is that we sometimes seem to forget about these  
> \> higher level and concentrate on a controlled variable without  
> \> paying attention to the higher levels that account for the  
> \> fact that this particular perception is being controlled...Some  
> \> exchanges on CSGnet suggest that it is easy to lose sight of  
> \> this fact.
> 
> Could you give an example of what you mean. Are you suggesting  
> that there is something wrong with some exchanges on CSGNet  
> because the participants in those exchanges lose sight of the  
> fact that perceptions at one level are controlled as a means  
> of achieving higher level goals? Could you explain this?

In my view, much of the exchange about coercion and RTP focussed on control  
at one level (the disrupting child will leave the classroom) and ignored the  
possibility that the teacher was controlling at the program level on the  
basis of a perception at the principle level that the child, with support,  
can work out his problems and return to the classroom. Or at least, I never  
saw any mention of possible higher level perceptions.

Bruce Gregory