On 12 December 2010 10:17, Greg Barton <greg_bar...@yahoo.com> wrote:
> The benefits of an OO RBMS don't matter when you're incompletely
> constraining the type as you were in your original rules. The constraint
> you want is "the id is the same AND they're of corresponding types" which
> you couldn't get by just specifying the supertypes as you were.
The moral of the story is that you can't use a mixture of leaf and non-leaf
class nodes from the same hierarchy for distinct matches. Use supertypes in
patterns only if you "really mean it".
Or, I can also use
rule "track state for unknown element"
when
$s: TrackState( $id: id, *eval( $s.getClass() == TrackState.class)*)
not Track( id == $id )
then
>
> As for your testing comment, I agree. The best I've ever done is to set up
> a random dataset I know should pass a test, including random setup
> conditions, and run the test until I'm reasonably confident the code works
> properly. That doesn't work if the input data is too "safe," but that's
> always a problem with unit tests.
>
Even a set of exhaustive tests of individual SwitchState facts succeeds:
for( String e: new String[]{ "1", "2", "3", "4", "5", "6" } ){
insert( new SwitchState( e, true, SwitchPosition.RIGHT, false )
);
fireAllRules();
}
Only moving fireAllRules() out of the loop produces the effect.
-W
>
>
> --- On *Sun, 12/12/10, Wolfgang Laun <wolfgang.l...@gmail.com>* wrote:
>
>
> From: Wolfgang Laun <wolfgang.l...@gmail.com>
> Subject: Re: [rules-dev] A remarkable flop
>
> To: "Rules Dev List" <rules-dev@lists.jboss.org>
> Date: Sunday, December 12, 2010, 2:48 AM
>
>
> Ah, yes, and I'd actually be interested to learn why the indeterminism of
> rule firings not only depends on two or more rules matching the fact set but
> also on the order and/or number of facts being inserted.
>
> Notice that with three SwitchState facts inserted, id's 1, 2 and 5 match
> and fire the "correct" (i.e., expected) rule. Adding a fourth fact with id 4
> suddenly fires the match of no. 5 with the "wrong" (i.e., unexpected) rule.
>
> Actually, this means that you cannot rely on tests of rule sets, as you
> could if a potentially multiple match between two rules would always first
> activate A or always first B.
>
> -W
>
> On 12 December 2010 09:28, Wolfgang Laun
> <wolfgang.l...@gmail.com<http://mc/compose?to=wolfgang.l...@gmail.com>
> > wrote:
>
> The solution I adopted is to make SwitchState not a subclass of TrackState
> but of ElementState, which means that the field(s) to be inherited from
> TrackState have to be duplicated in SwitchState. (Luckily, here it is only
> one field.)
>
> Adding a type-identifying field goes against the (my) idea of classes for
> identifying categories and using them as an implicit constraint in rules,
> making them more readable. That's one of the benefits of having an OO RBS,
> isn't it?
>
> Anyway, I just wanted to draw people's attention to this hidden trap;
> working around it is no problem once you know it is there.
>
> -W
>
>
>
> On 12 December 2010 05:06, Greg Barton
> <greg_bar...@yahoo.com<http://mc/compose?to=greg_bar...@yahoo.com>
> > wrote:
>
> Well, seeing as you're already maintaining two parallel type hierarchies,
> and it's a mismatch between the two that's causing the problem, you might as
> well use that in the rules.
>
> rule "Xyz state update"
> when
> $s: XyzState( $id: id, $type: type ... )
> $e: Xyz( id == $id, type == $type )
>
> then
> //...update $e, retract $s
> end
>
> rule "Xyz state for unknown element"
> when
> $s: XyzState( $id: id, $type: type )
> not Xyz( id == $id, type == $type )
> then
> //... diagnostic, retract $s
> end
>
> That oughter do it, and it avoids salience.
> --- On *Sat, 12/11/10, Wolfgang Laun
> <wolfgang.l...@gmail.com<http://mc/compose?to=wolfgang.l...@gmail.com>
> >* wrote:
>
>
> From: Wolfgang Laun
> <wolfgang.l...@gmail.com<http://mc/compose?to=wolfgang.l...@gmail.com>
> >
> Subject: [rules-dev] A remarkable flop
> To: "Rules Dev List"
> <rules-dev@lists.jboss.org<http://mc/compose?to=rules-...@lists.jboss.org>
> >
> Date: Saturday, December 11, 2010, 10:23 AM
>
>
>
> Given classes Switch and Track, and the "natural" class hierarchy
> representing state changes for these two elements:
> ElementState
> TrackState extends ElementState ("free/occupied")
> SwitchState extends TrackState (adds "left/right/moving")
> Now we have rules for updating Switch and Track elements, like this one:
> rule "Xyz state update"
> when
> $s: XyzState( $id: id, ... )
> $e: Xyz( id == $id )
> then
> //...update $e, retract $s
> end
> and, since we want to catch bad ids, also
> rule "Xyz state for unknown element"
> when
> $s: XyzState( $id: id )
> not Xyz( id == $id )
> then
> //... diagnostic, retract $s
> end
>
> Best practice, wouldn't you say?
>
> Testing by inserting a few of SwitchState objects works fine:
> updated: Switch 5 RIGHT occupied
> updated: Switch 2 RIGHT
> updated: Switch 1 RIGHT occupied
> so everything is allright, wouldn't you say?
>
> Add another SwitchState for Switch "4" to the test, and suddenly:
> updated: Switch 4 RIGHT
> track state for unknown element 5
> updated: Switch 2 RIGHT
> updated: Switch 1 RIGHT occupied
> What's this?!
>
> After some headscratching I realized that the negative rule for the
> SwitchState's superclass TrackState produces another activation, since, for
> any Switch element with an id x there clearly isn't a Track element with id
> x! This activation *occasionally *precedes the activation for the match in
> the "update" rule.
>
> This is annoying. Of course, negative salience for the "not" rules fixes
> this, but who would have thought that you need it with conditions
> (seemingly!) describing disjoint situations. And the negative salience is
> counter-intuitive, since normally you'd perform the check "no such element"
> *before *permitting any update action.
>
> Remarkable.
> Wolfgang
>
>
>
>
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org <http://mc/compose?to=rules-...@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org <http://mc/compose?to=rules-...@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org <http://mc/compose?to=rules-...@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
