I think Sidney Bailin wrote: > > > > (defrule ground3-4 > > (need-subgoal2 ?x&bird|dog) > > => > > (assert (subgoal2 ?x))) > > Ernest - Isn't this synonymous with my ground3 and ground4 rules taken > together? I don't quite see how it helps. The difference is that the invisible (not) CE for this rule is different, because it specifies the exact subgoal2's it can generate - i.e., it will only be activated/deactivated with regard to the exact facts (need-subgoal2 bird) or (need-subgoal2 dog) whereas your other rules would also fire for (need-subgoal2 chicken), even though neither of them could cons up a chicken even if they wanted to. The bogus subgoal2 thus generated could possibly block a desired one from being asserted. Again, use ppdefrule to see the difference. > > Or maybe you're not saying it helps, but just pointing out the implicit > meaning of my pair of rules (ground3 and ground4) and how it doesn't > account for the case of (need-subgoal2 cat). Since I'm thinking from > a Prolog point of view, allowing the programmer this incompleteness > is precisely the value of backtracking. I guess we're saying the same > thing in two different ways. More or less, but there is a subtle difference. It's perfectly fine to have 27 rules that all respond to (need-subgoal2 ?). But if one of them sees (need-subgoal2 chicken) it's buggy if it asserts (subgoal2 cat); this is what's wrong with boath ground3 and ground4. They need to be sure to assert only the fact that was requested. Alternatively, the 27 cases can only match specific need-subgoal2 facts, and again, can thereby do the right thing as well. Do you understand what I'm saying? > > I know that this issue of controlling superfluous firings is a real > headache. Since the issue boils down to deciding which matches may still > be useful and which aren't, it seems application-dependent. Yeah, that's how it seems to me. Somehow, though, Prolog manages to be defined in such a way that backtracking can be done in a generally useful way. > > My intuition is that the desired behavior cannot be achieved by Jess > itself without (in effect) implementing an additional data structure > that represents the attempt to achieve a goal (that is, a pattern > for which backchaining is enabled). Implementing such a structure > explicitly (and the algorithms to go with it) is not a horrendous task, > but how it would co-exist with Rete I'm not sure. Yeah, that's the thing. Jess's current implementation is a clever hack (which I did not invent; rather it was done first in ART,) mapping backwards chaining onto the inherently forward-chaining Rete algorithm. > It's probably > safer to implement a version that is formulated at the user level > in terms of current Jess constructs, and then perhaps "internalize" > it into Jess itself. > > So ... Since I need this type of backtracking behavior in my > application, > if I can figure out how to do it in a way that seems portable, I will > send it over for your consideration. I'll look forward to seeing what you can come up with. > > Sidney Bailin > Knowledge Evolution, Inc. > > --------------------------------------------------------- Ernest Friedman-Hill Distributed Systems Research Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 Org. 8920, MS 9012 [EMAIL PROTECTED] PO Box 969 http://herzberg.ca.sandia.gov Livermore, CA 94550 --------------------------------------------------------------------- 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] ---------------------------------------------------------------------
