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
