On Mon, Jul 27, 2009 at 2:10 PM, Nick Tinnemeier <[email protected]> wrote:

> Thank you for your helpful replies. I guess the solution of extending the
> antecedent of the rules with one fact that is asserted and retracted before
> each run is more efficient than retracting and reasserting all facts?


Certainly so, and as it seems that only a smattering of your rules needs
this behaviour, then the "trigger" fact is to be preferred.

Interestingly, deleting and re-inserting the rules between (run) calls does
not re-trigger the rules.

-W


>
> I am implementing a prototype of a programming language with a predefined
> semantics, it is difficult to explain why exactly I want this behavior.
> Basically, most constructs translate naturally to Jess rules that assert and
> retract facts. For those rules it is not a problem (it's even convenient)
> that a rule only fires once, but one particular construct requires to fire
> (and call a user-defined function) each time its precondition is satisfied.
> I implemented this as rules of the form:
> (defrule myrule (precondition) => (function params))
>
> Nick.
>
>
> Wolfgang Laun wrote:
>
>  The following function retracts and reasserts all facts in the engine.
>> Except for the fact ids, the working memory should be the same after the
>> call, but all rules will fire over again.
>>
>> (deffunction rewind ()
>>   (bind ?e (engine))
>>   (bind ?it (?e listFacts))
>>   (while (?it hasNext)
>>      (bind ?fact (?it next))
>>      (?e assertFact (?e retract ?fact) )
>>   )
>> )
>>
>> -W
>>
>>
>> On Thu, Jul 23, 2009 at 4:22 PM, Ernest Friedman-Hill 
>> <[email protected]<mailto:
>> [email protected]>> wrote:
>>
>>    I can't think of any other way to achieve that behavior, so I
>>    guess you can go ahead and do it. You might tell us *why* you want
>>    that behavior, though, because maybe there's another solution.
>>
>>
>>
>>
>>    On Jul 23, 2009, at 5:02 AM, [email protected] <mailto:[email protected]>
>>    wrote:
>>
>>        Dear Jess users,
>>
>>        I have been looking in the manual and mailing list for some
>>        time but
>>        couldn't find an answer. Maybe you could help me on this one.
>>
>>        Rules only fire once each time their condition is true,
>>        provided that the
>>        facts the condition refers to are not modified, i.e. if I only
>>        have one
>>        rule:
>>
>>        (defrule test
>>         (fact)
>>         =>
>>         (printout t "fired!" crlf))
>>
>>        it will only fire once as (fact) is not modified.
>>
>>        I am running Jess from Java. Even when I invoke the rete.run()
>>        method
>>        twice the rule still fires once. I want a behavior in which
>>        the rule fires
>>        once each time I call the run() method. What I mean is that two
>>        consecutive calls to run should produce as output:
>>        fired!
>>        fired!
>>
>>        Resetting the engine (rete.reset()) is not a satisfactory
>>        solution,
>>        because I don't want to reset my working memory also. Neither is
>>        implementing a rule:
>>
>>        (defrule test
>>         ?f <- (fact)
>>         =>
>>         (retract ?f)
>>         (printout t "fired!" crlf)
>>         (assert ?f))
>>
>>        as this will result in firing the rule ad infinitum during one
>>        run.
>>
>>        I considered enriching the LHS of all my rules with a special
>>        designated
>>        fact, say (fire-again) and retract and assert it in between
>>        each call to
>>        run, i.e.:
>>
>>        (defrule test
>>               (fire-again)
>>               (fact)
>>               =>
>>               (printout t "fired!" crlf)
>>        )
>>
>>        (reset)
>>        (assert (fire-again))
>>        (run)
>>        (retract-string "(fire-again)")
>>        (assert (fire-again))
>>        (run)
>>
>>        and this seems to get me the behavior I want.
>>
>>        Before I rush to preprocessing all my rules in Java I wondered
>>        if there
>>        are other (better) ways to get the behavior I want?
>>
>>        Kind regards,
>>
>>        Nick.
>>
>>
>>
>>
>>  --------------------------------------------------------------------
>>        To unsubscribe, send the words 'unsubscribe jess-users
>>        [email protected] <mailto:[email protected]>'
>>        in the BODY of a message to [email protected]
>>        <mailto:[email protected]>, NOT to the list
>>        (use your own address!) List problems? Notify
>>        [email protected] <mailto:[email protected]>.
>>
>>  --------------------------------------------------------------------
>>
>>
>>    ---------------------------------------------------------
>>    Ernest Friedman-Hill
>>    Informatics & Decision Sciences, Sandia National Laboratories
>>    PO Box 969, MS 9012, Livermore, CA 94550
>>    http://www.jessrules.com
>>
>>
>>
>>
>>
>>
>>
>>
>>    --------------------------------------------------------------------
>>    To unsubscribe, send the words 'unsubscribe jess-users
>>    [email protected] <mailto:[email protected]>'
>>    in the BODY of a message to [email protected]
>>    <mailto:[email protected]>, NOT to the list
>>    (use your own address!) List problems? Notify
>>    [email protected] <mailto:[email protected]>.
>>    --------------------------------------------------------------------
>>
>>
>>
>
>
> --------------------------------------------------------------------
> 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].
> --------------------------------------------------------------------
>
>

Reply via email to