I think Igor Gorbunov wrote:
> 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 :))
You understand me, and I understand you. Who could ask for anything
more? :)
> 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.
>
After thinking about this, I realized you could make good use of
defmodules here to enforce the sequence you want. Here's a basic
outline of what you want to do:
- Create a module SQL
- Put the satisfy-need-count rule into SQL
- Declare satisfy-need-count to have the auto-focus property.
- satisfy-need-count looks something like
(defrule SQL::satisfy-need-count
(declare (auto-focus TRUE))
(user (id ?id))
(need-count (id ?id))
=>
(bind ?count (fetch-from-database ?id))
(if (there was a count) then
(assert (count (id ?id) (count ?count)))
(return))
- Back in module MAIN, put the deal-with-countless-user rule:
(defrule MAIN::deal-with-countless-user
(user (id ?id))
(not (count (id ?id)))
=>
(do-whatever-it-is-you-want))
- Presumably, there is some other rule in MAIN that needs a count
fact, like this:
(defrule MAIN::process-user-count
(user (id ?id))
(count (id ?id))
=>
(do-something))
Now, when a user fact is asserted, if there is no count fact,
deal-with-countless-user will be activated, and Jess will also assert
a need-count fact based on process-user-count. Both of these things
happen during the time that the user fact is being asserted. No rules
will fire in between these events. The need-count and the user
together will activate satisfy-need-count, which will switch the focus
to module SQL, guaranteeing that the next rule that fires, without
exception, is satisfy-need-count. Once it has fired, focus will return
to MAIN. If there is a count fact, deal-with-countless-user will be
deactivated. If satisfy-need-count did not produce a count, then
deal-with-countless-user will still be activated, and will fire.
This is a nice setup, because it's more robust and more efficient than
using salience, and it works no matter how many user facts are
asserted at once. It even works if satisfy-need-count works by
selecting ALL available user counts, and asserting them all as facts,
to minimize the number of queries.
What do you think?
---------------------------------------------------------
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]
--------------------------------------------------------------------
