RUN AND COMMAND MODES

FLOPS has two types of operational modes;command, in which FLOPS commands are directly executed in the order in which they are encountered; andrun, in which FLOPS rules are fired.

FLOPS always starts out in command mode, reading its commands either from a FLOPS program disk file or from the keyboard. Command mode is procedural;

commands are executed in the order in which they are encountered.FLOPS remains in command mode until aruncommand is executed, placing FLOPS into run mode, or until astoporexitcommand terminates the FLOPS run.

Inrunmode, FLOPS rules are fired.Run mode is data-driven and non-procedural;

the order in which rules are written has nothing to do with the order in which they are executed. FLOPS remains in run mode until no more rules are fireable; a halt command is executed; a specified number of rule-firing steps has been carried out;

or until the FLOPS run is terminated by a stopor exit command. On leaving run mode, FLOPS reverts to command mode unless the program has been terminated.

Exercise Hello1.fps. For years the most popular introductory program for a language has been one that prints out “Hello, World!” to the monitor screen. We will use two versions of a FLOPS Hello program. The first of these is executed entirely in command mode. The program itself follows:

:Hello1.fps - simplest "Hello, World!" program.

message "Hello, World!";

exit;

FLOPS always starts in command mode. When we tell FLOPS to open a program, it reads the program line by line, ignoring comments and executing com-mands. FLOPS will remain in command mode until a run command is encountered.

We first open TFLOPS, then open file Hello1.fps in subfolder examples. Note that the first line, a comment, uses a gray font. In the next line, “message” uses a

2.4 RUN AND COMMAND MODES 19

blue font since it is a FLOPS command, and the string “Hello, World!” uses a red font, the FLOPS color code for a character string. Finally, “exit”, another FLOPS command, is also color-coded in blue.

To run Hello1, we click on “run” on the menu bar, then “run hello1.fps”. FLOPS is now invoked, and opens the Hello1.fps file in command mode. The comment line is ignored, as is the null line that follows, and the “message” command is read and exe-cuted. Immediately a dialog box with the message “Hello, World!” is displayed. We click the “OK” button, and FLOPS reads and executes the “exit” command. A ter-mination dialog box is displayed, FLOPS terminates and we return to TFLOPS with an error log “0 warnings, 0 errors” displayed at the bottom of the screen.

If you wish, you can display other messages by adding or changing FLOPS com-mands. If you intend to modify the program, it is important to save it under another name, such as “temp.fps” before any modifications are made. Click on the “Help”

menu bar item, then click on “Manual”, then select “Input/Output commands”.

Your two output options are “write”, which writes a message to the screen without pausing, and “message”, which puts up a dialog box displaying the selected text with “OK” and “Cancel” buttons.

It is easy to see that command mode is limited in its power, especially since there are no program loops. Command mode is essential when setting up a FLOPS program to run; in command mode a FLOPS program may be read, the data declara-tions are implemented, rules are compiled, and initial data are set up. For the FLOPS programmer, command mode is very important in program debugging, since FLOPS has a number of commands especially for debugging. But the real work of an expert system is done in run mode, illustrated by Hello2.fps.

Exercise Hello2.fps. Although very tiny, Hello2 has the elements of a non-trivial FLOPS program: a data declaration, a rule, a command to create initial data, and a “run” command to switch from command mode to run mode. Unlike Hello1, Hello2 does its work in run mode.

:Rule-based "Hello, World!" program.

message "Compiling Hello2.fps;

declare Data output str;

:rule r0

rule (goal Write message to screen) IF (in Data output = <Str>)

THEN message "<Str>";

make Data output = "Hello, World!";

message "Hello2 ready to run";

run;

exit;

As before, we invoke TFLOPS and open hello2.fps in the examples folder. After hel-lo2.fps is loaded, we run it in the same way as we ran hello1.fps in the previous exercise.

Flops starts running Hello2 in command mode, just as in running Hello1. As before, the initial comment is ignored. The message command is executed, display-ing the “Compildisplay-ing Hello2.fps” message. Next, the data declaration is executed, and the single rule is compiled. The initial instance of data element Data is created; this instance of Data makes rule r0 fireable. After another message to the user, FLOPS executes the “run” command and switches to run mode. The rule fires and executes the consequent “message” command, displaying “Hello, World!” in a dialog box.

After rule r0 has fired, no more rules are newly fireable; rule r0 will not fire again on the same data. We return to command mode, read and execute the “exit”

command, and return to TFLOPS.

2.4.1 Run Mode: Serial and Parallel Rule Firing

In data-driven expert systems, it often (even usually) happens that the data make two or more rules concurrently fireable. In that case, the computer has two options. The first option is taken by almost all non-fuzzy expert systems; arule-conflict algorithm decides which rule will be fired, and the rest of the fireable (but unfired) rules are placed on a backtracking stack. After firing the selected rule, we look to see if any rules are newly fireable. If so, the process is repeated, and again any fireable but unfired rules are placed on top of the backtracking stack. If at some point no rules are newly fireable, a rule is popped off the backtracking stack and fired; this is calledbacktracking.This option is called sequentialor serial rule firingmode.

mode or terminates the program.

The second option is used by most fuzzy systems. If the data make several rules concurrently fireable, they are all fired, effectively in parallel. However, a new problem can arise; if two or more rules attempt to modify the same data item in different ways, amemoryconflict occurs, and must be resolved by amemory conflict algorithm.In expert systems that work with fuzzy sets, parallel rule firing is con-siderably more efficient than serial rule firing, permitting faster speed, greater clarity, and economy in the number of rules needed.

The choice between serial and parallel rule-firing modes can depend on the nature of data input. If information must be elicited from the user in a context-dependent fashion, so that each question to be asked depends on the answer to the previous question, serial rule firing is indicated. (It may also be useful in the depth-first search of a decision tree, or in the emulation of deductive reasoning, although one should first make sure that a parallel program will not work better.) A serial program can be much slower than an equivalent parallel program, since systems overhead is very much higher. Parallel programming is indicated if data are supplied to the program without user input from the keyboard, as in real-time on-line oper-ation, or when the data are input from a disk file. In general, parallel programming is to be preferred to serial programming, unless there is a specific reason why serial

2.4 RUN AND COMMAND MODES 21

programming is indicated. Parallel FLOPS programs have a .par suffix; serial programs have a .fps suffix. For example, programs badger.fps and auto2.fps ask a series of questions of the user, and the next question to be asked cannot be chosen until the previous question has been answered, and serial rule firing is employed. Program echo.par takes its input from a disk file prepared by a previous C program; program schizo.par asks a fixed sequence of questions; and program pac.par takes its input on-line in real-time from a patient physiologic monitor; all these programs use parallel rule firing.

The situation may arise when a combination of these modes is desirable; perhaps serial mode to obtain necessary information, and parallel mode to draw conclusions from these data. The FLOPS commandsserialandparallelpermit switching from one mode to the other.

2.4.2 Checking which Rules Are Fireable: The RETE Algorithm

In both serial and parallel rule-firing modes, we first check to see which rules the data make fireable. In serial mode only, we select a rule for firing using a rule-conflict algorithm. Next, we fire our rule(s) and place any other fireable rules on the backtracking stack. We use a memory-conflict algorithm to decide whether memory-modifications are permitted. This process is then repeated.

Data-driven systems spend most of their time finding out which rules are fireable.

An obvious way to check for rule fireability is to set up a loop over all rules, then inside this loop set up another loop over the data too see if a rule is fireable.

This can be terribly time-consuming. To reduce this time and speed up programs, Charles Forgy devised the RETE algorithm, which speeds up this process considerably (Forgy, 1982). Since in parallel programs the rules have to be scanned for fireability less often, parallel rule firing tends to run considerably faster thanserial rule firing.No rule conflict algorithm is needed.

2.4.3 Serial Rule Firing

Serial rule firing amounts to a depth-first search of a decision tree. Figure 2.1 illustrates the dynamics of rule firing in serial mode. At the start of the program, rules R1, R2, and R3 are concurrently fireable; R10 through R15 represent goal states, and will fire when we have reached a conclusion.

At the start of the program, rules R1, R2, and R3 are concurrently fireable. Our rule conflict algorithm selects R1 for firing, and R2 and R3 are placed on the back-tracking stack with R2 on top. R1 is fired, making R4 and R5 fireable. R4 is selected for firing, and R5 placed on top of the backtracking stack, which now holds R5, R2, and R3. R4 is fired, but does not make any rules newly fireable; R5 is popped off the backtracking stack and fired. The backtrack stack now holds R2 and R3. R5 is fired, but does not make any rules newly fireable; R2 is popped off the backtracking stack, which now holds only R3; R2 is now fired. R2 makes R6 and R7 newly fireable; R6 is selected, and R7 added to the backtrack stack that now holds R7 and R3. R6 makes R12 newly fireable; we select R12, and fire it. No rules are newly fireable; our goal

state has been reached, and we return to command mode. The important feature that serial rule firing requires is the rule conflict algorithm (Jackson, 1999), to decide which of two or more newly fireable rules will be selected for firing. We first con-sider rule-conflict algorithms designed for crisp 0-1 logic. There are several points to be considered when selecting a rule for firing. These includerefractoriness, which includes the obvious requirement that a rule should not be permitted to fire twice on the same data;recency, which considers how recent they are in the rule antecedent;

andspecificity, which considers the complexity of the antecedent. All commonly used strategies use refractoriness first. The LEX strategy then sorts by recency;

and the MEA (Means-End Analysis) strategy is a development of the LEX strategy (Jackson (1999), p. 87) to include specificity.

FLOPS rule-conflict strategy first ranks the rules for firing by the truth value that the rule antecedent is true combined with the truth value that the rule itself is valid, the posterior confidence ,pconf.. If there is a tie among the first-ranked rules after this step, FLOPS then employs the MEA algorithm. If there is still a tie for first, one of the tied rule is randomly selected. The backtracking stack is maintained, with fireable but unfired rules being placed on top of the stack and, if no rules are newly fireable, rules are popped off the top of the stack and fired.

2.4.4 Parallel Rule-Firing

Parallel mode amounts to a breadth-first search of a decision tree, and is a bit simpler than the serial mode. If several rules are concurrently fireable, we fire them all. Since all fireable rules are fired, there is no backtracking. Parallel programs are organized by rule blocks, and these blocks are turned on or off for firing bymetarules.In AI parlance, metarules are rules whose purpose is to control the sequence in which program sections are invoked. Metarules may enable or disable individual rules, blocks of rules, or entire programs, and are essential in parallel programs. Within those blocks of rules that are enabled, rule firing is data-driven and non-procedural.

Metarules furnish procedural organization of enabled rule blocks and programs.

Rule firing in a parallel FLOPS program then consists of a procedurally organized sequence of non-procedural steps.

Parallel rule-firing is shown in Figure 2.2.

Figure 2.1 Rule firing sequence in serial mode, illustrating backtracking.

2.4 RUN AND COMMAND MODES 23

2.5 FORWARD AND BACKWARD CHAINING