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.l...@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.ans...@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.l...@gmail.com> wrote: >> >>> Hello Michael, >>> >>> On 1 April 2011 09:01, Michael Anstis <michael.ans...@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.l...@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.ans...@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@lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> > >>>>> > >>>>> _______________________________________________ >>>>> rules-dev mailing list >>>>> rules-dev@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> rules-dev mailing list >>>> rules-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>>> >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > >
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
