[rules-dev] Decision table - Otherwise

Mon Apr 4 09:41:25 EDT 2011

There is a JIRA to add this to the spreadsheet form of decision tables too;
but I am yet to work on it.

There's a few I need to get round to at some time:

   - https://issues.jboss.org/browse/GUVNOR-1278 (otherwise)
   - https://issues.jboss.org/browse/GUVNOR-1237 (negate rule)
   - https://issues.jboss.org/browse/GUVNOR-1284 (negate pattern)

I will be updating the Guvnor documentation around decision tables for the
next release.

With kind regards,

Mike

On 4 April 2011 13:44, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:

> Fair enough.
>
> Presumably this will only be documented with Guvnor - if at all ;-)
>
> This way it will not confuse users writing their spreadsheets manually,
> which was my primordial fear.
>
> Thanks for you patience, Michael!
> Wolfgang
>
>
>
> On 4 April 2011 13:35, Michael Anstis <michael.anstis at gmail.com> wrote:
>
>> I've spoken to Mark about his direction on this can of works I fell into
>> ;-)
>>
>> What has been added to Guvnor's guided decision table is the simple
>> ability to add "else\otherwise" values to single field constraints that use
>> literal values and either the equality or inequality operator. There are
>> hooks in the code to add future support for other operators at the single
>> field constraint level - not composite field constraint (I'm taking the
>> implicit "and" between single field constraints to imply compound field
>> constraints on a single pattern too). It is not pretending to be the much
>> more generalised and further reaching "else\otherwise" at the whole rule
>> level. For this I will wait until the underlying rule engine provides it
>> "out of the box" - if ever.
>>
>> With kind regards,
>>
>> Mike
>>
>>
>> On 1 April 2011 11:54, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>>
>>> Hello Michael,
>>>
>>> On 1 April 2011 09:01, Michael Anstis <michael.anstis at gmail.com> wrote:
>>>
>>>> hehe, so I walked into this one with my eyes wide shut :)
>>>>
>>>> Given it is only possible to define implicit logical AND's between field
>>>> constraints within a decision table and given it is not possible to
>>>> introduce complexity with parenthesis, is the immediate problem domain
>>>> smaller than the more generalised discussion surrounding "otherwise" or
>>>> "else"?
>>>>
>>>> The first limitation can be overcome by converting multiple single field
>>>> constraints on the same field to a single compound field constraint on the
>>>> same field; thus:-
>>>>
>>>> r1:   age > 14, age <= 28 (i.e. age > 14 && <= 28) becomes
>>>> rx:   age <= 14 || > 28
>>>>
>>>> I wonder whether this problem cannot simply be resolved with application
>>>> of DeMorgan's Theorems (something I know a little about from studying
>>>> electronics as a student years ago).
>>>>
>>>
>>> Attaboy!
>>>
>>>
>>>>
>>>> Unlike some commentators I am not an expert in first order logic, and
>>>> therefore would appreciate guidance if people are willing to help.
>>>>
>>>
>>> Well, the point is that you can come up with pretty nasty constraints
>>> even without parentheses:
>>>
>>>    a > $1 && != $2 && < $3    # implicit assumption: $1 < $2 < $3
>>>
>>> Of course, de Morgan will help you here, too, but you'll have to develop
>>> some hefty symbolic expression handling.
>>>
>>> If expressions E1, E2, are the combined logical expressions for some
>>> field from rules r1, r2,..., the "otherwise" condition is
>>>
>>> ¬ ( E1 || E2 || ... ) =
>>> ¬ E1 && ¬ E2 && ...
>>>
>>> and you continue to apply de Morgan's laws to all Ei.
>>>
>>> But what about the very natural constraint combination of two or more
>>> fields as in my age/income example?
>>>
>>> Perhaps an entirely different approach should be considered, too. I'm
>>> thinking of a generic mechanism, which would have to gain control before any
>>> rule from a certain rule table is executed for another fact or set of facts.
>>> Then you could inspect all pending activations, and whenever you have one
>>> for a rule without an "otherwise" in a column it should discard any
>>> activations for the same fact set for rules with an "otherwise" in that
>>> column. I think this could be done from an agenda listener.
>>>
>>> -W
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Mike
>>>>
>>>> On 1 April 2011 07:02, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>>>>
>>>>> Michael,
>>>>>
>>>>> My position is that an otherwise for a single column is likely to
>>>>> cause trouble by misunderstandings. Especially the operators >, >=, <,
>>>>> <= are likely to be used to separate intervals, as in
>>>>> r1:   age > 14, age <= 28
>>>>> r2:   age > 28, age <= 42
>>>>>
>>>>> If you apply the proposed definition, the otherwise results in
>>>>> rx:   age <= 14, age > 42
>>>>> which is obviously never true.
>>>>>
>>>>> You can construct similar blackouts with two different fields, e.g.
>>>>> r1:   age > 60, income > 100000
>>>>> r2:   age > 40, income > 80000
>>>>>
>>>>> You will have to do an in-depth analysis of the AST resulting from the
>>>>> condition definition resulting from rule table lines $n+2 and $n+3 in
>>>>> order to get it right.
>>>>>
>>>>> My opinion is: Don't do it unless you can do it right.
>>>>>
>>>>> Cheers
>>>>> Wolfgang
>>>>>
>>>>> PS: I could provide a definition for otherwise with matches and
>>>>> soundslike, but I'd rather not.
>>>>>
>>>>>
>>>>> On 31 March 2011 21:25, Michael Anstis <michael.anstis at gmail.com>
>>>>> 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
>>>>> > https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>> >
>>>>> >
>>>>> _______________________________________________
>>>>> rules-dev mailing list
>>>>> rules-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> rules-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> 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/20110404/87ebc54b/attachment-0001.html 