# Program control (was Re: Shared references)

[From Rick Marken (2004.07.02.1010)]

Bruce Gregory (2004.0702.1130) --

Bill Powers (2004.07.02.0849 MDT)

There are very fews things that exist only in the "yes" and "no"
states, with nothing between and no alternative forms of either.

While i certainly agree with what you say, I interpret it somewhat
differently. No matter what state a program is in, from just beginning,
to abandoned, to almost finished, to be being debugged, it seems to me
that it is always a program (or not).

That's true of all different classes of perception, not just programs. For
example, no matter what state a color is in, it is always a color (or not,
as when it changes to a grayscale value). But in the program control task I
have developed, it's not enough to know that there is or is not a program
occurring. That is because there is always a program occurring. In order to
control for a particular program perception you have to perceive _which_
program is occurring.

Here is the way the program control demo currently works:

A sequence of numbers, such as 8 3 4 10, is presented slowly, one after the
other, to the subject. The sequence is determined by the following program:

If n>5 then np1 is odd else np1 is even

That is, if the current number (n) is >5 then the next number (np1) will be
odd, otherwise it will be even. The numbers are randomly selected integers
in the range from 1 to 10. So if the current number (n) is 8, the next
number (np1) is any odd integer in the range 1 to 10. Let's say np1 is 3.
Then when np1 is shown, it is now number n and the next number is selected
according to the program rule. So now np1 will be an even number between 1
and 10 because the current n, 3, is not >5. The following sequence of
numbers:

8 3 4 10 7 9 1 6 ...

is generated by the program that implements this rule:

n = int(rnd(3)*9)+1
While (true)
Print n
wait (1000)
np1 = int(rnd(3)*9)+1
Print n
If n>5 then
if np1 mod 2 = 0 then np1=np1-1
Else
if n mod 2 <> then np1 = np1+1
End if
n = np1
wend

A some point this program changes to one that is slightly different, but
still a program. The basic contingency in the new program is:

If n>5 then np1 is even else np1 is odd

So the sequence of numbers is still being generated by a program but now by
a program with a different contingency test. But the switch is not from
program to no program. It's from one kind of program to another.

I had this demo set up (this was done some time ago so I don't have the
program on hand but I can easily rewrite it in java) so that a push of the
mouse button toggles the number generation program from one program (the one
where np1 is odd if n>5) to another (the one where np1 is even if n>5) and
vice versa. An independent disturbance also toggled between the programs at
random times. So by pressing the mouse button, one could toggle back to the
desired (reference) program after a disturbance. Assuming the reference
program id the one where np1 is odd if n>5, then, in order to keep this
program occurring one had to be able to perceive when it is occurring and
when another program (the one where np1 is even if n>5) was occurring.

I wasn't thrilled with this demo as it sat because I'm not sure that one
actually had to perceive the program in order to control it. One does have
to be able to perceive a logical relationship between the number on trial n
and the number on trial n+1. But I'm not sure this is really the perception
of a program. I want to design a version of this demo where the perception
of the program requires seeing more than the relationship between two steps
in the program. For example, there are several different programs
(algorithms) that sort a list of numbers by size. There's the Bubble sort,
Shell sort, Heap sort, etc. I would like to write a demo that switches
between two of these sort algorithms in a way that requires that the subject
perceive more than just one or two steps in the program to know which
algorithm is currently occurring. Of course, such a demo would only work
with people who _can_ perceive these algorithms. I'll have to see if there
is a way to design the demo so that it's possible to control a program even
if you're not a computer science PhD.

Regards

Rick

···

--
Richard S. Marken
Home: 310 474 0313
Cell: 310 729 1400

[From Bill Powers (2004.07.02.1122 MDT)]

Rick Marken (2004.07.02.1010)--

I want to design a version of this demo where the perception
of the program requires seeing more than the relationship between two steps
in the program. ... I'll have to see if there
is a way to design the demo so that it's possible to control a program even
if you're not a computer science PhD.

That's a rather good idea. A program is a network of sequences joined by
choice points. So to identify a program, you have to recognize the pattern
of choice points, or the sequences, as being the same (though I'd opt for
the choice points). The key for identifying a program is to see that the
choice points go the same way every time a test occur.

if a > b then do c
or
if a > b then do d

c and d eventually get back to the original choice, if a > b

Best.

Bill P.