the language statement "this in ($joe, $bob, $tom)" sounds & looks
great to me - more intuitive than the eval. imho it
shortens down the overall LHS...
Considering rule-performance, one should imho fail-as-early-as-
possible... but for the example that surely does not matter...
thanx for this improvement...
will you commit this to the next release, so this sample works "as
expected" from now on?
regards from (sunny) Cologne,
Gernot
Am 11.08.2007 um 20:45 schrieb Edson Tirelli:
Gernot,
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:
// The golfer to Fred's immediate right
// is wearing blue pants
$fn : Golfer( position == ( $fredsPosition + 1 ),
color == "blue",
this in ( $joe, $bob, $tom ) )
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.
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.
Edson
2007/8/10, Dr. Gernot Starke <gs(a)gernotstarke.de>:
Hi there,
some people complained that the Golfer-example from the JBoss-Drools
distribution finds two identical solutions.
I investigated a little and found the "problem":
The rule is underspecified: It binds five Golfer objects, but only
four of those are completely specified by their respective
condition elements. The fifth, the "Freds right neighbour", lacks
that completeness...
What happens is the following: The "unknown golfer" can be bound to
two different facts: I had the "unknown" golfer
printed out - and see what happened:
Fred 1 orange, Joe 2 blue, Bob 4 plaid, Tom 3 red
unknown Tom 2 blue
Fred 1 orange, Joe 2 blue, Bob 4 plaid, Tom 3 red
unknown Joe 2 blue
As the unknown golfer is NOT compared to the actual neighbor, Joe,
there are two possible instantiations
for our "unknown" golfer...
The solution would be to constraint the unknown-golfer (= Fred's
right neighbour) to the set of (Bob, Joe, Tom)...
an eval sounds great - too bad the "in" constraint doesn't work...
// freds right neighbour is either Tom, Bob or Joe!
eval (($fn == $joe) || ($fn == $bob) || ($fn == $tom))
The simple (but un-elegant) solution is setting an agenda-group rule-
attribute, prohibing the rule from firing twice.
In his book on JESS, E. Friedemann-Hill shows JESS to deliver only a
single solution ... I translated the Drools-version
literally to his JESS version (I had to create GolferColor and
GolferPosition classes, but needed only 32 facts in working memory,
instead of 64 with the combined Golfer-drools version)....
regards,
Gernot
Dr. Gernot Starke
Doing IT Right
---
Willi-Lauf Allee 43, D-50858 Köln
gs(a)gernotstarke.de,
+49 (0) 177 - 728 2570
http://www.gernotstarke.de
Blog:
http://it-and-more.blogspot.com
****************************************
Das freie Portal für Software-Architekten:
http://www.arc42.de
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @
www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Dr. Gernot Starke
Doing IT Right
---
Willi-Lauf Allee 43, D-50858 Köln
gs(a)gernotstarke.de,
+49 (0) 177 - 728 2570
****************************************
Das freie Portal für Software-Architekten: