[rules-users] Golfer example finds two identical solutions - the explanation

[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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070811/4d331b64/attachment.html