Re: [rules-dev] Decision table - Otherwise

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(a)gmail.com&gt; 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(a)gmail.com&gt; wrote: > >> Hello Michael, >> >> On 1 April 2011 09:01, Michael Anstis <michael.anstis(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; >>>> 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(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/rules-dev >>>> > >>>> > >>>> _______________________________________________ >>>> rules-dev mailing list >>>> rules-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>> >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev