On 12 December 2010 10:17, Greg Barton <span dir="ltr"><<a href="mailto:greg_barton@yahoo.com">greg_barton@yahoo.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">
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. </td>
</tr></tbody></table></blockquote><div><br>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".<br>
<br>Or, I can also use<br> rule "track state for unknown element"<br> when<br> $s: TrackState( $id: id, <b>eval( $s.getClass() == TrackState.class)</b> )<br> not Track( id == $id )<br> then<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">
<div><br></div><div>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.</div>
</td></tr></tbody></table></blockquote><div><br>Even a set of exhaustive tests of individual SwitchState facts succeeds:<br> for( String e: new String[]{ "1", "2", "3", "4", "5", "6" } ){<br>
insert( new SwitchState( e, true, SwitchPosition.RIGHT, false ) );<br> fireAllRules();<br> }<br>Only moving fireAllRules() out of the loop produces the effect.<br><br>-W<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">
<div><div class="im"><br><br>--- On <b>Sun, 12/12/10, Wolfgang Laun <i><<a href="mailto:wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>></i></b> wrote:<br></div><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">
<div class="im"><br>From: Wolfgang Laun
<<a href="mailto:wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>><br></div>Subject: Re: [rules-dev] A remarkable flop<div class="im"><br>To: "Rules Dev List" <<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>><br>
</div>Date: Sunday, December 12, 2010, 2:48 AM<div><div></div><div class="h5"><br><br><div>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.<br>
<br>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.<br>
<br>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.<br><br>-W<br><br><div>
On 12 December 2010 09:28, Wolfgang Laun <span dir="ltr"><<a rel="nofollow" href="http://mc/compose?to=wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>></span> wrote:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.)<br>
<br>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?<br>
<br>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.<br><font color="#888888"><br>-W</font><div><div></div><div><br><br><br><div>
On 12 December 2010 05:06, Greg Barton <span dir="ltr"><<a rel="nofollow" href="http://mc/compose?to=greg_barton@yahoo.com" target="_blank">greg_barton@yahoo.com</a>></span> wrote:<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">
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.<br><br><div><div> rule "Xyz state update" <br>
when<br></div> $s: XyzState( $id: id, $type: type ... )<br> $e: Xyz( id == $id, type == $type )<div><br> then<br> //...update $e, retract $s<br> end<br><br></div></div><div><div>
rule "Xyz state for unknown element"<br> when<br></div> $s: XyzState( $id: id, $type: type )</div><div> not Xyz( id == $id, type == $type )</div><div><div> then<br> //... diagnostic, retract $s<br>
end</div><div><br></div></div><div>That oughter do
it, and it avoids salience.<br>--- On <b>Sat, 12/11/10, Wolfgang Laun <i><<a rel="nofollow" href="http://mc/compose?to=wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">
<br>From: Wolfgang Laun <<a rel="nofollow" href="http://mc/compose?to=wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>><br>Subject: [rules-dev] A remarkable flop<br>To: "Rules Dev List" <<a rel="nofollow" href="http://mc/compose?to=rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>><br>
Date: Saturday, December 11, 2010, 10:23 AM<div><div></div><div><br><br><div><br>
Given classes Switch and Track, and the "natural" class hierarchy representing state changes for these two elements:<br>
ElementState<br>
TrackState extends ElementState ("free/occupied")<br>
SwitchState extends TrackState (adds "left/right/moving")<br>Now we have rules for updating Switch and Track elements, like this one:<br>
rule "Xyz state update" <br>
when<br>
$s: XyzState( $id: id, ... )<br>
$e: Xyz( id == $id )<br>
then<br>
//...update $e, retract $s<br>
end<br>
and, since we want to catch bad ids, also<br>
rule "Xyz state for unknown element"<br>
when<br>
$s: XyzState( $id: id )<br>
not Xyz( id == $id )<br>
then<br>
//... diagnostic, retract $s<br>
end<br>
<br>
Best practice, wouldn't you say?<br><br>Testing by inserting a few of SwitchState objects works fine:<br> updated: Switch 5 RIGHT occupied<br> updated: Switch 2 RIGHT<br> updated: Switch 1 RIGHT occupied<br> so everything is allright, wouldn't you say? <br>
<br>Add another SwitchState for Switch "4" to the test, and suddenly:<br> updated: Switch 4 RIGHT<br> track state for unknown element 5<br> updated: Switch 2 RIGHT<br> updated: Switch 1 RIGHT occupied<br>What's this?!<br>
<br>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 <i>occasionally </i>precedes the activation for the match in the "update" rule.<br>
<br>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" <i>before </i>permitting any update action.<br>
<br>Remarkable.<br>Wolfgang<br><br><br><br> <br> <br><br><br>
</div><br></div></div>-----Inline Attachment Follows-----<br><br><div>_______________________________________________<br>rules-dev mailing list<br><a rel="nofollow" href="http://mc/compose?to=rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a rel="nofollow" href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br></div></blockquote></div></td></tr></tbody></table><br>
<br>_______________________________________________<br>
rules-dev mailing list<br>
<a rel="nofollow" href="http://mc/compose?to=rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a rel="nofollow" href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br></blockquote></div><br>
</div></div></blockquote></div><br>
</div><br>-----Inline Attachment Follows-----<br><br><div>_______________________________________________<br>rules-dev mailing list<br><a href="http://mc/compose?to=rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br></div></div></div></blockquote></div></td></tr></tbody></table><br>
<br>_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br></blockquote></div><br>