Re: JESS: multiple shadow fact templates
I think Scott Moss wrote: > >The order in which rules are fired depends first on the conflict > >resolution strategy, but if two rules are of equal priority by that > >criterion, then they'll fire in an arbitrary order that just falls out > >of the Rete network implementation. That order is affected by, but > >isn't equal to nor even easily predicatable from, the order in which > >the rules are defined. > > > That's good to know since one of our developments will be to implement a > conflict resolution strategy sound and consistent with a formal logic > or, more likely, several conflict resolution strategies based on > several logics. The ability to do this is, I think, one of the great > strengths of Jess from a modeller's point of view. I imagine that, in > so doing, the order of the defrule statements can be entirely > irrelevant. Is that right? Only if you replace the existing arbitrary-but-not-random order with your own arbitrary-but-not-random order. As a trivial example, these two rules: (defrule rule-1 => ) (defrule rule-2 => ) will fire in an arbitrary order which will definitely depend on the order in which they're defined. To remove that dependency in your strategy implementation, you'd have to order them based on dictionary ordering of their names, or some other arbitrary criterion. But the point is that yes, you could do that. - Ernest Friedman-Hill Advanced Software Research Phone: (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]
Re: JESS:Modular deffacts problem
I think David Firmin wrote: > > I'm trying to use deffacts with a specific module, but am having some > problems changing out of that module once the deffacts has taken place. > At present, I'm doing the following (although I've simplified the code > here, the sense remains the same): I'm afraid you've simplified things a little bit too much. The important points are 1) when and where the defclass for your Java objects is being done, 2) exactly how the object is being put into working memory, and 3) what version of Jess you're using. Jess 7.0b4 was released just today, and it fixes a bug in earlier 7.0 releases related to definstances in the presence of multiple modules, although the symptoms don't sound precisely right. - Ernest Friedman-Hill Advanced Software Research Phone: (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]
Re: JESS: multiple shadow fact templates
[EMAIL PROTECTED] wrote: If the defrules are ordered as above, then no shadow facts are created for producer. If the producers rule is defined first, then three producers shadowfacts are created followed by seven agents shadow facts. Is it the case that there cannot be two points to a single Java object? Is that the reason or is there some other reason why the ordering of the defrules determines the result? An object can be added to working memory just once, so once those three are defined using the one template, they can't be added again with the other. right. I have read that and now have a better understanding of its implications. Thanks for that. This is probably a silly thing to do and work-arounds are easy to devise. On the other hand, is it a good idea for the order in which defrule is called to determine the outcome? The order in which rules are fired depends first on the conflict resolution strategy, but if two rules are of equal priority by that criterion, then they'll fire in an arbitrary order that just falls out of the Rete network implementation. That order is affected by, but isn't equal to nor even easily predicatable from, the order in which the rules are defined. That's good to know since one of our developments will be to implement a conflict resolution strategy sound and consistent with a formal logic or, more likely, several conflict resolution strategies based on several logics. The ability to do this is, I think, one of the great strengths of Jess from a modeller's point of view. I imagine that, in so doing, the order of the defrule statements can be entirely irrelevant. Is that right? regards Scott 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]
JESS:Modular deffacts problem
Hi I'm having a problem with deffacts and modules I was hoping someone could help me out with. I'm trying to use deffacts with a specific module, but am having some problems changing out of that module once the deffacts has taken place. At present, I'm doing the following (although I've simplified the code here, the sense remains the same): (defmodule ONE) (defmodule TWO) (defmodule THREE) (set-current-module MAIN) (deftemplate TWO::template-for-module-two (slot slot1) ) (deffacts some-facts (TWO::template-for-module-two (slot1 value1)) (TWO::template-for-module-two (slot1 value2)) ) ;;; some business logic rules (reset) Once the code has been parsed into the Rete [ using executeCommand(String)] I then subsequently assert some shadow fact objects before running the rete. The problem is that the shadow facts are asserted into the TWO module rather than the MAIN module as I would like them to be. It seems my call to set-current-module is being overridden by the deffacts construct asserting facts straight into the TWO module. Is there a way around this so that once the reset command has been called, the focus shifts back to MAIN automatically? Any help would be gratefully received. Many thanks Regards David 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]
Re: JESS: multiple shadow fact templates
I think Scott Moss wrote: > If the defrules are ordered as above, then no shadow facts are created > for producer. If the producers rule is defined first, then three > producers shadowfacts are created followed by seven agents shadow facts. > > Is it the case that there cannot be two points to a single Java object? > Is that the reason or is there some other reason why the ordering of the > defrules determines the result? > An object can be added to working memory just once, so once those three are defined using the one template, they can't be added again with the other. > This is probably a silly thing to do and work-arounds are easy to > devise. On the other hand, is it a good idea for the order in which > defrule is called to determine the outcome? > The order in which rules are fired depends first on the conflict resolution strategy, but if two rules are of equal priority by that criterion, then they'll fire in an arbitrary order that just falls out of the Rete network implementation. That order is affected by, but isn't equal to nor even easily predicatable from, the order in which the rules are defined. - Ernest Friedman-Hill Advanced Software Research Phone: (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]
JESS: Announcing Jess 7.0b4
Hi Folks, We're pleased to announce the availability of the latest release of Jess, the rule engine for the Java platform, at the usual location: http://herzberg.ca.sandia.gov/jess/download.shtml This release adds a lot of polish to Jess 7 as we approach the final version. There are a number of bug fixes, enhanced features for the JessDE debugger, and a new simplified API for embedding Jess in Java applications. As usual, comments and questions are welcome on the mailing list at jess-users@sandia.gov or directly to me at [EMAIL PROTECTED] >From the changelog: Fix slot-specific behavior for "null" property names in change events (thanks Shan Ming Woo). Fix SAX parse error for facts with no slots (thanks Wang Dong.) Fixed definstance name resolution across modules (Woo). New "map", "filter", and "list" functions for functional programming. Run configurations are reused in Eclipse. Can pass command-line arguments from Eclipse Run dialog. Defglobals show up in JessDE debugger. Spaces in path names won't confuse jess.bat (thanks Eric Schubert.) Fix deadlock in debugger when stepping over (read) and (readline) calls (thanks Jim Goodwin.) "Start suspended" checkbox in debugger. Can specify jess.Main alternate in launch configuration. Tiny font in manual navbar fixed. New URL for Jikes in manual. New "quick start" section in manual, and a new simplified engine API as described therein: mark(), resetToMark(), add(), addAll(), getObjects(). - Ernest Friedman-Hill Advanced Software Research Phone: (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]
JESS: multiple shadow fact templates
I tried to have two definstance calls on the same Java class. Specifically, (defclass market Market) (defclass agent TradingAgent) (defclass producer TradingAgent) Instances of class Market have two public members: agentsList and producersList where the latter is a subset of the former. These are then instantiated in two rules: (defrule agents (market (agentsList $?alist)) => (foreach ?a ?alist (definstance agent ?a static))) and (defrule producers (market (producersList $?pList)) => (foreach ?p ?pList (definstance producer ?p static))) In testing these rules, there were 10 TradingAgents in agentsList, of which three were also in producersList. If the defrules are ordered as above, then no shadow facts are created for producer. If the producers rule is defined first, then three producers shadowfacts are created followed by seven agents shadow facts. Is it the case that there cannot be two points to a single Java object? Is that the reason or is there some other reason why the ordering of the defrules determines the result? This is probably a silly thing to do and work-arounds are easy to devise. On the other hand, is it a good idea for the order in which defrule is called to determine the outcome? 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]
Re: JESS: Jess error: Bad index
Hello, as a new JESS user, this email was very helpful, thanks! Does anybody have any information about websites that have similar design information, or even case studies? Thanks, Kip Kip Lubliner Developer, HSBC Securities 646-344-3113 [EMAIL PROTECTED] wrote on 11/01/2005 08:41:39 AM: > While this reply does not deal directly with the rule under discussion, I > continue to be amazed at the approaches used to "engineer" rule-based > systems (which ultimately fail) and how little we hear from the the Olympic > geniuses who are employed by the vendors (unless you are willing to pay > $300/hr). > > To me, rules engineering (at the requirements/analysis level) is a > discipline that is simple: > > (1) discover the "rules" that are found/described in the textual portions of > the requirements. > > (2) describe possible "information entities" that the rule's LHS uses to > test for truth and that the rule's RHS would take action with > (create/update/delete). > > (3) model this information in such a way that the potential interactions > between the rules can be documented, i.e. what conditional testing by LHS > would be impacted by actions of the RHSs of other rules. > > (4) elaborate on this information with a high-level "control" system to > preclude the possibility of undesirable conflicts between rules. > > Ironically, much of this can be set down in an Excel spreadsheet. The > principal problem is that the merit of this approach seems to be lost on > people until they have endured multiple project failures (myself included) > and begin to look at rules engineering as something that is 180 degrees out > of phase from ordinary procedural programming - it is a radically different > paradigm that is not intuitively obvious to the uninitiated. > > Once this technique becomes second nature to the rules designer, success > (and $) will follow. I offer this advice free to beginners, but as a > consultant I do not work for free. > > Rich Halsey > - Original Message - > From: "James C. Owen" <[EMAIL PROTECTED]> > To: > Sent: Monday, October 31, 2005 11:53 PM > Subject: Re: JESS: Jess error: Bad index > > > > OK, this has been in my mail box for almost four hours and no one has > > said anything - so, here goes. FIRST - don't write B I G rules !!! > > Second, half of the logic is in the right hand side (AE) of the rule. > > Why? Third, there is absolutely NO explanation of what the rule does or > > what it is supposed to do, etc., etc. etc. Pretty much, this is written > > like a lot of rules that I see every day. Rules that show a thought > > process gone amok. So, break it down, think it out, make it simple, THEN > > see what's wrong with the logic. Actually, what is "wrong" with the rule > > is in the error message itself; apparently Jess thinks that there is a > > call to a Vector in the LHS of the rule and that index 123 is a bad > > index. Probably is. > > > > On the other hand, even if you fix that part of the rule, it should still > > be taken out and shot for breaking the first three guidelines mentioned > > above. Anyway, it's almost midnight. Time for all good little rule boys > > to be in bed. Preferably with someone else. :-) > > > > SDG > > jco > > > > On Oct 31, 2005, at 8:35 PM, Eunice Palmeira wrote: > > > >> I use Jess 6.1 p4 and JessTab 1.3, when a run big rules like the rule > >> below the Jess report an error: > >> > >> Jess reported an error in routine ValueVector.get > >> while executing rule LHS (MTELN) > >> while executing rule LHS (TECT). > >> Message: Bad index 123 in call to get() on this vector: > >> (MAIN::object (is-a :JESS-DEFTEMPLATE) (is-a-name ":JESS-DEFTEMPLATE") > >> (OBJECT > >> Address:edu.stanford.smi.protege.model.DefaultSimpleInstance>) > >> (:NAME "Science_Instance_45") (:DIRECT-TYPE > >> ) > >> (:DIRECT-INSTANCES ) > >> > >> RULE: > >> (defrule e_201_links > >> (object (Page-Status ?l&RECOMMENDATION|REJECTED|CLASSIFIED| > >> EXTRACTED|LIST) > >> (is-a Processing-Monitor)) > >> ?s <- (object (is-a Suggestion-Recognizer) (What-to-Suggest > >> ?k&LINK|LINK-TEXT) > >> (Class-to-Suggest ?c) (Cases $?cs)) > >> ?f <- (Result (Page-Status ?)) > >> (not (Processed Links ?k)) > >> (object (is-a Agent) (treats-Class ?ca) (name ?nsa)) > >> ?g <- (object (is-a Case) (Concepts $?cb&:(> (length$ $?cb) 0)) > >> (Keywords $?k) (Absent-Concepts $?ac)) > >> (test (and > >> (integerp (member$ (instance-address ?g) $?cs)) > >> (or (eq ?c ?ca) (subclassp ?c ?ca > >> => > >> (if (eq ?k LINK) then > >> (insert-link ?nsa (search-in-list (create$ (words-of-concepts > >> $?cb) $?k) > >> (slot-get [LINKS] Values) (slot-get [PAGE] > >> Links)) ?f ?c 201) > >> else (insert-link ?nsa (search-in-list (create$ > >> (words-of-concepts $?cb) $?k) > >> (slot-get [LINKS-
