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

[Edson Tirelli]

   Gernot,

   Yes, it is commited in trunk in case you want to check it out:

http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-examples/drools-examples-drl/src/main/rules/org/drools/examples/golf.drl

    Regards,
    Edson


2007/8/12, Dr. Gernot Starke <gs at gernotstarke.de>:
>
> the language statement "this in ($joe, $bob, $tom)" sounds & looks great
> to me - more intuitive than the eval. imho itshortens 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 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
> _______________________________________________
> rules-users mailing list
> rules-users at 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 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/20070812/4d49973c/attachment.html