> -----Original Message----- > From: Geoffrey Wiseman [mailto:[EMAIL PROTECTED] > > On 11/20/05, Karr, David <[EMAIL PROTECTED]> wrote: > > I think I understand salience, but I still don't understand > > xor-groups. From what I thought I understood, what I > described doesn't > > match your description, particularly related to your > statement "then > > the other rule will not as it is in the same XOR group". In my test > > case, it executed the consequence for both rules in the same > > xor-group. How does that jive with your statement? > > > > Perhaps my misunderstanding about this has to do with what "fire" > > means. I thought this referred to the checking of the > parameters and > > conditions on a rule. Your statements seem to imply that's not the > > case. > > I don't know much about the xor-group part, becauase I > haven't used it or examined its implementation, but my base > assumption would be that the parameters and conditions are > checked as normal, activations placed on the agenda, but > before an activation is fired (e.g. consequence executed), it > would check to ensure that no other activation from the same > xorgroup has fired. > > What I'd expect to see, then, is all the relevant conditions > are checked, but that the consequence of the rule with > salience 2 is executed and the consequence of the rule with > salience 1 is not (although the conditions would be).
Ok, then, if your expectations are reasonably authoritative, then something's wrong. Perhaps I'm doing something you didn't expect. If you don't mind, I'm going to attach my DRL, the Java class driving it, and the output from running my test. In the build output, you'll see "Got here.4" from the salience "2" rule, and "Got here.3" from the salience "1" rule, the latter being the one that I think we expect to NOT see. As I'm using the "DebugWorkingMemoryEventListener" event listener, perhaps the build output will tell you something else that is significant.
