<br> Gernot,<br><br> Thanks for taking the time to investigate and report your findings. I implemented a fix in a similar way to your suggestion, but instead of writing an eval() in the end, I reordered the patterns leaving the Fred's neighbor pattern as the last pattern:
<br><br> // The golfer to Fred's immediate right<br> // is wearing blue pants<br> $fn : Golfer( position == ( $fredsPosition + 1 ),<br> color == "blue",<br> this in ( $joe, $bob, $tom ) )
<br><br> What do you think about this solution? It now correctly solves the problem, but I'm not sure it is as elegant solution as you was looking for. <br><br> If you want to take a look, just make sure you use drools-core jar from trunk (not GA), since I found and fixed a minor bug while changing the golfer example.
<br><br> Edson<br><br><div><span class="gmail_quote">2007/8/10, Dr. Gernot Starke <<a href="mailto:gs@gernotstarke.de">gs@gernotstarke.de</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi there,<br><br>some people complained that the Golfer-example from the JBoss-Drools<br>distribution finds two identical solutions.<br>I investigated a little and found the "problem":<br><br>The rule is underspecified: It binds five Golfer objects, but only
<br>four of those are completely specified by their respective<br>condition elements. The fifth, the "Freds right neighbour", lacks<br>that completeness...<br><br>What happens is the following: The "unknown golfer" can be bound to
<br>two different facts: I had the "unknown" golfer<br>printed out - and see what happened:<br><br>Fred 1 orange, Joe 2 blue, Bob 4 plaid, Tom 3 red<br>unknown Tom 2 blue<br><br>Fred 1 orange, Joe 2 blue, Bob 4 plaid, Tom 3 red
<br>unknown Joe 2 blue<br><br>As the unknown golfer is NOT compared to the actual neighbor, Joe,<br>there are two possible instantiations<br>for our "unknown" golfer...<br><br>The solution would be to constraint the unknown-golfer (= Fred's
<br>right neighbour) to the set of (Bob, Joe, Tom)...<br>an eval sounds great - too bad the "in" constraint doesn't work...<br><br> // freds right neighbour is either Tom, Bob or Joe!<br> eval (($fn == $joe) || ($fn == $bob) || ($fn == $tom))
<br><br><br>The simple (but un-elegant) solution is setting an agenda-group rule-<br>attribute, prohibing the rule from firing twice.<br><br>In his book on JESS, E. Friedemann-Hill shows JESS to deliver only a<br>single solution ... I translated the Drools-version
<br>literally to his JESS version (I had to create GolferColor and<br>GolferPosition classes, but needed only 32 facts in working memory,<br>instead of 64 with the combined Golfer-drools version)....<br><br>regards,<br>Gernot
<br><br><br>Dr. Gernot Starke<br>Doing IT Right<br><br>---<br>Willi-Lauf Allee 43, D-50858 Köln<br><a href="mailto:gs@gernotstarke.de">gs@gernotstarke.de</a>,<br> +49 (0) 177 - 728 2570<br><a href="http://www.gernotstarke.de">
http://www.gernotstarke.de</a><br>Blog: <a href="http://it-and-more.blogspot.com">http://it-and-more.blogspot.com</a><br>****************************************<br>Das freie Portal für Software-Architekten:<br><a href="http://www.arc42.de">
http://www.arc42.de</a><br><br><br><br>_______________________________________________<br>rules-users mailing list<br><a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-users">
https://lists.jboss.org/mailman/listinfo/rules-users</a><br></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> Software Engineer - JBoss Rules Core Developer<br> Office: +55 11 3529-6000<br> Mobile: +55 11 9287-5646
<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a>