on a related note I do plan to add OTHERWISE support at a DRL level, just no time to do it right now. Once it's supported at a DRL level, you won't need to as much work on figuring out the inverse options etc. Mark On 31/03/2011 20:25, Michael Anstis 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 listrules-dev@lists.jboss.orghttps://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

Otherwise has been dragging on since 2006. There are many skeletons in that cave. I will believe it when I see it ! On Fri, Apr 1, 2011 at 7:25 AM, Michael Anstis <michael.anstis(a)gmail.com&gt;wrote: > I bet Edson can't wait to refactor the parser for that ;) > > > On 31 March 2011 21:11, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > >> on a related note I do plan to add OTHERWISE support at a DRL level, >> just no time to do it right now. Once it's supported at a DRL level, you >> won't need to as much work on figuring out the inverse options etc. >> >> Mark >> >> On 31/03/2011 20:25, Michael Anstis 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 listrules-dev@lists.jboss.orghttps://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 > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com

= 30 )

becomes "<= the minimum value of the other cells'

= becomes "< the minimum value of the other cells'

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

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(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

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

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

- https://issues.jboss.org/browse/GUVNOR-1237 (negate rule) I don't see any useful use cases for this except for a rule table

- https://issues.jboss.org/browse/GUVNOR-1284 (negate pattern) Simple preceding any single (!) pattern with not is possible right now -

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(a)gmail.com&gt; 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(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 > > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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