[rules-dev] Decision table - Otherwise

[Michael Anstis]

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).

Unlike some commentators I am not an expert in first order logic, and
therefore would appreciate guidance if people are willing to help.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110401/5e9cb157/attachment.html