Re: JESS: Odd accumulate behavior with identical 'result' variable names

> I have been unsuccessful in exactly replicating my issue.  I do  
> believe
> that I still got accumulate to behave unexpectedly, however.  I  
> will note
> that I tested it in the version my company is running (some old 7.0
> version), the 7.0p2 version, and the new 7.1b3 version.  This issue  
> occurs
> in 7.0, 7.0p2, but appears to be corrected in 7.1b3.
>
> This time, instead of matching facts that it shouldn't have, the  
> second
> rule appeared to do the opposite this time and wasn't matching  
> facts that
> it should have.  If I turn the first rule off, the second will work  
> fine.
> But, if I have both running, the behavior presents itself.
>
> I can send a zip file of my eclipse project j-unit test that  
> highlights the
> issue.

>
>
>
>
>
>              "Ernest
>              Friedman-Hill"
>              
> <ejfried@...                                          To
>              ov>                       "jess-users"
>              Sent by:                  <jess-users@...>
>              owner-jess-
> users@                                          cc
>              sandia.gov
>                                                                    
> Subject
>                                        Re: JESS: Odd accumulate  
> behavior
>              04/01/2008 08:42          with identical 'result'  
> variable
>              PM                        names
>
>
>              Please respond to
>              jess-users@sandia
>                    .gov
>
>
>
>
>
>
> My simple attempts at duplicating this in Jess 7.0p2 or 7.1b2 failed.
> Can you check what version you're using? If it's older, can you try
> with a current build?
>
>
>
> On Apr 1, 2008, at 6:15 PM, DCWYRICK@... wrote:
>
>>
>> I noticed some odd behavior with the accumulate function.  I've got
>> two
>> very similar rules
>>
>> 1) validates a string based on a fact and asserts an error fact if  
>> the
>> string is incorrect
>> 2) validates a string based on a fact and asserts a different fact
>> which is
>> used to correct the string later
>>
>> I used the accumulate function to accomplish this, because one of any
>> possible values for this 'string' are considered to be acceptable.
>> Since
>> the two rules had minute differences, I copied the rule text,
>> changed the
>> name, and changed the minor details.  I left the accumulate
>> variable the
>> same in both rules, and it was named ?result.
>>
>> rule 1 accumulate:
>>   ?someList <- (accumulate (bind ?result (create
>> $))                     ;;
>> initializer
>>                (bind ?result (create$ ?result (...str from ?
>> fact...)))  ;;
>> action
>>                ?
>> result                                                  ;;
>> result
>>                (SOME-FACT-NAME ?fact
>>                  &:(...condition1...)
>>                  &:(...condition2...)
>>                )
>>
>> rule 2 accumulate:
>>   ?someList <- (accumulate (bind ?result (create
>> $))                     ;;
>> initializer
>>                (bind ?result (create$ ?result (...str from ?
>> fact...)))  ;;
>> action
>>                ?
>> result                                                  ;;
>> result
>>                (SOME-FACT-NAME ?fact
>>                  &:(...condition1...)
>>                  &:(...condition2...)
>>                  &:(...condition3...)
>>                )
>>
>> The first rule worked fine, and generated its error fact.  However, I
>> noticed that the 2nd accumulate function seemed to be matching on
>> facts
>> that it should not have, and firing.  The condition 1 and condition
>> 2 were
>> filtering just fine, but the 3rd condition was not filtering out
>> what it
>> should have been.  It was funny, because I even placed the same
>> condition 3
>> check on the RHS of the rule and they would print out FALSE,
>> meaning that
>> the accumulate should have not even matched the fact that made it
>> through.
>>
>> After scratching my head for a while and trying a bunch of random
>> stuff, I
>> found that the problem resolved itself when I changed these
>> variable names
>> to be distinct.  IE, instead of two nearly identical rules with  
>> nearly
>> identical accumulate functions in which the result variables were
>> named the
>> same - ?result, I changed the names to the equivalent of ?result_a  
>> and
>> ?result_b and this problem went away.  It's like the second  
>> accumulate
>> function was already finding the result variable that was generated
>> by the
>> first accumulate, and automatically plopping the contents into the
>> second
>> ?someList.
>>
>> I'm thinking this is a Jess bug, but I am not positive about that
>> (I am
>> pretty new to Jess).  I am using Jess 7.0 as well (not sure what
>> build), so
>> I suppose it also could have been corrected since then.  Hopefully
>> this
>> example is enough to illustrate what's happening, as I have already
>> rambled
>> on for a while now.  If more detail is required, I will have to
>> replicate
>> the problem differently since the actual code is my company's
>> property.
>>
>> .
>>
>>          This message and any attachments contain information from
>> Union Pacific which may be confidential and/or privileged.
>> If you are not the intended recipient, be aware that any
>> disclosure, copying, distribution or use of the contents of this
>> message is strictly prohibited by law. If you receive this message
>> in error, please contact the sender immediately and delete the
>> message and any attachments.
>>
>>
>>
>> --------------------------------------------------------------------
>> To unsubscribe, send the words 'unsubscribe jess-users
>> you@...'
>> in the BODY of a message to majordomo@..., NOT to the list
>> (use your own address!) List problems? Notify owner-jess-
>> users@....
>> --------------------------------------------------------------------
>
> ---------------------------------------------------------
> Ernest Friedman-Hill
> Informatics & Decision Sciences          Phone: (925) 294-2154
> Sandia National Labs                FAX:   (925) 294-2234
> PO Box 969, MS 9012                 ejfried@...
> Livermore, CA 94550                 http://www.jessrules.com
>
>
>
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users  
> you@...'
> in the BODY of a message to majordomo@..., NOT to the list
> (use your own address!) List problems? Notify owner-jess-
> users@....
> --------------------------------------------------------------------
>
>
>
>
> .                                                                      
>                                                                        
>          This message and any attachments contain information from  
> Union Pacific which may be confidential and/or privileged.
> If you are not the intended recipient, be aware that any  
> disclosure, copying, distribution or use of the contents of this  
> message is strictly prohibited by law. If you receive this message  
> in error, please contact the sender immediately and delete the  
> message and any attachments.
>
>
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users  
> you@...'
> in the BODY of a message to majordomo@..., NOT to the list
> (use your own address!) List problems? Notify owner-jess-
> users@....
> --------------------------------------------------------------------