The Inference Block › Posting and Scope › Posting Order versus Priority Order

Posting Order versus Priority Order

The preceding example demonstrates how you can improve your application by arranging the inference order in which rules are posted. The credit-checking rules (for CreditRating) are posted after the ask-user rules (for Income and Loan) because connecting to the Credit Bureau costs time and resources. As such, we want to avoid firing the credit-checking rules unless we absolutely need to do so. And, if we can approve the loan based on Income and Loan without examining CreditRating, we should do so. By positioning the credit-checking rules after the ask-user rules, we accomplish this efficiently.

In many situations, you may want more control over the rule order. You may find it inconvenient to move large numbers of rules around after they are written, or you may wish to post a last-resort rule ahead of other rules.

The posting order is the order in which the inference engine encounters rule definitions during execution of the inference block. Aion posts rules consecutively from the top of the block. Rules may reside directly in the inference block or in rule methods that you call from it. The posting order for a block includes both kinds of rules.

Priority order governs the order in which the inference engine examines rules during forward or backward chaining. Priority indicates which is the next available rule. By default, the posting order and the priority order are the same. You can specify a different priority order by assigning priority numbers to rules.

Priority numbers work in the following way:

• The greater the value, the higher the priority.
• Priority numbers must be integers and may be positive, negative, or zero.
• If several rules have the same priority number, the inference engine decides order among them by using the posting order.

Note: If you do not specify a priority, the priority number for a rule is zero by default.

The following table of seven hypothetical rules illustrates these points. Assume that all rules are in the same inference block:

You use the keyword priority to assign priority numbers. Consider the example in the previous section. From a packaging standpoint, the last resort rule could be grouped with the LoanRules( ) method to improve the overall organization of the code.

We avoided putting it there in the first place, you may remember, because we do not want the last-resort rule to fire if other sources of information-Credit Bureau or loan officer-could alter the outcome. Priority numbers can solve this problem, letting us place all four rules together in the LoanRules( ) method.

For instance, you might assign a negative integer to the last-resort rule. You could also use priority numbers, if you did not want to depend on posting order. In that case, the other three rules in LoanRules( ) might have a priority of 5, and the rules in CreditCheckrules( ) and AskUserRules( ) a priority of 3.

The LoanRules( ) method would look like this:

rule "Good Rating: approve any loan under 10K"
priority 5
ifrule CreditRating = "GOOD" AND Loan<10000
then

Approve=TRUE

end
rule "High Income/Bad Rating: approve any loan under 10K"
priority 5
ifrule Income > 50000 AND Loan<10000
then

Approve=TRUE

end
rule "High Income/Good Rating: approve any amount"
priority 5
ifrule CreditRating = "GOOD" AND Income > 50000
then

Approve=TRUE

end
rule "If no reason to approve, then reject"
priority -2
if rule ISUNKNOWN(->Approve)
then

Approve=FALSE

end

The inference block would be streamlined, easy to understand and maintain:

INFER 

LoanRules( )
AskUserRules( )
CreditCheckRules( ) 
backwardchain (->Approve) 
TellUser( ) 

end