I think Jack Kerkhof wrote: > Hi all, > > Under what conditions could the addition of an (exists <pattern>) > around a <pattern> cause a rule NOT to fire?
None that I can think of, unless perhaps the pattern binds a variable that is used later in the rule -- but be sure to read all the way to the enf of this message. > I know that would imply the problem is elsewhere, but I have > constrained all variables to only the change above. It would seem to > me that under any circumstance two rules with the above variations > would either not fire at all, or both fire at least once - correct? Yes, that should be the case. What does the pattern look like? Does it define any variables? > PS Tested in 5.2 Try this in 6.0 if you can, see if the problem has been fixed. > PPS: Ernest, the documentation section 2.8.1.7. (5.2) indicates that > (exists) is implemented as (not (not)) when in fact it appears to be > implemented as (not (not (unique))). I don't know if that is salient > to this problem or 'not' ;-) It's true that the (unique) flag is set in those two nested "not" nodes as an optimizatiion. This is the case in 5.2 but not in 6.0. You could try commenting that line (line 1104 in jess/Jesp.java) and see if the problem goes away -- please let me know if it does. (unique) is a tricky beast and easy to abuse; this optimization might in fact be one of those abuses. --------------------------------------------------------- Ernest Friedman-Hill Distributed Systems Research Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 Org. 8920, MS 9012 [EMAIL PROTECTED] PO Box 969 http://herzberg.ca.sandia.gov Livermore, CA 94550 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
