You
could assign each rule to a different module, then push the modules in the
appropriate order.
You
could use what I've been calling 'indicator' facts. The first rule to fire
looks for the lack of any indicator fact, and asserts a fact indicating it's
execution. The second rule looks
Hello,
rule1 could assert a fact that results in rule2 getting fired;
rule 2 could assert a fact that results in rule3 getting fired.
Rr.
-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED] namens Subrahmanyam
Verzonden: ma 11-8-2003 14:45
Aan: [EMAIL PROT
There are a couple of additional techniques you can use to control rule
firing order. The main one is introducing additional "state" facts into
the fact base; another is using modules. A very crude example is:
(deftemplate state (slot current))
(assert (state (current 0)))
In your MAIN module
I think that Ross Judson said:
>> There are a couple of additional techniques you can use to control rule
firing order.
FYI - There are two more ways:
1. Flip the order in which Jess fires facts on the agenda (first activated
= first to fire) by using the (set-strategy breadth) command -- a depth
Or, just a thought, you could use a goal-oriented approach such that
the first CE of the rule is a Goal object with a Name, usually a
literal equal to a integer for speed considerations and to avoid the
String.equals(String) method. All of the rules having to do with one
stage would ask "if th