Table of Contents

# The edit buffer

The edit buffer is where you enter source rule language statements. As with any text editor, you can copy, cut, and paste text using both the mouse and the keyboard. Typing and removing characters also operates the same as any other editor. A popup context menu with commmon editor actions is available by simply clicking your secondary mouse button.

Each time you start the ruleset editor as a standalone program, a skeletal ruleset definition is placed into the edit buffer. You can enter variable and rule definitions into this skeleton to complete the ruleset, or you can completely replace the text by using an Open action to load an existing ruleset from disk. And, if you prefer to start with a blank slate, you can use the New ruleset action to entirely clear the edit buffer of all text.

Note that if you start the ruleset editor as a bean customizer from within the Able Editor, the contents of the selected bean are placed into the edit buffer so that you can subsequently change the contents of the bean. If you change any of the source language statements placed into the edit buffer, you must do a Verify before returning to the Able Editor. If you fail to do a Verify, you have only cosmetically changed the rules in the edit buffer; you have not changed the underlying contents of the actual bean. Using Verify is the only way to ensure that any changed source language statements are still correct, and until the statements are proven correct the contents of the underlying bean are not changed.

The remainder of this document contains some tips on working with the edit buffer.

On this page...

- Inserting templates into the edit buffer
- Specifying input and output
- Verifying source rule statements
- Testing the ruleset
- Saving the contents of the edit buffer

### Inserting templates into the edit buffer

Until you become familiar with the rule language it is difficult to know how to define variables, fuzzy sets, and rules. The edit buffer offers several ways to insert skeletal (or partial) definitions of these elements, but you must complete the partial definitions by replacing text delineated by the < (less than) and > (greater than) characters as explained in the following sections.

#### Inserting a starting skeletal ruleset

At the most basic, you can perform New ruleset followed by Insert Ruleset to obtain a partially completed ruleset definition. After doing this, change the name of the ruleset from the default of AbleRuleSet_n (where n is some number) to anything of your liking. For example, you might prefer the name MyGreatRuleSet_For_WONDERFUL_THINGS_01_A. After changing the name you are ready to insert variable definitions.

#### Inserting skeletal variable definitions

To insert partial variable definitions into a ruleset, position the text cursor after the opening parenthesis of the Variables keyword and then use Insert Variable to insert one or more variable definitions. You must complete the variable defintion by giving the variable a name. For example, after using Insert Variable Boolean to insert a Boolean variable definition into the edit buffer, you will see a line that looks like this:

            <varName> Boolean(False)

You must change <varName> to something else; for example:

            myBoolVar Boolean(True) // A comment for this variable

Note that you can change the default value of the variable as well as add a comment for the variable.

If you insert a Fuzzy variable definition into the ruleset, you must also insert one or more fuzzy set definitions for the variable, described next.

#### Inserting skeletal fuzzy set definitions for a fuzzy variable

Position the text cursor after the opening parenthesis of the SetDefinitions keyword and use Insert Fuzzy set to insert one or more partial fuzzy set definitions. Each type of fuzzy set has specifications delineated by < (less than) and > (greater than) that you must change in order for the set to be valid.

Once you have entered all variable and fuzzy set definitions that you wish, you can define some rules.

#### Defining rules

There is no way to automatically insert skeletal rules into the edit buffer, but the syntax is simple, so you simply type them in after the opening parenthesis of the Rules keyword. For the syntax of rules, see the Rule Language Documentation.

Return to top

### Specifying input and output: reading and writing values of variables before and after inferencing

#### Input

You can give your variables initial values during inferencing by using assertions in your rules, but this isn't very practical. Much more flexible is the capability to obtain values just before inferencing starts from an external input buffer that must be available at runtime, and this the inference engine does. To identify those variables whose initial values are to be obtained from an external buffer, you use the InputVariables statement. Inside the parentheses you list those variables whose values will be available in a buffer at runtime. For example, the statement `InputVariables(a, b, c)` says that, at runtime, an external buffer will be available whose first element is the initial value of a, the second element is the initial value of b, and so on. If there is no input buffer at runtime, or if there are not enough values in the input buffer, a runtime error is signaled. Extra values in a buffer are ignored.

If you leave the InputVariables statement empty, the inference engine will not expect to have an input buffer at runtime, and will not do any related error checking.

Note, too, that variables can also take on values that are the result of calling User-Defined Functions. See the Rule Language Documentation for details.

#### Output

Similar to the InputVariables statement is the OutputVariables statement. Use this statement to designate those variables whose values are to be placed into an external output buffer after inferencing is complete, so that the values may be read by another Java program. For example, the statement `OutputVariables(b, c, c, a)` says that, when inferencing is complete, an external buffer will be created and made available to other programs, and that the first element of the buffer is the final value of b, the second element is the final value of c, the third element is also the final value of c, and the fourth element is the final value of a.

If you leave the OutputVariables statement empty, the inference engine will not write any values to an output buffer.

Note that variable values can be passed to other programs by calling user-defined functions. See the Rule Language Documentation for details.

Finally, you should know that the value of a fuzzy variable is always presented to the external world as a defuzzified crisp value.

Return to top

### Verifying source rule statements

Use the Verify editor action any time after changing or inserting text into the edit buffer to verify that your source rules are correct. If your rules contain errors, as might be the case if you forgot to change some text beginning with <, a window will pop up explaining the error. Simply fix the error and try Verify again. If no errors are found, the ruleset editor title bar will contain the word verified.

Return to top

### Testing the ruleset

Use the Run editor action to test your verified ruleset. (If you have not verified your ruleset, Run will be disabled.) If your ruleset produces output (indicated by the fact that the OutputVariables statement contains one or more variable names), a window will pop up displaying the values of any of your designated OutputVariables. If you have not specified any OutputVariables (or called any user-defined functions) it may not be easy for you to tell if your ruleset did anything.

There are two limitations to testing a ruleset from within the ruleset editor.

1. You may not specify any InputVariables (leave the list empty) as there is no way to pass variable values to the inference engine from within the ruleset editor. You can work around this for testing purposes by temporarily coding an empty InputVariables statement and then entering assertion rules for each variable's value that you would normally expect to obtain from the input buffer (for example, `setValue1: fuzzyVar1 = 36.9`). To test your ruleset with different values, simply change your assertions in the edit buffer, select Verify and then Run. Repeat as many times as desired. When you are done testing, add input variable names back to the InputVariables list and then Verify and Save your ruleset. You do not need to remove your assertion statements unless you want to, because variable values obtained from an external input buffer always take precedence over any assertions.
2. You may not use declared User-Defined Functions. (Declared user-defined functions are those that are attached to the ruleset through some external means.) If your ruleset uses declared user-defined functions, you must test it externally to the ruleset editor. Imported user-defined functions (those that are made available through the use of import statements) are usable, however.

Once you are done testing your ruleset, make sure your InputVariables statement is correct and then save your work.

Return to top

### Saving the contents of the edit buffer

You can save the contents of the edit buffer as a source file on disk by using the Save ruleset and Save ruleset as... editor actions. Note that the Save ruleset action is available only when the edit buffer has been changed -- there is no point in saving something that doesn't need to be saved. The Save ruleset as... action is available at all times, and allows you to save the edit buffer under a different file name.

You can save the contents of a verified edit buffer as a serialized JavaBean by using the Save serialized and Save serialized as... editor actions and as an XML document by using the Save XML and Save XML as... editor actions. Each of these Save actions is available only when the edit buffer has been verified.

Return to top

Ruleset editor table of contents
Rule language table of contents
Rule package table of contents

Last modified: Wed Jun 6 10:02:19 CDT 2001