For a general introduction to inexact rules see What are inexact rules? General issues of using inexact rules are explained in Using Inexact Rules.

 

Fuzzy Sets

There are four main types of fuzzy set rules, which combine one or more fuzzy sets into a resulting set. In addition to that, both data and support rules can be used to represent fuzzy set membership functions. See e.g. the fuzzy set fuel efficient bikes (query rules under).

 
Complement The membership function for the complement of a fuzzy set.
Intersection The membership function for the intersection of two or more fuzzy sets (by using one of the four intersection methods standard intersection, algebraic product intersection, bounded difference intersection or drastic intersection).
Union The membership function for the union of two or more fuzzy sets (by using one of the four union methods standard union, algebraic product union, bounded difference union or drastic union).
Ordered Weighted Averaging The membership function for a set averaging operation of one or more fuzzy sets, where a weighting factor is applied to the contributing sets.
The fuzzy set operations are defined in more details in the Fuzzy Set Concepts page.

The window (under) is used for all fuzzy set rules except ordered weighted averaging rules (which does not have the nine radio buttons in the middle of the window). The upper three fields show the rule's NL-name, KB-name and realm (only the latter can be changed).

The window above shows the fuzzy set bad roads type bike (with parameter model name) which is an algebraic product intersection of the fuzzy sets not big bikes and not good roads only type bikes (which unsurprisingly has the same parameter). The input parameters are entered or changed in the same way as in the general rule definitions window.

The radio buttons are used to specify the desired type of fuzzy operation. The listbox lists the fuzzy sets combined in the operation. The list is modified by the five buttons on top. All but the Add Set-button requires that one of the sets in the list is selected (a set is selected by clicking it). The Add Set and Edit Set-button invokes the general rule-call dialog.

ORDERED WEIGHTED AVERAGING

The ordered weighted averaging type fuzzy set uses a window similar to the window above, however without the radio buttons. Each call is associated with a weighting factor - either an explicit value (> 0.0) or a call to a rule returning the appropriate weighting value. Refer to the general rule-call dialog.

 

AND-, OR- and NOT-rules
AND Returns the lowest of the returned probabilities or certainty factors of two or more called rules. (The probabilities will be used if the the rule returns a probability and vice versa).
OR Returns the highest of the returned probabilities or certainty factors of two or more called rules. (The probabilities will be used if the the rule returns a probability and vice versa). 
NOT Returns the inverse probability (or certainty factor) of another rule. (The probabilities will be used if the the rule returns a probability and vice versa). The inverse of probability p is 1-p. The inverse of certainty factor c is computed by first computing pc (the probability corresponding to c - see prior probabilities), and then computing the certainty factor ci corresponding to 1-pc.
AND-rules are entered in the window under. The Add Call- and Edit Call-buttons open the general rule call dialog where the rule to be called (and its actual parameters if any) is selected.

The AND-rule in window above specifies that the certainty of peter will catch tanigue  is equal to the lowest certainty of the three propositions there will be fresh bait available, there will be good sea conditions and there will be no dynamite fishing. Note that same rule is displayed as bayesian type rule under (for the illustration purpose).

The OR- and NOT-rule uses the same window as being used by AND-rules (with the exception of the field headers). Only one rule can be called by a NOT-rule. A context can be specified for AND-, OR- and NOT-rules.

Bayesian Rules
Bayesian A bayesian-type rule returns a certainty factor (or probability) by applying assumptions (built in to the rule) of dependent probabilities on the certainty factors (or probabilities) returned by one ore more called rules (which return probabilities (or certainty factors)), by applying assumptions (built in to the rule) of dependent probabilities (see Probabilities - Dependent Probabilities - Certainty Factors ).
The bayesian type rule in window above specifies that the certainty of peter will catch tanigue  is determined via a bayesian logic type combination of the three propositions there will be fresh bait available, there will be good sea conditions and there will be no dynamite fishing. The only superficial difference between the bayesian rules and the simpler AND-rules, is the increment and decrement factors (the computational logic is of course quite different). Note that same rule is displayed as an AND-rule above (for the illustration purpose).

Increment and decrement factors

One increment factor (greater or equal to 1)  and one decrement factor (in the range <0.0,1.0> are specified for each called rule. These factors define the significance of the dependency between the propositions represented by the called and the calling rule. The application of the factors depend on the prior probability (pp) and evaluated probability (p) of the called rule:

  • p = pp : the factors have no effect
  • p < pp: the "disbelief" in the proposition representing the calling rule, is greater the smaller the decrement factor is (the increment factor has no effect)
  • p > pp: the "belief" in  in the proposition representing the calling rule, is greater the bigger the increment factor is (the decrement factor has no effect)

See Dependent Probabilities for more details and examples.

Increment and decrement factors as rule calls

Increment and decrement factors are either explicitly specified in the bayesian rule, or they are specified indirectly by a call to another rule (which then returns the increment or decrement factor). This can be useful in certain contexts e.g. where "correct" value of the factors depend on the rule's input parameters or depend on evaluation-time consultation with the user through a question-rule.

Note that a contributing rule can only occur once in the same bayesian combination.

 

Combination Rules
Combination Returns a certainty factor (or probability) from two or more called rules (which return certainty factors (or probabilities)), according to the following formula:
  • CF1>0,CF2>0 : CF1+CF2 - CF1*CF2 
  • CF1<0,CF2<0 : CF1+CF2 + CF1*CF2 
  • CF1=-CF2 ,CF1+CF2 =0: 0
  • else : (CF1+CF2) / (1-min(|CF1|,|CF2|))

(see also Probabilities - Dependent Probabilities - Certainty Factors ).
The combination rules use the same window as the AND-rules (with the exception of the field headers).

Data Rules
The only class of rules which do not necessarily call other rules are the data rules (they can optionally call other rules to specify a context). A question rule gets its return value from the KE/user, while a query rule gets its answer from the knowledge base. 
Query Returns a value by querying the knowledge base (single-value query). The query can be parameterized, such that one or more of the input parameters to the rule can be used as actual parameters in the query. The answer to the query can optionally be mapped into another value through a defined map which forms a part of the rule.
Question Returns a value by soliciting a value from the user during the interpretation of the rule. The question text associated with the rule, can be parameterized such that one or more of the rule's input parameter values can be used as part of the question text. The answer to the question can optionally be mapped into another value through a defined map which forms a part of the rule.  
 

QUESTION RULES

The question is simply a text (used in the prompt presented to the KE during run-time rule interpretation e.g. How important is the bike size preference?). The answer value must be from the specified answer domain, and Pro/3 insists on getting a value from this domain.

Answer alternatives are optionally listed in square brackets after the question text which in this case must be end with a question-mark. The answer alternatives are separated by semi-colons. The answers must be from the selected answer domain. The user has no option, but selecting one of the answer alternatives if these are specified.

Embedded parameters 

Rule input parameters can optionally be embedded in the question text in curly brackets (e.g. Are you considering stocks from the [sector] industry?. These parameters are substituted with their actual values when the question is presented to the user.

The default value must be from the answer domain. It will be used if the user cancels the question prompt window.

The annotation for the rule (if any) will be displayed together with the question prompt (in the lower part of the question window):

 

Two "input facilities" can be specified to improve the user-interface of inexact rule networks with question rules, i.e. question series and question clusters.

 
MAPS

Maps are used to map from one set of values to another set, possibly of different domains. Maps are used iwith queries, questions and in map rules (described under). There are two types of maps: numeric maps and discrete maps. 

Numeric maps apply to any query which returns a number. Linear interpolation is used when the query value falls between to map entries. Query values outside the minimum and maximum map entries will be mapped as the minimum or maximum value in the map. Numeric maps map into a numeric value.

Discrete maps (as in the example to the right) will only map query values that match entries in the map. Map entries can be numbers, integers, strings (in double quotes) and identifiers. 

The from and to domains are shown over the edit controls where new map-entries are entered. The values must be of the same domains.

 

 
You enter a map value by typing the value mapped from and value mapped to in the edit controls under the domain specifiers, and finally press the Add-button. The sequence of map entries are not significant since the entries are properly sorted (numeric maps) when the map is used by the inference engine.
CONTEXT

A rule can optionally have a context A context is simply one or more calls to other inexact rules . Each call is associated with a condition which must be satisfied for the calling rule to be considered in context. If at least one of the context calls do not satisfy its condition, then the calling rule is considered out of context and the rule's  out of context value is returned. The following types of conditions can be specified:

  • V = value
  • V <> value
  • V > value
  • V >= value
  • V < value
  • V <= value
  • V > value1 & V < value2
  • V > value1 & V <= value2
  • V >= value1 & V < value2
  • V >= value1 & V <= value2

Context calls are added by pressing the Add Context Call-button (which opens the general rule call window). You can change the sequence of the calls by the Move Up and Move Down buttons (the sequence of the calls has no significance).   

Pro/3 will not validate the conditions i.e. whether they make logical sense or not! 

 

QUERY RULES

Query rules contain a single-value query and optionally a map as in question rules. Input parameters to the rule can be embedded in the query.
Query

The query included in the rule should be a single-value query type. The syntax is the same as for entering queries in general in Pro/3, however the common start of the query e.g. what equals (or what =) is dropped. The question-mark at the end of the query text can optionally be left out.

Example:

The query what=first value of consumption where bike with model=this model name
has metric specifications with consumption > 0.0? when used in a certainty rule, should be entered as first value of consumption where bike with model=this model name
has metric specifications with consumption > 0.0.

Pro/3 cannot handle data rule queries which directly or indirectly involves the evaluation of an inexact rule network.

Query parameters

The rule's input parameter (if any) can be embedded in the query as follows: 

... bike with model=is fuel efficient's model name has ...

The rule input parameter is prefixed with the rule's name followed by 's. An alternative shorter alternative syntax is better i.e. the genitive form of the rule name is replaced by this:

... bike with model=this model name has ...  

The syntax can be validated by the Validate-button (not shown in the picture over), and you can test run the query with the Run query-button. You should then usually replace rule input parameters (used as actual parameters) with literal values. Always check your query with the Validate-button, which also is required to determine the value domain returned by the query.

Default value

The default value is mandatory, and it is used in place of a value returned by the query if the query fails. This means that the default value must be of the same domain as the value returned by the query. The default value must be map-able (if a map is used). 

The query value domain must be the same as the rule's return domain if no mapping is specified.

 

Map Rules
Map Returns a value mapped from another value (returned from a called rule).
This map rule calls (refers to) the fuzzy set undervalued stocks, and maps the membership grade value returned into a certainty factor (which represents the certainty of stock will give good return. The map is a trivial numeric map.

Parameter Rules
Parameter Calls one or more rules and uses the values returned by these rules as actual parameters in a call to another rule. The value returned by this last rule is the value returned by the rule.
The parameter-type rule above calls (in the context that the user has specified an ABSOLUTE PRICE RANGE) the rule bike is within the price range with two parameters namely lowest price and highest price. These two parameters are given by the user during run-time i.e. via the two question rules lower price limit and higher price limit. The values returned by these two rules are assigned to the two variables Low and High (within the parameter rule) and subsequently used as actual parameters to the bikes is within price range-rule.

CALL DETAILS FIELD

Rules with long names and/or long parameter tails are sometimes not fully visible in the listbox displaying calls. The "call details field" at the bottom of inexact rule windows displays highlighted (selected) calls such as the call to the rule bike is within the price range in the window above. The details field is horizontally scrollable, thus making it possible to see the entire call by scrolling to the right. The field cannot be used for altering the call.

Switch Rules
Switch Returns the value returned from a called rule selected from a list of rules, on the basis of a call to a special "switch" certainty rule (call-switch type switch rule). Comparison is made to a switch-type of statement used in various programming languages.
Returns the value returned from a called rule selected from a list of rules, on the basis of one of the rule's input parameters (parameter-switch type switch rule).
Switch-rules are used to dynamically select a rule to be called, either on the basis of one of the rule's input parameters or on the result returned from another rule. Switch rules can have a context.

CALL-TYPE SWITCH RULES
The call-type switch rule calls a criterion rule (the Add/Change Criterion Rule-button invokes the general rule call dialog), and the value returned by this rule is used as basis for selecting the (main) rule to be called. Each of the main rule alternatives (three in the example above) is associated with a condition, and the first condition satisfied determines the main rule. If e.g. the value returned by the road type requirement-rule is SURFACED LOW-QUALITY ROADS, then the second not good roads only type bikes-rule is called. The value returned by this rule is the value returned by the switch-rule itself (bikes that match road type requirement).

The conditions have the same structure as the context rule conditions, however switch-rules additionally have a default-condition. The rule specified for the default-condition is called if none of the other conditions are satisfied. Note that "branches" of the switch-rule are tested from top to bottom until eventually a condition is satisfied. Thus the sequence is significant unless the conditions are mutually exclusive (which is the recommended structure).

The default criterion-rule value is used in cases where the value returned by the criterion rule fails to meet any of the switch conditions.

Pro/3 will not validate if the conditions are incomplete, over-lapping or illogical! 

PARAMETER-TYPE SWITCH RULE
The window used for parameter-type switch rules is similar to the window used for call-type switch rules. The criterion rule-call fields, however, are not included since the switching is determined by the value of a designated input parameter (rather than the value returned by the criterion rule). This parameter is simply selected in the parameter listbox on the left side of the window. A default parameter value is used in place of the default criterion-rule value.