	     EVALUATING RULES USING HIGH-LEVEL LANGUAGE CONSTRUCTS

			     ME 715  Assignment 5.1
				 Brad Rodriguez
				17 October 1989

	I. INTRODUCTION

	The objective of this project is to implement the animal species
	expert system of Chapter 5 in a high-level language.  "Rules"
	will be written as IF-THEN clauses, and ordinary variables will
	be the logic variables of the system, for inputs, intermediate
	conclusions, and final conclusions.  We will also examine the
	effects of optimal and sub-optimal ordering of the rules.

	II. PECULIARITIES OF THE FORTH LANGUAGE

	This project is written in Forth.  Although Forth is a
	structured, procedural language, it is different from other such
	languages (like Pascal or C) in both its syntax, and the customs
	and conventions that have arisen around it.  A few words of
	explanation are in order.

	All routines in Forth are known as "words."  The names of all
	the words in the system are kept in a data structure called the
	"dictionary."  The process of programming in Forth is one of
	"defining a word" (or set of words) which perform the desired
	function.  New Forth words are defined in terms of words which
	are already "known."  This approach is "extensible" in that any
	word, whether supplied by the system or defined by the
	programmer, can be used in the creation of new words.

	Forth source code is not kept in disk files, but in disk
	"screens," each 16 lines of 64 characters.  (This used to
	correspond to physical disk sectors.) The process of compiling
	Forth source code is called "loading" these screens.  In
	general, anything which can be loaded from a screen can be
	typed in directly, and vice versa.

	Like BASIC and LISP, Forth can execute a program statement
	"interpretively," by typing it as a command.  (There are certain
	exceptions to this rule.)  This can also be done from a "load
	screen."  In other words, a disk screen may contain source code
	to be compiled, "batch" commands to be executed, or both.

	Forth operates on data using a stack -- like a Hewlett-Packard
	calculator -- and also uses the Reverse Polish notation that
	HP made famous.  Almost all functions are written
		operand operand ... operation
	So, to add 2 and 3 in Forth, you would program "2 3 +" .



	III. DESCRIPTION OF THE PROGRAM

	Listing 1 (appendix) is the direct implementation of the
	algorithm given in Chapter 5.  It occupies four Forth screens,
	numbers 9 through 12.  The right half of each page is devoted
	to comments; this is a popular Forth technique called "shadow"
	documentation.

	All of the logic variables are defined in screen 9.  A VARIABLE
	in Forth holds a 16-bit binary (integer) value.  The Forth
	convention for logic values is that zero is false, and any
	non-zero value is true; "true" is usually stored as -1 (a binary
	number of all '1' bits).

	Also on screen 9 are two "words" to store "true" and "false"
	into a variable: YES and NO.  Frequently performed operations
	like these are often "factored out" into separate words.  This
	simplifies the later definitions, and if good names are chosen,
	can improve readability.  This also lets us do a common Forth
	"trick" -- the definition of YES has some extra code added,
	whose purpose is to print the name of the variable it sets to
	true.  By "instrumenting the code" in this way, we obtain a
	printed record of all the "firings," in the order they occur.

	Screens 10, 11, and 12 are the program loop.  Several notes
	should explain it:

	a)  the sequence ": CONCLUSION" begins the definition of a new
	    word named CONCLUSION.  The definition is ended by a
	    semicolon ";".

	b)  Forth has no GOTO statement.  An infinite loop is programmed
	    using the BEGIN ...  AGAIN structure.  

	c)  The word "@" (pronounced "fetch") fetches the contents of a
	    variable; e.g., "CLAWS @" fetches the value stored in CLAWS.

	d)  The Forth if-then-else structure has a somewhat unusual
	    syntax.  For a simple if-then, it is
		condition  IF  true-stuff  THEN
	    and for an if-then-else, the syntax is
		condition  IF  true-stuff  ELSE  false-stuff  THEN
	    The word "THEN" is Forth's "endif."

	e)  QUIT is Forth's function to terminate the program.

	f)  Comments in Forth are enclosed in parentheses.


	Screen 13 is a "batch file" load screen, containing commands
	to initialize the variables and then run the program.  This
	initialization is important because Forth has no means of
	specifying initial data for a variable when the program begins,
	and so the variables will keep whatever values they had from a
	previous program run.

	The first part of the screen is the inputs.  The programmer can
	edit these with Forth's resident editor between program runs.
	Following these are the intermediate conclusions; we MUST make
	these false, to clear the leftover logic values from the
	previous run.  Note that, since we have already defined YES and
	NO, we can use them here as "batch commands."

	Finally, the "command" CONCLUSION is executed.  This runs the
	program.

	IV. DISCUSSION OF RESULTS

	Figure 1 is the screen 13 input data, and the results, of the
	first test run.  Observe that, since we are using YES to set
	the input values, we get a printed report of every value we
	set to true in the initialization.  The loop then begins,
	three rules fire, and the conclusion of "zebra" is reached.
	Only one pass through the loop occurs.

	Figure 2 is the same program with different test data.  Again,
	in one pass through the loop, three rules fire, and the
	conclusion "tiger" is reached.

	Listing 2 (appendix) is the program modified with the rules in
	a random order.  (The original rule numbers are kept in
	comments so the ordering is evident.)

	Figure 3 is the "zebra" test run with this modified program.  It
	now takes three passes through the loop to fire all of the
	intermediate conclusions; one "new" conclusion is made on each
	pass.  On the final pass, the final conclusion "zebra" is
	reached.  The intermediate conclusions and the final result are
	the same as those of Figure 1, but more loops are required.

	Figure 4 is the "tiger" test with the modified program.  Even
	though all of the intermediate conclusions fire on the first
	pass through the loop, it takes a second pass for the final
	"tiger" conclusion to fire.  Again, the intermediate conclusions
	and final result are the same, but more loops are taken.

	So it does indeed appear that a system using IF-THEN rules
	will reach the same conclusion, independent of the ordering of
	the rules, as long as enough iterations are performed.
