Thanks for detailed reply, Ernest. There's just a couple of points I'd like to clarify a little more, if you don't mind... (my Qs inlined)
--- [EMAIL PROTECTED] wrote: > OK, well, there's always more than one way to do > things. Here's one > made up off the top of my head: Your "not" pattern > doesn't really mean > "not (count)". It means "not (count) even after > need-count was > asserted." Well, this really depend on how one treats backward-chaining. If one considers backward-chaining a fully automated engine activity, then "not (count)" == "not (count) even after need-count was asserted". Right? (I think you won't agree :)) >Therefore, you might consider changing > "not (count)" to > "(couldnt-create-count)" and writing your > goal-seeking rule like this: > > (defrule create-count-facts > (need-count ...) > => > (if (possible) then > (assert (count ...)) > else > (assert (couldnt-create-count)))) > That was my first thought, actually - in RHS add something as simple as (couldnt-create-count) if I can't create (count). Unfortunately, I cannot do that easily - RHS in my rule is SQL query, and it returns just counts for users, who really have counts. Asserting (couldnt-create-count) for ALL other users, would be difficult and expensive. As for adding another backward-chaining rule, how can I do that, so this second rule will fire after the first one? Thanks very much, Igor __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -------------------------------------------------------------------- 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] --------------------------------------------------------------------
