Ernest:
Does this mean that Jess will become more of a goal-oriented rulebased programming
tool? Or, perchance good fortune ensues, incorporate full-opportunistic backward
chaining; sort of like the old Expert (C/C++ Rulebase from Neuron Data) used to do? I
don't know of ANY rulebase in Java that does true,
full-opportunistic backward chaining at this time. Including Advisor, JRules, OPSJ,
JEOPS or Jess. I'm sure that there is one - I just don't know about it. Yet. :-)
SDG
jco
-
James C. Owen
Senior KE
Knowledgebased Systems Corporation
6314 Kelly Circle
Garland, TX 75044
972.530.2895
[EMAIL PROTECTED] wrote:
The long-running debate between the people like yourself, who are surprised when
rules fire during a query, and those who want a query to trigger backward chaining,
and so are surprised if they don't, has been resolved -- and I think you could say
that you won! In recent versions of Jess 6.1 (which is at
RC1 right now, and if all goes well will be in final release by the end of this
week) the default is for rules to NOT fire during a query, but there's now a way to
let rules fire during a query on a case-by-case basis.
So what I would do, if I were you, would be to upgrade to 6.1RC1 and things will
behave by default just the way you'd like them to.
I think =?iso-8859-1?q?un=20ethix?= wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Hi,
Thanks for taking the time to read this.
I have a number of activated rules. The first of these rules to fire includes a
function call which includes a query iteration. However, the subsequent rules in
the conflict set (i.e. the subsequent activated rules) fire before the query call
completes. This behavior is best illustrated by an example:
Jess (run 1)
FIRE 1 MAIN::rule_1 f-6
== f-7 (MAIN::__query-trigger-myQuery)
FIRE 1 MAIN::rule_2 f-5, f-6
If the firing is left to run then the query will eventually return
== f-7 (MAIN::__query-trigger-myQuery)
but only after all other activated rules have fired.
My problem is that rule_2 depends upon the result of firing rule_1, and causes an
illegal operation (division by 0) as a result of rule_1 not returning first.
I am able to circumvent this by having an extra fact asserted by rule_1, which
rule_2 needs i.e. :
(defrule rule_1 =
(callQuery) (assert (foo)))
(defrule rule_2 ... (foo) = ...)
In this case, since rule_2 can only be activated after the query has returned, it
works...it does seem an illogical way of doing things though.
The release notes do mention something about the run-query command executing
'run(10)' - but this does not explain why subsequent rules don't fire after the
query returns.
Is there something that i'm missing here?
Thanks in advance,
Pol
-
Yahoo! Mail - For a better Internet experience
-
Ernest Friedman-Hill
Distributed Systems ResearchPhone: (925) 294-2154
Sandia National LabsFAX: (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]