Well, there's no magic solution, but it should always be possible to
accomplish what you need by rewriting your rules. In the case of the
rules you've written, you might want to do something like this:
(defrule income-rule
(trait
(name ?trait-name)
(value ?trait-value))
=>
(if (and (eq ?trait-name INCOME)(< ?trait-value 50000)) then
(assert (rule-exec (num 1)(resolution success)))
else
(assert (there-were-facts-but-they-didnt-match))))
Then you can tell the difference between the two cases based on the
existence of the (there-were-facts-but-they-didnt-match) fact.
The (exists) CE is a useful way to have a rule fire only once even if
a pattern is matched many times -- this might come in handy.
I think Withers, Ryan(STL) wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hello all,
>
> I'm probably making this more difficult that it needs to be, but I thought
> I'd at least pose the question. I have a deftemplate, for which I could
> have multiple facts asserted, but in this example I'm just going to assert
> one.
>
> (deftemplate trait (slot type) (slot name) (slot value))
>
> (assert (trait (type DEMOGRAPHIC) (name INCOME)(value 1000)))
>
> Then I may have two rules that test to see what the value of HAIR_COLOR and
> INCOME is. My problem is I'm dealing with dynamic data, and so I can't
> determine if a rule didn't fire because it didn't meet the condition, or if
> it the fact just wasn't asserted in the first place. The rules for the fact
> above follow:
>
> (defrule income-rule
> (trait
> (name ?trait-name)
> (value ?trait-value))
> (test (and (eq ?trait-name INCOME)(< ?trait-value 50000)))
> =>
> (assert (rule-exec (num 1)(resolution success))))
>
> (defrule haircolor-rule
> (trait
> (name ?trait-name)
> (value ?trait-value))
> (test (and (eq ?trait-name HAIR_COLOR)(eq ?trait-value brown)))
> =>
> (assert (rule-exec (num 1)(resolution success))))
>
>
> In this case I know the hair color rule will never be fired, but how can I
> tell whether it is due to information not being asserted or the rule not
> firing. I think I remember seeing something on testing the not of a rule.
> If this is not possible, is there a way to verify a rule hasn't fired,
> besides testing for the inverse of the original condition and firing on
> that.
>
> Thanks for your help.
>
> Sincerely,
>
> Ryan
>
>
>
> ---------------------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
