Hi Rosita,

I have been working on  a network problem that sounds similar to yours.

Here are a few design considerations that have helped me out:

- Separate the (relatively static) topology facts and rules that operate
on the topology of the network, or topology of the faults, from the
(relatively dynamic) state of the network.

- Regarding topology, design the application such that you derive static
'meta' facts about the topology that will reduce the number of
partial-matches in your dynamic rules. for example:

(defrule find-important-network-connections
    (device (name ?A) (type IMPORTANT))
    (device (name ?B) (type TRIVIAL))
    (device (name ?C) (type IMPORTANT))
    (connected (from ?A) (to ?B))
    (connected (from ?B)  (to ?C)
=>
    (assert (important-connection (from ?A) (to ?C))
    ; now you can just match on important-connections of which there
will (presumably) be far fewer
)

- If applicable, process and store derived topology knowledge only when
the topology changes. Then load this knowledge into the dynamic
process(s) as needed. This can save space and time in your dynamic state
processing.

- Regarding aging: simply attach a time attribute (ie slot) to your
time-sensitive facts, and then define rules that describe the time
related relationships of such facts. So to age fault facts for example:

(deftemplate fault
     (slot name)
     (slot time)
)

(defrule age-old-faults
    (current-time ?now)
    ; match if the fault is more than some tolerance old:
    ?f<-(fault
                    (time ?t&:(> ( - ?now ?t) ?tolerance) )))
=>
    (retract ?f)
)

- Implementing some of the rule performance guidelines can have dramatic
impacts on the speed of your application. For example put patterns that
will likely have few matches, or that change infrequently, first. In
your case those are likely to be topology definitions or global
attributes.
ie
(defrule process-fault
    (current-time ?now)  ; there will only be one of these (unless you
are doing quantum physics or something ;-)
    (important-connection ?A ?B) ; this will be relatively static
    ....
     (fault ?A) (fault ?B)
=>
     (assert (panic ...))
)


- Remember that the rete algorithm, by design, is generally efficient at
processing facts where only a small percentage of them are changing at
any one time:  you may be plesantly surprised at how well JESS finds
it's way around a network dataset where many facts are static.

- Lastly: have fun.

Hope that helps,

Jack


---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------

Reply via email to