Re: JESS: Jess error: Bad index
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: jess-users@sandia.gov 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 External- Address:edu.stanford.smi.protege.model.DefaultSimpleInstance) (:NAME Science_Instance_45) (:DIRECT-TYPE External-Address:edu.stanford.smi.protege.model.DefaultCls) (:DIRECT-INSTANCES ) RULE: (defrule e_201_links (object (Page-Status ?lRECOMMENDATION|REJECTED|CLASSIFIED| EXTRACTED|LIST) (is-a Processing-Monitor)) ?s - (object (is-a Suggestion-Recognizer) (What-to-Suggest ?kLINK|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-TEXTS] Values) (slot-get [PAGE] Links)) ?f ?c 201)) (assert (Processed Links ?k))) Help me please, Eunice 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 owner-jess- [EMAIL PROTECTED] To unsubscribe, send the words
Re: JESS: Jess error: Bad index
Well, the solution was to change the version of JessTab and Jess. Now I use Jess 6.0b3 and JessTab1.1. However, when I run from eclipse many errors are reported. Can you help me? Eunice 2005/11/1, Rich Halsey [EMAIL PROTECTED]: 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: jess-users@sandia.gov 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 External- Address:edu.stanford.smi.protege.model.DefaultSimpleInstance) (:NAME Science_Instance_45) (:DIRECT-TYPE External-Address:edu.stanford.smi.protege.model.DefaultCls) (:DIRECT-INSTANCES ) RULE: (defrule e_201_links (object (Page-Status ?lRECOMMENDATION|REJECTED|CLASSIFIED| EXTRACTED|LIST) (is-a Processing-Monitor)) ?s - (object (is-a Suggestion-Recognizer) (What-to-Suggest ?kLINK|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-TEXTS] Values) (slot-get [PAGE] Links)) ?f ?c 201)) (assert (Processed Links ?k))) Help me please, Eunice To unsubscribe, send the words
Re: JESS: Jess error: Bad index
Eunice, Please provide the exact code and error messages you are getting. Please try to figure out whether the problem is with Protege, JessTab and/or Jess before posting to this list. For example, copy key portions (e.g. function names, exception names) of the stacktrace you are getting and then try Googling for them. Often you will find answers listed in a FAQ or in a mailing list archive. Also, try searching the Protoge list archives/FAQ for JessTab. Rarely (if ever?) is a Protoge/JessTab related problem due to something in Jess. Good luck! alan Eunice Palmeira wrote: Well, the solution was to change the version of JessTab and Jess. Now I use Jess 6.0b3 and JessTab1.1. However, when I run from eclipse many errors are reported. Can you help me? Eunice 2005/11/1, Rich Halsey [EMAIL PROTECTED]: 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: jess-users@sandia.gov 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 External- Address:edu.stanford.smi.protege.model.DefaultSimpleInstance) (:NAME Science_Instance_45) (:DIRECT-TYPE External-Address:edu.stanford.smi.protege.model.DefaultCls) (:DIRECT-INSTANCES ) RULE: (defrule e_201_links (object (Page-Status ?lRECOMMENDATION|REJECTED|CLASSIFIED| EXTRACTED|LIST) (is-a Processing-Monitor)) ?s - (object (is-a Suggestion-Recognizer) (What-to-Suggest ?kLINK|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)