Running a rabbit trail on this thread. I think that newbies to Jess (and other rulebased systems) tend to code rules similarly to what they did in OO. It's the same problem as moving from procedural to OO: The tool and the syntax are OO but the thinking and the code are still procedural.
Thinking in a declarative manner requires just a bit more thought up front. If you use the goal-oriented approach to solving the problem, you might see things in a different light. I've always maintained that the monkey's and bananas problem is a classic for a reason: It teaches declarative thinking. First, iterate the primary goal. What is the main thing that you want to do? Consider, instead, a more practical problem: A customer walks into a bank and says good morning to the teller. Now, if you had to give the teller, who had never been a teller in a bank, instructions how would you give that person a complete list of instructions on how to handle any give situation? First you would initialize the situation, the objects in code. Your first goal then is to initialize system and gather initial data. Assume that the customer is well dressed (not that this should affect your thinking - a multi-millionaire in Texas might wear jeans and boots) and this might indicate one approach. A few questions would gather more information. Each question might change the approach. First goal, satisfy customer requirements, a list of one or more. Does the customer want to open an account, take out an auto loan, take out a personal loan, take out a home loan (mortgage) or open a savings account? Each goal has a different set of rules. If the first sub-goal is to take out a mortgage, there is then another set of data gathering and decisions to be made. Does the customer live in the state? Does the customer have a credit history? Etc. etc. Each sub-goal can spawn more sub-sub-goals that must be satisfied. Using concurrency, the last goal asserted will be on top. Depending on whether this is a universal solution or an existential solution, you might or might not retract each goal as it is satisfied. Regardless, all of this reflects back to how a human would think about a problem and then go about solving that problem. And declarative takes quite a bit more thinking that OO or procedural, but it's a much better approach to solving business problems. SDG jco -------------------------------- James C. Owen Senior Knowledge Engineer KnowledgeBased Systems Corporation 6314 Kelly Circle Garland, TX 75044 314.493.8445 GMAC 214.684.5272 Cell 972.530.2895 Office -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 12:21 PM To: [EMAIL PROTECTED] Subject: Re: JESS: confusion about rule activation I think =?iso-8859-1?q?un=20ethix?= wrote: [Charset iso-8859-1 unsupported, filtering to ASCII...] > > Hi, > > I would much appreciate it if you could help me with the following: > > I have a cicular program (with an exit rule, once the right conditions > are met) > > Now, inside that cyle, I have a rule, with some conditions (LHS). On > the RHS I have an output. The details are not so important. However, > the output (RHS) of the rule does not affect the conditions which will > detirmine whether the rule will fire (the LHS conditions). > > My (limited) understanding is the following: If the conditions for > that rule are met, then the rule is activated (and the rule is then > fired at the appropriate time). > > I think I am correct in saying that in Clips, this rule would only fire once (per cycle), whilst in Jess this would be an infinite loop. You are actually not correct. Modifying facts in either CLIPS or Jess has the same effect on rule activations. If you modify a fact on a rule's RHS, and the modified fact still matches on the LHS, then the rule will be re-activated. CLIPS definstances and Jess definstances, however, act differently. In CLIPS, an instance is essentially implemented using a separate fact for each slot. In Jess, a single fact corresponds to each entire instance, which means they act like unordered facts. This consistency is, in general, a good thing. You can mix facts and instances without worrying about different behaviors. > Whilst it is possible to, for example, have the RHS 'innactivate', > using flags for example - the rule from firing (and then re-activating > it at the start of the next cycle - this does seem to be an > unnecessary complication. > Well, by definition, it it were unnecessary, you wouldn't need to do it! As it is, though, that's the standard way of dealing with things. > My question is: is there some (probably very obvious) thing that I am > missing here? > Nope. We've discussed additional features for future releases that are relevant here, like the recent discussion on one-shot rules; you could search the archive. > Thankyou for your time. > > Pol > > > > > --------------------------------- > With Yahoo! Mail you can get a bigger mailbox -- choose a size that > fits your needs --------------------------------------------------------- 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] -------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
