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