[rules-dev] Decision table - Otherwise

Mon Apr 4 13:31:52 EDT 2011

Great! - I'm trying to stay positive ;-)

The change to implement "otherwise" can be dropped from the spreadsheet
version: It is only possible in Guvnor because the editor has limited
function.

Negate rule: can also be dropped from the spreadsheet version.

Negate pattern: I didn't realise it was already there :)

FYI, I've been speaking with Mark about the prospect of replacing (or
complimenting) Guvnor's guided decision table editor with what I term
"tabular templating" i.e. DRL fragments as column definitions (with a single
place-holder for values) and a table beneath containing the data to
interpolate in the DRL fragments - much like the existing spreadsheet
dtable. Sort of a hybrid between Guvnor's "Templated rules" and it's
"Decision Table".

Furthermore, TBH, I raised the parallel JIRAs to keep Guvnor and the
spreadsheet versions operation consistent and can just as easily reject
them.

Happy(ier) now?

Cheers,

Mike

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

> Sigh.
>
> On 4 April 2011 15:41, Michael Anstis <michael.anstis at gmail.com> wrote:
>
>> 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)
>>
>> From the xls/csv-parser's point of view: this has to be restricted to the
> very simple form of the code snippet in the 2nd cell below CONDITION being
> just the field name. Otherwise, it's easy to write snippet/value
> combinations that can't be handled by an "otherwise" constructed from "not
> in (...)".
>
>
>>
>>    - https://issues.jboss.org/browse/GUVNOR-1237 (negate rule)
>>
>> I don't see any useful use cases for this except for a rule table
> containing just two rule rows, one with the positive pattern, and one with
> the negated form. Is this the reason this should be added?
>
>
>>
>>    - https://issues.jboss.org/browse/GUVNOR-1284 (negate pattern)
>>
>> Simple preceding any single (!) pattern with not is possible right now -
> you just write "not" in front of the type.
>
> Cheers
> Wolfgang
>
>
>>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/8a5d173e/attachment-0001.html 