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

[DCWYRICK]

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]

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: [phone]
Sandia National Labs                FAX:   [phone]
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@....
--------------------------------------------------------------------

[DCWYRICK]

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: [phone]
Sandia National Labs                FAX:   [phone]
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@....
--------------------------------------------------------------------

[Ernest Friedman-Hill]

On Apr 7, 2008, at 4:11 PM, DCWYRICK@... wrote:

> 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.

That sounds good. Send it directly to me, not to the list.

>
>
>
>
>
>              "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: [phone]
> Sandia National Labs                FAX:   [phone]
> 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@....
> --------------------------------------------------------------------

---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences          Phone: [phone]
Sandia National Labs                FAX:   [phone]
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@....
--------------------------------------------------------------------