Hi All, I have mentioned Haley's (ART's) approach to Ernest several times. :-) However, it is understandable that he wouldn't want to glom something onto Jess at this late stage in its lifecycle. A ground-up redesign with native backward chaining would be awesome. It all boils down to whether or not there is a need for such a tool and whether or not it can be funded -- not to mention whether or not Ernest or another developer wants that long-term commitment.
Cheers, Jason On Tue, Aug 26, 2008 at 12:58 PM, <[EMAIL PROTECTED]> wrote: > Greetings: > > I'm probably highly prejudiced, but I've always felt that the greatest > full-opportunistic, Backward Chaining Rulebase was the old Neuron Data > Nexpert, later called ND Expert. The GUI alone would make you fall in love > with it. It "used" objects in it's construction but it was like > Object-Oriented on steroids. If you can find someone with Fair Isaac who > still has the manuals they make for really interesting reading. > > While debugging was not a "snap" it wasn't terribly difficult either. It's > main drawback was that the text file that held the rules was done with the > old C routines and the variable (slot) description had to be in EXACTLY the > right place in the string. > > Advisor was supposed to be the Expert replacement but, unfortunately, > Advisor was nothing like Expert. Even though Expert was a C/C++ system, it > ran on 26 different platforms at the time, including VAX, MacIntosh, PC's, > Unix, Xenix, and even on mainframes. It's still available from FIC but you > have to really want it and not Advisor. Supposedly, you can even get the > source code for it, but I haven't checked that part out yet. > > SDG > jco > > > Quoting Peter Lin <[EMAIL PROTECTED]>: > > what about implementing the approach Paul Haley used in ART for >> backward chaining? >> >> >> >> http://haleyai.com/wordpress/2008/03/11/goals-and-backward-chaining-using-the-rete-algorithm/ >> >> paul recently posted his old paper on his blog. >> >> peter >> >> On Tue, Aug 26, 2008 at 12:40 PM, Ernest Friedman-Hill >> <[EMAIL PROTECTED]> wrote: >> >>> On Aug 26, 2008, at 11:55 AM, Marcin Krol wrote: >>> >>>> >>>> I have to say that daisy-chained backward-chaining rules are decidedly >>>> non-trivial (and therefore harder to write and debug), while >>>> forward-chaining rules are very easy to understand (at least for me). >>>> >>>> I'm writing about Jess in my thesis on AI techniques, and so I wanted to >>>> ask you a few questions - is backward-chaining is really valuable in >>>> practice, outside of subjects like calling queries to databases (like in >>>> the example you give in "Jess in Action")? >>>> >>>> If so, where do you think it is most useful? Are there any problems that >>>> are awkward to code using forward-chaining while they are more natural >>>> to code using backward-chaining rules? >>>> >>> >>> >>> I think the most important applications have been the query-like ones. >>> There >>> are certainly >>> plenty of techniques that work well with classical backward-chaining >>> rules, >>> but really can't be >>> implemented using Jess's restricted form of backward chaining >>> . >>> >>>> >>>> How do you think backward-chaining adds to the expressive power of Jess >>>> understood as language? Is it worth the effort, both for rule engine >>>> developer and for the rule engine user? >>>> >>> >>> I think it *could* add tremendously to the expressiveness of the language >>> if >>> it were carried >>> further. There are a lot of problems that can be expressed elegantly with >>> backtracking, for example. >>> There have been some user-modified versions of Jess that implement >>> backtracking concepts, but none of them >>> in an elegant way, AFAIK. Right now I think the truth is that beyond the >>> query-like applications (which are >>> equivalent in many ways to "finders" in JRules), Jess's backward chaining >>> hasn't seen widespread use. >>> >>> >>>> >>>> I have sort of stumbled on one limitation of backward-chaining in Jess: >>>> constraints on slots, I found I couldn't call a function on slot: >>>> >>>> Jess> Jess reported an error in routine ReteCompiler.addRule. >>>> Message: Can't use funcalls in backchained patterns __data. >>>> >>>> Is there a way around that? Or am I misunderstanding the problem, >>>> because one perhaps doesn't want to constrain slots in backward-chained >>>> rules as finding their values is the goal of this part of rule engine >>>> operation (as constraints would simply prevent firing one of b-c rules >>>> in the chain of reasoning in some cases, like it happened in my >>>> uncorrected example)? >>>> >>> >>> >>> There's no way around it in the current version of Jess. As you know, >>> goals >>> are represented >>> as regular facts, and stored in regular working memory. For anything >>> other >>> than literal constraints to >>> be usable in goals, there would need to be a way of representing the >>> constraint in the fact itself, and >>> storing that representation in working memory. While not impossible to >>> implement, this would impact many parts >>> of the Jess codebase. >>> >>> Another approach would be to store goals not in working memory, but in a >>> different >>> structure altogether, one designed from the beginning to accommodate >>> their >>> requirements. >>> In retrospect this is probably how Jess's backward chaining should have >>> been >>> implemented >>> in the first place. >>> >>> >>> --------------------------------------------------------- >>> 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]' >>> 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] > -------------------------------------------------------------------- > > -- ----------------------------------------------------------- Jason Morris Morris Technical Solutions LLC [EMAIL PROTECTED] (517) 304-5883
