9:25 p.m.
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
10:11 p.m.
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 list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
10:25 p.m.
I bet Edson can't wait to refactor the parser for that ;)
On 31 March 2011 21:11, Mark Proctor <mproctor(a)codehaus.org> 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
11:20 p.m.
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>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> 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
11:25 p.m.
Yeah, I remember the exchanges from a long time ago about "else" in DRL.
IIRC, Mark wasn't keen on the idea.
Anyway, provided my "reversals" make sense it's almost complete in the
guided dtable; it only uses SimpleFieldConstraints so doesn't have the
complexity of compound constraints :)
On 31 March 2011 22:20, Michael Neale <michael.neale(a)gmail.com> wrote:
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>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> 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
11:54 p.m.
Oh, it's been dragging on longer than that. I used it in OPSJ in 1999. :P
--- On Thu, 3/31/11, Michael Neale <michael.neale(a)gmail.com> wrote:
From: Michael Neale <michael.neale(a)gmail.com>
Subject: Re: [rules-dev] Decision table - Otherwise
To: "Rules Dev List" <rules-dev(a)lists.jboss.org>
Date: Thursday, March 31, 2011, 4:20 PM
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> 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> 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 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
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
-----Inline Attachment Follows-----
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
12:31 a.m.
On 31/03/2011 22:25, Michael Anstis wrote:
Yeah, I remember the exchanges from a long time ago about
"else" in
DRL. IIRC, Mark wasn't keen on the idea.
I didn't like the way Ilog did
"else", where it only works on an "eval"
node and must be the last CE in a rule.
I do however like the OPSJ way of labelled else, and you can have as
many as you like. I have already done the backend for this, with "named"
consequences, so allow multiple consequences per rule. We just haven't
hooked this up into the parser.
Although I have revised this concept further, with "steroids", and
instead called it "named branch". It is likely we'll dothis instead of
simple 'else'. Branch and Else are also the foundations for
opportunistic BC.
http://community.jboss.org/wiki/DroolsLanguageEnhancements#Branch_Labelle...
Branch (Labelled Else)
If the first branch is true it'll continue to propgate to the next node
which is part of the [then] chain, [then] is implicit for the first
branch. If b1 or b2 are true it'll it will activate the labelled block
branch( Pattern(....),
[b1] Pattern(....),
[b2] Pattern(....) )
If none of the branches match then the [b3] default branch is activated.
branch( Pattern(....),
[b1] Pattern(....),
[b2] Pattern(....),
[b3] default )
We can have branches activated when the pattern is not matched.
branch( [!b1] Pattern(....),
[!b2] Pattern(....),
[!b3] Pattern(....) )
In the case of b2 and b3 if the pattern is not true, it'll do nothing,
if the pattern is false the b2 will or b3 will activate. In the case of
first pattern, if it's false the b1 block will activate, if it's true it
will continue to propagate to the rest of the rule. ** is this
consistent and intuitive?
** Each branch does not need to be a Pattern it can have any drl, be
it an 'else', 'not', 'and'. If you want multiple patterns, make
sure to
use the 'and' CE. We shouldn't allow 'or' CE's as I think that
would get
too messy
** At the moment we don't ensure any xor type behaviour. For instance
we could have it that so only one branch can activate, it'll start at
the top and try each one in turn, exiting after the first one is activated.
Anyway, provided my "reversals" make sense it's almost complete in the
guided dtable; it only uses SimpleFieldConstraints so doesn't have the
complexity of compound constraints :)
On 31 March 2011 22:20, Michael Neale <michael.neale(a)gmail.com
<mailto:michael.neale@gmail.com>> wrote:
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 <mailto:michael.anstis@gmail.com>> 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
<mailto:mproctor@codehaus.org>> 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 <tel:31%2F03%2F2011%2020>: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 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
--
Michael D Neale
home: www.michaelneale.net <http://www.michaelneale.net>
blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
12:32 a.m.
On 31/03/2011 22:54, Greg Barton wrote:
Oh, it's been dragging on longer than that. I used it in OPSJ in
1999. :P
Edson's new parser is almost finished. We just found we had hit a brick
will with pure ANTLR, it was defying us at every turn. Which caused our
language innovation to crawl to a halt. It's been very painful, but once
it's done, we'll be back on the language innovation train again :)
Mark
--- On *Thu, 3/31/11, Michael Neale /<michael.neale(a)gmail.com>/* wrote:
From: Michael Neale <michael.neale(a)gmail.com>
Subject: Re: [rules-dev] Decision table - Otherwise
To: "Rules Dev List" <rules-dev(a)lists.jboss.org>
Date: Thursday, March 31, 2011, 4:20 PM
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
</mc/compose?to=michael.anstis(a)gmail.com>> 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
</mc/compose?to=mproctor(a)codehaus.org>> 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 list
> rules-dev(a)lists.jboss.org
</mc/compose?to=rules-dev(a)lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
</mc/compose?to=rules-dev(a)lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
</mc/compose?to=rules-dev(a)lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net <http://www.michaelneale.net>
blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
-----Inline Attachment Follows-----
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org </mc/compose?to=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
8:02 a.m.
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> 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
9:01 a.m.
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> 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> 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
12:54 p.m.
Hello Michael,
On 1 April 2011 09:01, Michael Anstis <michael.anstis(a)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> 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> 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
1:35 p.m.
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> wrote:
Hello Michael,
On 1 April 2011 09:01, Michael Anstis <michael.anstis(a)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> 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> 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
2:44 p.m.
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> 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> wrote:
> Hello Michael,
>
> On 1 April 2011 09:01, Michael Anstis <michael.anstis(a)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> 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>
>>> 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
3:41 p.m.
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.laun(a)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.anstis(a)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> wrote:
>
>> Hello Michael,
>>
>> On 1 April 2011 09:01, Michael Anstis <michael.anstis(a)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> 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>
>>>> 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
7:09 p.m.
Sigh.
On 4 April 2011 15:41, Michael Anstis <michael.anstis(a)gmail.com> wrote:
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
very
simple form of the code snippet in the 2nd cell below CONDITION being
just the field name. Otherwise, it's easy to write snippet/value
combinations that can't be handled by an "otherwise" constructed from
"not
in (...)".
- https://issues.jboss.org/browse/GUVNOR-1237 (negate rule)
I don't see any useful use cases for this except for a rule table
containing
just two rule rows, one with the positive pattern, and one with
the negated form. Is this the reason this should be added?
- https://issues.jboss.org/browse/GUVNOR-1284 (negate pattern)
Simple preceding any single (!) pattern with not is possible right now -
you just
write "not" in front of the type.
Cheers
Wolfgang
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> 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> 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> wrote:
>>
>>> Hello Michael,
>>>
>>> On 1 April 2011 09:01, Michael Anstis <michael.anstis(a)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>
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>
>>>>> 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
7:31 p.m.
Great! - I'm trying to stay positive ;-)
The change to implement "otherwise" can be dropped from the spreadsheet
version: It is only possible in Guvnor because the editor has limited
function.
Negate rule: can also be dropped from the spreadsheet version.
Negate pattern: I didn't realise it was already there :)
FYI, I've been speaking with Mark about the prospect of replacing (or
complimenting) Guvnor's guided decision table editor with what I term
"tabular templating" i.e. DRL fragments as column definitions (with a single
place-holder for values) and a table beneath containing the data to
interpolate in the DRL fragments - much like the existing spreadsheet
dtable. Sort of a hybrid between Guvnor's "Templated rules" and it's
"Decision Table".
Furthermore, TBH, I raised the parallel JIRAs to keep Guvnor and the
spreadsheet versions operation consistent and can just as easily reject
them.
Happy(ier) now?
Cheers,
Mike
On 4 April 2011 18:09, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
Sigh.
On 4 April 2011 15:41, Michael Anstis <michael.anstis(a)gmail.com> wrote:
> 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
very simple form of the code snippet in the 2nd cell below CONDITION being
just the field name. Otherwise, it's easy to write snippet/value
combinations that can't be handled by an "otherwise" constructed from
"not
in (...)".
>
> - https://issues.jboss.org/browse/GUVNOR-1237 (negate rule)
>
> I don't see any useful use cases for this except for a rule table
containing just two rule rows, one with the positive pattern, and one with
the negated form. Is this the reason this should be added?
>
> - https://issues.jboss.org/browse/GUVNOR-1284 (negate pattern)
>
> Simple preceding any single (!) pattern with not is possible right now -
you just write "not" in front of the type.
Cheers
Wolfgang
>
> 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> 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> 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> wrote:
>>>
>>>> Hello Michael,
>>>>
>>>> On 1 April 2011 09:01, Michael Anstis
<michael.anstis(a)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>
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>
>>>>>> 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
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:48 p.m.
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.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
4770
days inactive
4774
days old
16 comments
5 participants
participants (5)
-
Greg Barton -
Mark Proctor -
Michael Anstis -
Michael Neale -
Wolfgang Laun