On 04/04/2011 13:44, Wolfgang Laun wrote:
Fair enough.
Presumably this will only be documented with Guvnor - if at all ;-)
We do hope to eventually have excel round tripping. So OTHERWISE will
need to be treated as a special keyword there.
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
<mailto: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
<mailto:wolfgang.l...@gmail.com>> wrote:
Hello Michael,
On 1 April 2011 09:01, Michael Anstis
<michael.ans...@gmail.com <mailto: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 <mailto: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
<mailto: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
<mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto: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
