[rules-dev] Decision table - Otherwise
Mark Proctor
mproctor at codehaus.org
Thu Mar 31 18:31:24 EDT 2011
On 31/03/2011 22:25, Michael Anstis wrote:
> Yeah, I remember the exchanges from a long time ago about "else" in
> DRL. IIRC, Mark wasn't keen on the idea.
I didn't like the way Ilog did "else", where it only works on an "eval"
node and must be the last CE in a rule.
I do however like the OPSJ way of labelled else, and you can have as
many as you like. I have already done the backend for this, with "named"
consequences, so allow multiple consequences per rule. We just haven't
hooked this up into the parser.
Although I have revised this concept further, with "steroids", and
instead called it "named branch". It is likely we'll dothis instead of
simple 'else'. Branch and Else are also the foundations for
opportunistic BC.
http://community.jboss.org/wiki/DroolsLanguageEnhancements#Branch_Labelled_Else
Branch (Labelled Else)
If the first branch is true it'll continue to propgate to the next node
which is part of the [then] chain, [then] is implicit for the first
branch. If b1 or b2 are true it'll it will activate the labelled block
branch( Pattern(....),
[b1] Pattern(....),
[b2] Pattern(....) )
If none of the branches match then the [b3] default branch is activated.
branch( Pattern(....),
[b1] Pattern(....),
[b2] Pattern(....),
[b3] default )
We can have branches activated when the pattern is not matched.
branch( [!b1] Pattern(....),
[!b2] Pattern(....),
[!b3] Pattern(....) )
In the case of b2 and b3 if the pattern is not true, it'll do nothing,
if the pattern is false the b2 will or b3 will activate. In the case of
first pattern, if it's false the b1 block will activate, if it's true it
will continue to propagate to the rest of the rule. ** is this
consistent and intuitive?
** Each branch does not need to be a Pattern it can have any drl, be
it an 'else', 'not', 'and'. If you want multiple patterns, make sure to
use the 'and' CE. We shouldn't allow 'or' CE's as I think that would get
too messy
** At the moment we don't ensure any xor type behaviour. For instance
we could have it that so only one branch can activate, it'll start at
the top and try each one in turn, exiting after the first one is activated.
>
> Anyway, provided my "reversals" make sense it's almost complete in the
> guided dtable; it only uses SimpleFieldConstraints so doesn't have the
> complexity of compound constraints :)
>
>
> On 31 March 2011 22:20, Michael Neale <michael.neale at gmail.com
> <mailto:michael.neale at gmail.com>> wrote:
>
> Otherwise has been dragging on since 2006. There are many
> skeletons in that cave.
>
> I will believe it when I see it !
>
>
> On Fri, Apr 1, 2011 at 7:25 AM, Michael Anstis
> <michael.anstis at gmail.com <mailto:michael.anstis at gmail.com>> wrote:
>
> I bet Edson can't wait to refactor the parser for that ;)
>
>
> On 31 March 2011 21:11, Mark Proctor <mproctor at codehaus.org
> <mailto:mproctor at codehaus.org>> wrote:
>
> on a related note I do plan to add OTHERWISE support at a
> DRL level, just no time to do it right now. Once it's
> supported at a DRL level, you won't need to as much work
> on figuring out the inverse options etc.
>
> Mark
>
> On 31/03/2011 20 <tel:31%2F03%2F2011%2020>:25, Michael
> Anstis wrote:
>> Hi,
>>
>> I'm adding support for "otherwise" to (for the time
>> being) the guided decision table in Guvnor.
>>
>> The idea being if you set a cell to represent "otherwise"
>> the generated rule is the opposite of the accumulation of
>> the other cells; perhaps best explained with an example:-
>>
>> Person( name == )
>> Mark
>> Kris
>> Geoffrey
>> <otherwise>
>>
>> This would generate:-
>>
>> Person(name not in ("Mark", "Kris", "Geoffrey")
>>
>> Equals is the simple example, this is my thoughts for the
>> other operators we might like to support:-
>>
>> * != becomes "in (<list of the other cells' values)"
>> * < becomes ">= the maximum value of the other cells'
>> values
>>
>>
>> For example:-
>>
>> Person ( age < )
>> 10
>> 20
>> 30
>> <otherwise>
>>
>> Person ( age >= 30 )
>>
>> * <= becomes "> the maximum value of the other cells'
>> values
>> * > becomes "<= the minimum value of the other cells'
>> values
>> * >= becomes "< the minimum value of the other cells'
>> values
>> * "in" becomes "not in (<a list of all values
>> contained in all the other cells' lists of values>)"
>>
>> For example:-
>>
>> Person ( name in )
>> Jim, Jack
>> Lisa, Jane, Paul
>> <otherwise>
>>
>> Person ( name not in ("Jim", "Jack", "Lisa", "Jane",
>> "Paul" ) )
>>
>> * I'm not sure there is a simple solution for
>> "matches" and "soundslike" but welcome advice,
>> although a possibility might be to create a
>> compound field constraint:-
>>
>> Person ( name soundslike )
>> Fred
>> Phil
>>
>> not Person ( name soundslike "Fred" || soundslike "Phil" )
>>
>>
>> Would this be considered the most suitable approach?
>>
>> Inputs and thoughts welcome.
>>
>> Thanks,
>>
>> Mike
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Michael D Neale
> home: www.michaelneale.net <http://www.michaelneale.net>
> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110331/97a9e27d/attachment-0001.html
More information about the rules-dev
mailing list