Excuse my buttinsky but I haven't responded to a Jess email in a really
long time and I was having withdrawal symptoms.  ;-)  Anyway, it would
seem that a rulebase is the wrong tool to use for your problem UNLESS
you just want to prove your point.  (I once had a friend who wrote a
word processor in COBOL just to prove that he could do it.)  Normally a
rulebase is used when the code is not procedural, when the problem set
is extremely complex, when the rules are subject to frequent change,
etc., etc.  (See the book.)

What you have described *_seems_* to be more of a procedural problem
that is normally best solved using procedural code, such as C, Pascal,
C++ or Java rather than a declarative language, such as Jess. (I know:
C++ and Java are OO.  But they are not declarative.)  This is something
that I see quite often.  A rulebase is a really cool tool so I've seen
it used for GUI data validation, small sets of rules to manage data flow
that was static in nature, and lots of other poor uses.  Usually with
lots of priorities (more than three is lots) because the solution to the
problem really was procedural in nature, not declarative.

The very fact that you will have to add an extra condition to the rules
should not dramatically affect the performance.  I you time it both
ways, you will probably find that this adds very little to the overall
time used.

SDG
jco
 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Raoul Jdrvis
Sent: Wednesday, August 06, 2003 8:48 AM
To: [EMAIL PROTECTED]
Subject: RE: JESS: Querying a fact

Thank you for your reply. 
Unfortunately I cannot use this method since there are cases when a rule
has to be fired more than once. There are cases when there are cycles in
the "graph" with cycle length bigger than one (i.e. no node will point
to itself directly). Rules have stop conditions to prevent them looping
indefinetly.

So I've used timestamp slot in facts that are updated when the fact is
(re)evaluated and have a test condition on the LHS that checks that the
fact's arguments' timestamps must be bigger than the fact's own
timestamp. 

It means an extra condition to check but I guess it's the only way to
achieve what I am trying to do ? 
(and at least the test evaluation should be faster than the extra firing
of the rule).

Best regards,
Raoul

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 06, 2003 4:37 PM
To: [EMAIL PROTECTED]
Subject: Re: JESS: Querying a fact


The general trick is to write the rule such that it doesn't match
after the value is set; i.e.,

;; default value is the symbol UNDEFINED
(deftemplate formula (slot ...) (slot value (default UNDEFINED)))

(defrule set-value
  ?f <- (formula ... (value UNDEFINED))
  =>
  ;; Fact won't match this rule anymore
  (modify ?f (value 37)))

Jess 7 is going to provide other ways of dealing with this particular
situation. 

I think =?iso-8859-4?Q?Raoul_J=E4rvis?= wrote:
[Charset iso-8859-4 unsupported, filtering to ASCII...]
> Hello,
> 
> I have the following small problem:
> 
> I am using rules to perform computation on a set of formulas.
> Basically for every fact I have a rule that specifies how to calculate
the value (slot) for this fact.
> So on the LHS of the rule I am binding the facts whose values are
used/needed as arguments for calculating the fact's value. Once the
value is calculated I need to modify the fact to update its value. 
> So my question is, how can I bind the fact to be calculated on the
RHS? If I bind it on the LHS of the rule, then the modification of the
fact by the same rule will put the rule back on the agenda and it will
be fired again, although the "argument" facts that would affect the
calculation result have not changed. So basically every rule is fired
one "extra" time. How can I prevent that. Can I bind the fact that I'm
calculating on the RHS or are there any other solutions for this
problem?
> 
> Thank you in advance,
> Raoul
> 



---------------------------------------------------------
Ernest Friedman-Hill  
Distributed Systems Research        Phone: (925) 294-2154
Sandia National Labs                FAX:   (925) 294-2234
PO Box 969, MS 9012                 [EMAIL PROTECTED]
Livermore, CA 94550         http://herzberg.ca.sandia.gov

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

--------------------------------------------------------------------
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