CLIPS> (defrule r1
(not (digit ?))
=>)
CLIPS> (defrule r2
(not (and (digit 1) (digit 2)))
=>)
CLIPS> (defrule r3
(and (not (digit 1)) (not (digit 2)))
=>)
CLIPS> (deffacts digits
(digit 0) (digit 1) (digit 2) (digit 3) (digit 4))
CLIPS> (reset)
==> f-0 (initial-fact)
==> Activation 0 r3: f-0,,
==> Activation 0 r2: f-0,
==> Activation 0 r1: f-0,
==> f-1 (digit 0)
<== Activation 0 r1: f-0,
==> f-2 (digit 1)
<== Activation 0 r3: f-0,,
==> f-3 (digit 2)
<== Activation 0 r2: f-0,
==> f-4 (digit 3)
==> f-5 (digit 4)
CLIPS>
The above might not make sense or mean anything to you, but it made me quite happy.
6 kommentarer:
haha.... I got a good laugh from that. doing too much rule engine work may warp your mind :)
Yes, I've noticed ;-)
I was in the middle of determining Not and Exists behaviour and when it turned out CLIPS *actually* behaves as I hoped it would. I had to write something but I was very pressed for time and that's why it's so short. I'm planning to expand my thoughts in a later post though.
yeah, the way clips does it, it ends up adding activations and then immediately removing it.
the way I implemented it in jamocha, it doesn't need to do that. I believe Gary of CLIPS changed how NOT works so that it no longer needs to do that.
But isn't that correct behaviour? If you do (run) before you assert anything those activations should fire even though it's probably not a very common usage pattern ;-)
the immediately removal is the correct behavior, though not necessarily efficient :)
by not having the engine do that extra work, it can do other things. according to gary, when he made the change, it improved the performance a bit. there's an experimental build up on the clips download site.
http://www.ghg.net/clips/download/other/
I'm probably misunderstanding something (as usual) but it seems that CLIPS 6.30 (the latest version I could find) does the same thing as in my example (CLIPS 6.24)
CLIPS> (reset)
==> f-0 (initial-fact)
==> Activation 0 r3: f-0,,
==> Activation 0 r2: f-0,
==> Activation 0 r1: f-0,
==> f-1 (digit 0)
<== Activation 0 r1: f-0,
==> f-2 (digit 1)
<== Activation 0 r3: f-0,,
==> f-3 (digit 2)
<== Activation 0 r2: f-0,
==> f-4 (digit 3)
==> f-5 (digit 4)
I see what you mean though. The reset command in my example shouldn't *have* to put those activations on the agenda provided that it's "smart" enough.
I just don't understand how you've implemented it. But that just gives me more to read during the weekend :-)
Skicka en kommentar