State Diagrams

[From Bruce Abbott (111195.1230 EST)]

Bill Leach 951111.01:26 U.S. Eastern Time Zone to Chris Cherpas--

I might have been a "little hasty" about my "state diagrams" comment.
I suspect that they would be useful in the "Program Level" of HPCT (but
not below).

Bill, Chris is talking about a way to diagram the environmental
contingencies as programmed in operant conditioning studies. The procedure
is broken down into a series of "state sets," each of which accomplishes a
particular task, For example, one can define a state set that reinforces
lever-pressing on an FR-1 schedule:

SS1: { FR-1 }
S1:
  R1:ON3------>S2
S2:
  0.1":OFF3--->S1

Here, R1 is "response on lever," ON3 is "power on to Output 3 (the feeder),
and OFF3 is "power off to Output 3." S1 and S2 are two "states." When
State 1 is current, the response will turn on the feeder and make State 2
current. When State 2 is current, the passage of 0.1 seconds removes power
from the feeder-stepper and restores State 1.

This code can be diagramed as:

SS1
             R1:ON3
   > S1 |--------------->| S2 |
      ^ |

ยทยทยท

    0.1":OFF3 |

      +---------------------+

Additional state sets would accomplish such chores as ending the session
when, say, 90 reinforcers have been delivered or one hour has passed since
start. State sets can interact, and virtually any type of schedule can be
implemented -- and as Chris notes, clearly _documented_ -- using state diagrams.

As you note, such diagrams could also document the relationships in a
sequence-level control system. Different states would define different
active control systems.

Regards,

Bruce

<[Bill Leach 951111.19:42 U.S. Eastern Time Zone]

[Bruce Abbott (111195.1230 EST)]

Thanks Bruce. I was, of course, thinking of the state diagram commonly
associated with computer programming and essential to the "state machine"
programming.

I was NOT thinking in terms of describing the experimental apparatus
(where such use should be obvious, but apparently is not).

-bill