Re: [rules-users] How to track constraint truth [was: Non short circuit ANDing]

Let me add 2 more cents to the discussion :) I am still convinced that there should be better ways for the engine to provide argumentation facilities to the users. It's an open topic, we're working on it (better TMS, defeasible logic, new RETE algorithm, strong negation, etc..), but right now we have to live with what 5.x provides... at least until 6.x becomes a reality... The usecase here can be divided in two parts: - evaluate a chain of constraints, tracing which one(s) are satisfied and which ones are not - evaluate the overall formula, deciding whether an overall consequence should be fired or not. Wolfgang's suggestion, as usual, is correct: the constraints have to be broken apart. The alpha network evaluates them in a chain and does not notify the results of the evaluations. However, the proposed solution (extending a base rule) has a couple of problems - it relies heavily on (self) joins - it only handles the positive cases, e.g. color == "red", so that either a second rule (color != "red") has to be written, or later one will have to look for the absence of the "success" fact derived from that constraint. So, I'll follow up on my previous suggestion with this proposal: rule "car" when $car: Car( abs == true ) if ( colour == "red" ) do[red] else do[notRed] // vs break[notRed] then[red] System.out.println( ">>> Car is red " + $car ); then[notRed] System.out.println( ">>> Car is NOT red " + $car ); then System.out.println( "The best Car is in " + $car ); end The pattern Car( abs == true ) is a normal pattern: it's the same as the "base" rule and would filter objects (@Stephen) which are not relevant for discussion. The "if/else" structure follows the chain (no joins), but branches depending on result of the constraint. Both branches are linked to both a RHS (with an activation pushed into the agenda) AND the following patterns in the rule. This means that, using "do" as opposed to "break", one can still have a non-blocking sequence of evaluations with partial side effects, terminating with the "main" consequence. Each partial consequence can now be logged and possibly generate intermediate, control facts as suggested by Wolfgang. Let me name them "Fulfillment" and "Violation", following on a previous experiment we did a couple of years ago. At the moment, these facts have to be managed explicitly, but it would be great if the engine could provide more declarative ways to handle these use cases. I.e., something like the following rule allows a great deal of customization, but the "default" behaviour - dos insert Fulfillments, elses insert Violations - should probably be provided by the engine using some keyword ... rule "car" when $car: Car( abs == true ) if ( colour == "red" ) do[red] else do[notRed] // vs break[notRed] Success( $car; ) then[red] System.out.println( ">>> Car is red " + $car ); insert( new Fulfillment( $car, "red" ); ) then[notRed] System.out.println( ">>> Car is NOT red " + $car ); insert( new Violation( $car, "red" ); ) then System.out.println( "The best Car is in " + $car ); end The logic for creating the "Success" fact which unblocks the final consequence is another matter... should we require all Fulfills with no Viols? More Fulfills than Viols? The interesting thing is that now the "analysis" rules can be decoupled from the basic rule (again somehting we'd need to improve and provide out of the box) However, notice that this syntax is already PARTIALLY working... and while it is semantically designed to be *equivalent* to a chain of extended rules, the internal implementation is (supposedly) more efficient. UNFORTUNATELY: @Mario: I tried to use more than one "if" in a rule: $car: Car( abs == true ) if ( colour == "red" ) do[red] else do[notRed] if ( price < 1000 ) do[cheap] else do[notCheap] but I get a compilation error ... is this a bug or simply the feature has not been fully implemented yet? Best Davide -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-How-to-track-constraint-tru... Sent from the Drools: User forum mailing list archive at Nabble.com.