Sunday, December 10, 2006
Users know a solution when they see it. But, they don't necessarily know how to get there.
Facts: represent current state of the system
Rules: represent knowledge
Backward chaining: can prove statements (think symbolic calculator)
- goal driven reasoning
- prove a rule is valid
- does not need facts that are not required for proof
Forward chaining: execute rules (think expert systems)
- fact driven reasoning
- executes all rules that can with current facts
- needs all avail facts
Performance issues may prevent usage of a rule engine in 'live' systems.
In the listing of "when to use a rule engine" he gives a case of:
- "When you know the constraints of the solution, but now a precise algorithm to reach it."
Could I use genetic programming to extract an algorithm from the rule engine?
- "When the algorithm is too complex, but a 'good enough' solution is acceptable"
A neural net is provided as a possible alternative here. He also points out the cost/time involved in properly training the net.
- "When we have to deal with imprecise or incomplete input"
- "When we suspect the solution will e a chain of exceptions and refinements to a generic rule"
When to avoid?
- when there is a clear algorithm
- critical performance
- if the solution is unlikely to change (hahaha)
Next up, a basic example explaining the how the logic works in a rule engine.
Then a little comparison of Java source with CLIPS.
The example, sorting, is contrived but, its simple enough to get the point across. The normal java is simpler until, special cases are added. This is where the Java becomes more complex and the CLIPS code can stay elegant.