12:07 p.m.
Has anybody ever seen a situation where a couple of patterns such as
Fact( field >= 10 )
not Fact( field > 20 )
was appropriate? This does not match Facts where field isn't between 10 and
20, and so it would seem to be the same as
Fact( field >= 10 && <= 20 )
but actually it doesn't match any such Fact whenever any *other* Fact with
field > 20 is around.
Cheers
Wolfgang
12:47 p.m.
I haven't seen it personally, but I can imagine a situation where it would be useful.
Say you're reading temperatures, with readings retracted after a given time. If you
wanted a rule that meant "find a reading above 10 if there's never been a reading
above 20" you'd use the pattern below.
Maybe a better example would be alerting aircraft delays at an airport. This wasn't a
requirement for the system I worked on, but say you wanted to mark all delays over a given
threshold at one level of severity, but bump all delays to another level of severity if
one goes over another threshold. (Meaning, "Ger yer house in order now!") That
would use this pattern as well:
when d: Delay(duration > 10) not Delay(duration >
20)then d.setSeverity("meh");end
when d: Delay(duration > 10) Delay(duration >=
20)then d.setSeverity("DOH!");end
--- On Thu, 3/24/11, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
Subject: [rules-dev] An odd couple of patterns
To: "Rules Dev List" <rules-dev(a)lists.jboss.org>
Date: Thursday, March 24, 2011, 12:07 PM
Has anybody ever seen a situation where a couple of patterns such as
Fact( field >= 10 )
not Fact( field > 20 )
was appropriate? This does not match Facts where field isn't between 10 and 20, and so
it would seem to be the same as
Fact( field >= 10 && <= 20 )
but actually it doesn't match any such Fact whenever any other Fact with field > 20
is around.
Cheers
Wolfgang
-----Inline Attachment Follows-----
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
2:03 p.m.
Wolfgang I use patterns like that for a data filtering problem and also
for a preferential selection problem. Any time I have two sources of the
same data and I prefer one over the other that pattern allows you to
pick the secondary source when the preferred data doesn't exist. Also
used in cases where we want to execute a different action in the absence
of the second source.
It also occurs for us when dealing with a list of objects where we have
two sources for the same type of data and we prefer one data source over
the other, but we don't always get data for the preferred source.. We
use your pattern to make sure the preferred source doesn't exist before
using the secondary source
Joe
Here is an example from our code. $ebs is a List<Map>. Mapping to your
example the Map is the fact and the combination of BnftInfoCdoe and
BnftCvgeLevelCode would be the field.:
Map(this[BenefitsConsts.BenefitResponseEligibility.BnftInfoCode] ==
'C',
this[BenefitsConsts.BenefitResponseEligibility.BnftCvgeLevelCode]
== 'IND',
this[BenefitsConsts.BenefitResponseEligibility.SvcTypeCode] ==
"30",
this[BenefitsConsts.BenefitResponseEligibility.CvgePeriodQlfr] == '25',
this[BenefitsConsts.BenefitResponseEligibility.BnftAmt] matches
"0.*") from $ebs
not (Map(this[BenefitsConsts.BenefitResponseEligibility.BnftInfoCode] ==
'C',
this[BenefitsConsts.BenefitResponseEligibility.BnftCvgeLevelCode] ==
'FAM') from $ebs)
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Wolfgang Laun
Sent: Thursday, March 24, 2011 11:07 AM
To: Rules Dev List
Subject: [rules-dev] An odd couple of patterns
Has anybody ever seen a situation where a couple of patterns such as
Fact( field >= 10 )
not Fact( field > 20 )
was appropriate? This does not match Facts where field isn't between 10
and 20, and so it would seem to be the same as
Fact( field >= 10 && <= 20 )
but actually it doesn't match any such Fact whenever any other Fact with
field > 20 is around.
Cheers
Wolfgang
4:01 a.m.
On 24 March 2011 20:03, Joe White <Joe.White(a)recondotech.com> wrote:
Wolfgang I use patterns like that for a data filtering problem and
also for
a preferential selection problem. Any time I have two sources of the same
data and I prefer one over the other that pattern allows you to pick the
secondary source when the preferred data doesn’t exist. Also used in cases
where we want to execute a different action in the absence of the second
source.
It also occurs for us when dealing with a list of objects where we have two
sources for the same type of data and we prefer one data source over the
other, but we don’t always get data for the preferred source.. We use your
pattern to make sure the preferred source doesn’t exist before using the
secondary source
So you distinguish "source" by ranges of a numeric property? This is
unusual. For your use case I'd expect something like
not Data( source == Source.PRIM )
Data( source == Source.SEC, ... )
To clarify, here is the rule logic I posted, written with a redundant
constraint in the first pattern.
Fact( field >= 10 && field <= 20 ) // if > 20, LHS fails due to
"not"
not Fact( field > 20 )
Thanks
Wolfgang
Joe
Here is an example from our code. $ebs is a List<Map>. Mapping to your
example the Map is the fact and the combination of BnftInfoCdoe and
BnftCvgeLevelCode would be the field.:
Map(*this*[BenefitsConsts.BenefitResponseEligibility.BnftInfoCode] ==
'C',
*this*[BenefitsConsts.BenefitResponseEligibility.BnftCvgeLevelCode]
== 'IND',
*this*[BenefitsConsts.BenefitResponseEligibility.SvcTypeCode] ==
"30",
*this*[BenefitsConsts.BenefitResponseEligibility.CvgePeriodQlfr] == '25',
*this*[BenefitsConsts.BenefitResponseEligibility.BnftAmt] *matches*
"0.*") *from* $ebs
*not* (Map(*this*[BenefitsConsts.BenefitResponseEligibility.BnftInfoCode]
== 'C',
*this*[BenefitsConsts.BenefitResponseEligibility.BnftCvgeLevelCode]
== 'FAM') *from* $ebs)
*From:* rules-dev-bounces(a)lists.jboss.org [mailto:
rules-dev-bounces(a)lists.jboss.org] *On Behalf Of *Wolfgang Laun
*Sent:* Thursday, March 24, 2011 11:07 AM
*To:* Rules Dev List
*Subject:* [rules-dev] An odd couple of patterns
Has anybody ever seen a situation where a couple of patterns such as
Fact( field >= 10 )
not Fact( field > 20 )
was appropriate? This does not match Facts where field isn't between 10 and
20, and so it would seem to be the same as
Fact( field >= 10 && <= 20 )
but actually it doesn't match any such Fact whenever any *other* Fact with
field > 20 is around.
Cheers
Wolfgang
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
4:05 a.m.
(Sorry, I didn't read on after the signature.)
On 24 March 2011 20:03, Joe White <Joe.White(a)recondotech.com> wrote:
Here is an example from our code. $ebs is a List<Map>. Mapping to your
example the Map is the fact and the combination of BnftInfoCdoe and
BnftCvgeLevelCode would be the field.:
The positive and negative pattern aren't in conflict in a range of numeric
values, and so yours is not the pattern I'm concerned with.
Notice that I'd put the "not" CE up front.
Map(*this*[BenefitsConsts.BenefitResponseEligibility.BnftInfoCode]
==
'C',
*this*[BenefitsConsts.BenefitResponseEligibility.BnftCvgeLevelCode]
== 'IND',
*this*[BenefitsConsts.BenefitResponseEligibility.SvcTypeCode] ==
"30",
*this*[BenefitsConsts.BenefitResponseEligibility.CvgePeriodQlfr] == '25',
*this*[BenefitsConsts.BenefitResponseEligibility.BnftAmt] *matches*
"0.*") *from* $ebs
*not* (Map(*this*[BenefitsConsts.BenefitResponseEligibility.BnftInfoCode]
== 'C',
*this*[BenefitsConsts.BenefitResponseEligibility.BnftCvgeLevelCode]
== 'FAM') *from* $ebs)
Cheers
Wolfgang
4781
days inactive
4782
days old
4 comments
3 participants
participants (3)
-
Greg Barton -
Joe White -
Wolfgang Laun