RE: [rules-users] determinism with rulebase partitioning

2008-07-31 Thread Anstis, Michael (M.)
Hi Mark,

A few questions:-

(A) What does "parallel evaluation of a rulebase" mean? Is it designed
to optimise, for example, two threads processing a stateless and
stateful session?

(B) Are there only two partitions, both of which are invisible to the
user? Is there any value in allowing user-defined partitions?

(C) Does the partition used depend upon what type of session is used
(i.e. stateless always uses the partition without an agenda whereas
stateful always uses the partition with an agenda)?

(D) Can a rule sometimes be deterministic and sometimes not (i.e.
depends upon the type of session)?

Cheers,

Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Proctor
Sent: 01 August 2008 07:05
To: Rules Users List
Subject: [rules-users] determinism with rulebase partitioning

We have rulebase partitioning almost working, this allows parallel 
evaluation of a rulebase. For stateless lessions with no agenda this 
will allow for much faster executions, where you don't care about 
deterministic execution. However for deterministic execution its more 
complicated. The current plan is to have an agenda per parition, which 
means that we no longer have rulebase wide deterministic execution 
order, only with the partition itself. The user is unlikely to be aware 
of the created partitions, so won't be aware of the unditermistic 
behavour of their rulebase. Anyone have any input on mechanisms users 
can do to help the rulebase know what needs to be executed 
deterministically and what doesn't?

Mark
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


[rules-users] determinism with rulebase partitioning

2008-07-31 Thread Mark Proctor
We have rulebase partitioning almost working, this allows parallel 
evaluation of a rulebase. For stateless lessions with no agenda this 
will allow for much faster executions, where you don't care about 
deterministic execution. However for deterministic execution its more 
complicated. The current plan is to have an agenda per parition, which 
means that we no longer have rulebase wide deterministic execution 
order, only with the partition itself. The user is unlikely to be aware 
of the created partitions, so won't be aware of the unditermistic 
behavour of their rulebase. Anyone have any input on mechanisms users 
can do to help the rulebase know what needs to be executed 
deterministically and what doesn't?


Mark
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] Reusing predicates

2008-07-31 Thread Kris Nuttycombe
Thanks; my primary concern was the code replication, so I'll go with
the intermediate fact approach.

Kris

On Thu, Jul 31, 2008 at 4:54 PM, Edson Tirelli <[EMAIL PROTECTED]> wrote:
>
>Not sure if you are worried about syntax or performance. If you are
> worried about performance, just write your common Patterns in the same order
> among your multiple rules and the engine will reuse them.
>
>If you are worried about the syntax, i.e. not replicating the same code
> among multiple rules, the intermediate fact is probably the best solution
> right now. We want to implement rule inheritance or rule templates, but we
> don't have it yet.
>
>[]s
>Edson
>
> 2008/7/31 Kris Nuttycombe <[EMAIL PROTECTED]>
>>
>> Hi, all,
>>
>> I have a set of rules where the LHS is essentially the same except for
>> a couple of additional conditions in each case. What is the best way
>> to factor out these common predicates? Should I simply create an
>> intermediate fact based upon the common set of conditions and then
>> reason with that fact, or is there a way of reusing them without
>> adding another fact to the mix?
>>
>> Thanks,
>>
>> Kris
>> ___
>> rules-users mailing list
>> rules-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss, a division of Red Hat @ www.jboss.com
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] Reusing predicates

2008-07-31 Thread Edson Tirelli
   Not sure if you are worried about syntax or performance. If you are
worried about performance, just write your common Patterns in the same order
among your multiple rules and the engine will reuse them.

   If you are worried about the syntax, i.e. not replicating the same code
among multiple rules, the intermediate fact is probably the best solution
right now. We want to implement rule inheritance or rule templates, but we
don't have it yet.

   []s
   Edson

2008/7/31 Kris Nuttycombe <[EMAIL PROTECTED]>

> Hi, all,
>
> I have a set of rules where the LHS is essentially the same except for
> a couple of additional conditions in each case. What is the best way
> to factor out these common predicates? Should I simply create an
> intermediate fact based upon the common set of conditions and then
> reason with that fact, or is there a way of reusing them without
> adding another fact to the mix?
>
> Thanks,
>
> Kris
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] Compiling .drl files inside of a JUnit test

2008-07-31 Thread Edson Tirelli
   Right now, Drools uses JUnit for all its unit and integration tests. Take
a look at the integration tests and I think you will figure out:

http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-compiler/src/test/java/org/drools/integrationtests/

   []s
   Edson

2008/7/31 Ron Kneusel <[EMAIL PROTECTED]>

>
> I'm sure other people have run into this.  I'm trying to build a unit test
> that checks the compilation of an external .drl file.  My questions are:
>  How do I get the compiler to locate all the .class files that I reference?
>  When JUnit runs, where does it run from or how can its runtime classpath be
> manipulated?
>
> Any help appreciated!
>
> Ron
>
> _
> Keep your kids safer online with Windows Live Family Safety.
>
> http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_family_safety_072008
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


[rules-users] Reusing predicates

2008-07-31 Thread Kris Nuttycombe
Hi, all,

I have a set of rules where the LHS is essentially the same except for
a couple of additional conditions in each case. What is the best way
to factor out these common predicates? Should I simply create an
intermediate fact based upon the common set of conditions and then
reason with that fact, or is there a way of reusing them without
adding another fact to the mix?

Thanks,

Kris
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


[rules-users] Compiling .drl files inside of a JUnit test

2008-07-31 Thread Ron Kneusel

I'm sure other people have run into this.  I'm trying to build a unit test that 
checks the compilation of an external .drl file.  My questions are:  How do I 
get the compiler to locate all the .class files that I reference?  When JUnit 
runs, where does it run from or how can its runtime classpath be manipulated?

Any help appreciated!

Ron

_
Keep your kids safer online with Windows Live Family Safety.
http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_family_safety_072008
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] "Not" Non-Existential Quantifier

2008-07-31 Thread Ingomar Otter

Hans,
I checked the docs and as  Edson says it should work without the  
exists( ).

Strange that never worked for me.

Maybe we all learn something if you can carve out a test-case.
Strange.

--I

Am 31.07.2008 um 19:29 schrieb [EMAIL PROTECTED]:


Ingomar,

I tried this, and indeed that worked. I was surprised, as I thought  
"not" was meant more to mean that a fact inside its parentheses did  
not exist, rather than a logical negation, which is the way you used  
it in your example. However, if I do what you said, it does work  
exactly how I expected "not" alone to work.


Thanks!
-Hans

-- Original message --
From: Ingomar Otter <[EMAIL PROTECTED]>


Hans,
If you change "not NegativeResult()" to "not (exits
NegativeResult())" this should result in the expected behaviour.

Cheers,
Ingomar

Am 31.07.2008 um 17:19 schrieb [EMAIL PROTECTED]:


How is "not" supposed to work with insertLogical? Assume I have two
different rules whose conditions are mutually exclusive, like the
following:
rule "Rule One"
when
not NegativeResult()
then
insertLogical(new ApplicantStatus("Approved"));
end
rule "Rule Two"
when
NegativeResult()
then
insertLogical(new ApplicantStatus("Denied"));
end
Assume that the above two rules are the only way an ApplicantStatus
fact can be inserted into working memory. I would expect, after all
rules are run, that it would be impossible for there to be one
ApplicantStatus with "Approved" as its reason, and another with
"Denied" as its reason, in the working memory.
I would expect that, before any NegativeResult is inserted, that
rule one could run, and insert an ApplicantStatus fact with an
"Approved" reason. Then, after a NegativeResult is inserted, that
rule two could run, and insert an ApplicantStatus fact with a
"Denied" reason. At this point I would expect that the original
ApplicantStatus fact, with an "Approved" reason, would be retracted,
since the conditions under which it was inserted are no longer true.
This is not what I am observing, however. I am finding
ApplicantStatus facts with both reasons in working memory at the end
of the rules run. Should "not" work as I expect with regard to
inserting a fact via insertLogical()? Or is this a known limitation,
or simply the way it is designed to work?
Thanks,
-Hans___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] "Not" Non-Existential Quantifier

2008-07-31 Thread Edson Tirelli
   Hmm, in this case, it is definitively a bug. "not" IS the existential
qualifier, i.e., the constrary of exists. So it should be simply redundant
to write "not exists". Need to investigate that.

   []s
   Edson

2008/7/31 <[EMAIL PROTECTED]>

> Ingomar,
>
> I tried this, and indeed that worked. I was surprised, as I thought "not"
> was meant more to mean that a fact inside its parentheses did not exist,
> rather than a logical negation, which is the way you used it in your
> example. However, if I do what you said, it does work exactly how I expected
> "not" alone to work.
>
> Thanks!
> -Hans
>
>
> -- Original message --
> From: Ingomar Otter <[EMAIL PROTECTED]>
>
> > Hans,
> > If you change "not NegativeResult()" to "not (exits
> > NegativeResult())" this should result in the expected behaviour.
> >
> > Cheers,
> > Ingomar
> >
> > Am 31.07.2008 um 17:19 schrieb [EMAIL PROTECTED]:
> >
> > > How is "not" supposed to work with insertLogical? Assume I have two
> > > different rules whose conditions are mutually exclusive, like the
> > > following:
> > > rule "Rule One"
> > > when
> > > not NegativeResult()
> > > then
> > > insertLogical(new ApplicantStatus("Approved"));
> > > end
> > > rule "Rule Two"
> > > when
> > > NegativeResult()
> > > then
> > > insertLogical(new ApplicantStatus("Denied")); > > end
> > > Assume that the above two rules are the only way an ApplicantStatus
> > > fact can be inserted into working memory. I would expect, after all
> > > rules are run, that it would be impossible for there to be one
> > > ApplicantStatus with "Approved" as its reason, and another with
> > > "Denied" as its reason, in the working memory.
> > > I would expect that, before any NegativeResult is inserted, that
> > > rule one could run, and insert an ApplicantStatus fact with an
> > > "Approved" reason. Then, after a NegativeResult is inserted, that
> > > rule two could run, and insert an ApplicantStatus fact with a
> > > "Denied" reason. At this point I would expect that the original
> > > ApplicantStatus fact, with an "Approved" reason, would be retracted,
> > > since the conditions under which it was inserted are no longer true.
> > > This is not what I am observin! g, howe ver. I am finding
> > > ApplicantStatus facts with both reasons in working memory at the end
> > > of the rules run. Should "not" work as I expect with regard to
> > > inserting a fact via insertLogical()? Or is this a known limitation,
> > > or simply the way it is designed to work?
> > > Thanks,
> > > -Hans___
> > > rules-users mailing list
> > > rules-users@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> > ___
> > rules-users mailing list
> > rules-users@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>


-- 
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] "Not" Non-Existential Quantifier

2008-07-31 Thread Edson Tirelli
   Hans,

   Your reasoning is correct. There should not be 2 instances of
ApplicantStatus in the working memory.

   Can you provide a test case showing the problem? we have test cases here
using "not" and logical assertions, and it works properly.

   Thanks,
   Edson

2008/7/31 <[EMAIL PROTECTED]>

>  How is "
> not" supposed to work with insertLogical? Assume I have two different
> rules whose conditions are mutually exclusive, like the following:*
>
> rule
> * "Rule One"
>
> *when*
>
> not NegativeResult()
>
> *then*
>
> *insertLogical*(new ApplicantStatus("Approved"));*
>
> end
> **
>
> rule
> * "Rule Two"
>
> *when*
>
> NegativeResult()
>
> *then*
>
> *insertLogical*(new ApplicantStatus("Denied"));*
>
> end
> *
>
> Assume that the above two rules are the only way an
> ApplicantStatus fact can be inserted into working memory. I would expect,
> after all rules are run, that it would be impossible for there to be one
> ApplicantStatus with "Approved" as its reason, and another with "Denied"as 
> its reason, in the working memory.
>
> I would expect that, before any
> NegativeResult is inserted, that rule one could run, and insert an
> ApplicantStatus fact with an "Approved" reason. Then, after a
> NegativeResult is inserted, that rule two could run, and insert an
> ApplicantStatus fact with a "Denied" reason. At this point I would expect
> that the original ApplicantStatus fact, with an "Approved" reason, would
> be retracted, since the conditions under which it was inserted are no longer
> true.
>
> This is not what I am observing, however. I am finding
> ApplicantStatus facts with both reasons in working memory at the end of
> the rules run. Should "not" work as I expect with regard to inserting a fact
> via insertLogical()? Or is this a known limitation, or simply the way it
> is designed to work?
>
> Thanks,
>
> -Hans
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>


-- 
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] "Not" Non-Existential Quantifier

2008-07-31 Thread ringsah
Ingomar,

I tried this, and indeed that worked. I was surprised, as I thought "not" was 
meant more to mean that a fact inside its parentheses did not exist, rather 
than a logical negation, which is the way you used it in your example. However, 
if I do what you said, it does work exactly how I expected "not" alone to work.

Thanks!
-Hans

-- Original message -- 
From: Ingomar Otter <[EMAIL PROTECTED]> 

> Hans, 
> If you change "not NegativeResult()" to "not (exits 
> NegativeResult())" this should result in the expected behaviour. 
> 
> Cheers, 
> Ingomar 
> 
> Am 31.07.2008 um 17:19 schrieb [EMAIL PROTECTED]: 
> 
> > How is "not" supposed to work with insertLogical? Assume I have two 
> > different rules whose conditions are mutually exclusive, like the 
> > following: 
> > rule "Rule One" 
> > when 
> > not NegativeResult() 
> > then 
> > insertLogical(new ApplicantStatus("Approved")); 
> > end 
> > rule "Rule Two" 
> > when 
> > NegativeResult() 
> > then 
> > insertLogical(new ApplicantStatus("Denied")); 
> > end 
> > Assume that the above two rules are the only way an ApplicantStatus 
> > fact can be inserted into working memory. I would expect, after all 
> > rules are run, that it would be impossible for there to be one 
> > ApplicantStatus with "Approved" as its reason, and another with 
> > "Denied" as its reason, in the working memory. 
> > I would expect that, before any NegativeResult is inserted, that 
> > rule one could run, and insert an ApplicantStatus fact with an 
> > "Approved" reason. Then, after a NegativeResult is inserted, that 
> > rule two could run, and insert an ApplicantStatus fact with a 
> > "Denied" reason. At this point I would expect that the original 
> > ApplicantStatus fact, with an "Approved" reason, would be retracted, 
> > since the conditions under which it was inserted are no longer true. 
> > This is not what I am observing, however. I am finding 
> > ApplicantStatus facts with both reasons in working memory at the end 
> > of the rules run. Should "not" work as I expect with regard to 
> > inserting a fact via insertLogical()? Or is this a known limitation, 
> > or simply the way it is designed to work? 
> > Thanks, 
> > -Hans___ 
> > rules-users mailing list 
> > rules-users@lists.jboss.org 
> > https://lists.jboss.org/mailman/listinfo/rules-users 
> 
> ___ 
> rules-users mailing list 
> rules-users@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/rules-users ___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] "Not" Non-Existential Quantifier

2008-07-31 Thread Ingomar Otter

Hans,
If you change "not NegativeResult()"  to "not (exits  
NegativeResult())" this should result in the expected behaviour.


Cheers,
  Ingomar

Am 31.07.2008 um 17:19 schrieb [EMAIL PROTECTED]:

How is "not" supposed to work with insertLogical? Assume I have two  
different rules whose conditions are mutually exclusive, like the  
following:

rule "Rule One"
when
not NegativeResult()
then
insertLogical(new ApplicantStatus("Approved"));
end
rule "Rule Two"
when
NegativeResult()
then
insertLogical(new ApplicantStatus("Denied"));
end
Assume that the above two rules are the only way an ApplicantStatus  
fact can be inserted into working memory. I would expect, after all  
rules are run, that it would be impossible for there to be one  
ApplicantStatus with "Approved" as its reason, and another with  
"Denied" as its reason, in the working memory.
I would expect that, before any NegativeResult is inserted, that  
rule one could run, and insert an ApplicantStatus fact with an  
"Approved" reason. Then, after a NegativeResult is inserted, that  
rule two could run, and insert an ApplicantStatus fact with a  
"Denied" reason. At this point I would expect that the original  
ApplicantStatus fact, with an "Approved" reason, would be retracted,  
since the conditions under which it was inserted are no longer true.
This is not what I am observing, however. I am finding  
ApplicantStatus facts with both reasons in working memory at the end  
of the rules run. Should "not" work as I expect with regard to  
inserting a fact via insertLogical()? Or is this a known limitation,  
or simply the way it is designed to work?

Thanks,
-Hans___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] Finding a sequence within the data

2008-07-31 Thread Anders Hansen

Couldn't you accomplish what you are looking for using the "from collect"

http://downloads.jboss.com/drools/docs/4.0.7.19894.GA/html_single/index.html#d0e3968

So, applied to your example it would be something like the following.  Note, 
I'm not sure how patient is tied to your LabResult, but I added in what I 
thought it might be b/c you'd want to constrain the fact that there were 3 or 
more results for a given patient, not just 3 or more lab results for all 
patients in the current working memory.

import java.util.ArrayList

rule "patients that have at least 3 consecutive LabResults with value<1 in the 
last month"
when
        $patient: Patient()
        $results : ArrayList( size >= 3 )
                            from collect( LabResult( patient == $patient, value 
< 1, eval( inLastMonth(date) ) )
then
    # Do Something
end


--- On Wed, 7/30/08, Yoni Mazar <[EMAIL PROTECTED]> wrote:
From: Yoni Mazar <[EMAIL PROTECTED]>
Subject: [rules-users] Finding a sequence within the data
To: rules-users@lists.jboss.org
Date: Wednesday, July 30, 2008, 12:12 PM

Hi again,

Sorry for nagging, but I'm failing again and again to implement simple
business logic using rules.
Lets assume, we have LabResult facts with date and value fields. The
business requirement is to detect "patients that have at least 3
consecutive
LabResults with value<1 in the last month".
detecting one fact is simple:
LabResult(value<1 && eval(inLastMonth(date)))
But detecting 2 consecutive facts, actually requires that there is not a
third fact in the middle with value >= 1!
something like:

LabResult(value<1, date1:date, eval(inLastMonth(date1))), 
LabResult(value<1, date2:date, eval(inLastMonth(date2))), 
eval(date1.before(date2)),
not(   LabResult(value>=1, date3:date, eval(inLastMonth(date3))),
eval(date1.before(date3))
eval(date3.before(date2)) )

Now, imagine how to detect 3 consecutive facts...

Does someone has a simple idea how to implement this? How comes that one
English sentence is translated to so many lines of code?

Thanks for the help, Yoni

-- 
View this message in context:
http://www.nabble.com/Finding-a-sequence-within-the-data-tp18738051p18738051.html
Sent from the drools - user mailing list archive at Nabble.com.

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



  ___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


[rules-users] "Not" Non-Existential Quantifier

2008-07-31 Thread ringsah
How is "not" supposed to work with insertLogical? Assume I have two different 
rules whose conditions are mutually exclusive, like the following:
rule "Rule One"
when
not NegativeResult()
then 
insertLogical(new ApplicantStatus("Approved"));
end
rule "Rule Two"
when
NegativeResult()
then 
insertLogical(new ApplicantStatus("Denied"));
end
Assume that the above two rules are the only way an ApplicantStatus fact can be 
inserted into working memory. I would expect, after all rules are run, that it 
would be impossible for there to be one ApplicantStatus with "Approved" as its 
reason, and another with "Denied" as its reason, in the working memory.
I would expect that, before any NegativeResult is inserted, that rule one could 
run, and insert an ApplicantStatus fact with an "Approved" reason. Then, after 
a NegativeResult is inserted, that rule two could run, and insert an 
ApplicantStatus fact with a "Denied" reason. At this point I would expect that 
the original ApplicantStatus fact, with an "Approved" reason, would be 
retracted, since the conditions under which it was inserted are no longer true.
This is not what I am observing, however. I am finding ApplicantStatus facts 
with both reasons in working memory at the end of the rules run. Should "not" 
work as I expect with regard to inserting a fact via insertLogical()? Or is 
this a known limitation, or simply the way it is designed to work?
Thanks,
-Hans___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] Finding a sequence within the data

2008-07-31 Thread Yoni Mazar

One more question. 
http://blog.athico.com/2008/07/drools-50-m1-new-and-noteworthy.html Here  
there is description of CEP. Do you think CEP can help us analyzing this
data? 
Thanks, Yoni

Thanks for the help. We will use your ideas


   Hehe, never underestimate creativity... :) nice solution.

   []s
   Edson

2008/7/31 Greg Barton <[EMAIL PROTECTED]>

> Never underestimate the value of data structures.
> Give LabResult a pointer to the next (or previous)
> LabResult.  Then the rule becomes more comprehensible:
>
> $l1 : LabResult( value < 1, eval( inLastMonth(date) )
> $l2 : LabResult( value < 1, eval( inLastMonth(date),
> next == $l1 )
> $l3 : LabResult( value < 1, eval( inLastMonth(date),
> next == $l2 )
>
> It's also more easily extensible to longer sequences.
>
> GreG
>
>
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

-- 
View this message in context: 
http://www.nabble.com/Finding-a-sequence-within-the-data-tp18738051p18755241.html
Sent from the drools - user mailing list archive at Nabble.com.

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] Finding a sequence within the data

2008-07-31 Thread Yoni Mazar

Thanks for the help. We will use your ideas


Edson Tirelli-3 wrote:
> 
>Hehe, never underestimate creativity... :) nice solution.
> 
>[]s
>Edson
> 
> 2008/7/31 Greg Barton <[EMAIL PROTECTED]>
> 
>> Never underestimate the value of data structures.
>> Give LabResult a pointer to the next (or previous)
>> LabResult.  Then the rule becomes more comprehensible:
>>
>> $l1 : LabResult( value < 1, eval( inLastMonth(date) )
>> $l2 : LabResult( value < 1, eval( inLastMonth(date),
>> next == $l1 )
>> $l3 : LabResult( value < 1, eval( inLastMonth(date),
>> next == $l2 )
>>
>> It's also more easily extensible to longer sequences.
>>
>> GreG
>>
>>
>>
>> ___
>> rules-users mailing list
>> rules-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> 
> 
> 
> -- 
> Edson Tirelli
> JBoss Drools Core Development
> JBoss, a division of Red Hat @ www.jboss.com
> 
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
> 
> 
:-):-):-)
-- 
View this message in context: 
http://www.nabble.com/Finding-a-sequence-within-the-data-tp18738051p18754533.html
Sent from the drools - user mailing list archive at Nabble.com.

___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Re: [rules-users] Finding a sequence within the data

2008-07-31 Thread Edson Tirelli
   Hehe, never underestimate creativity... :) nice solution.

   []s
   Edson

2008/7/31 Greg Barton <[EMAIL PROTECTED]>

> Never underestimate the value of data structures.
> Give LabResult a pointer to the next (or previous)
> LabResult.  Then the rule becomes more comprehensible:
>
> $l1 : LabResult( value < 1, eval( inLastMonth(date) )
> $l2 : LabResult( value < 1, eval( inLastMonth(date),
> next == $l1 )
> $l3 : LabResult( value < 1, eval( inLastMonth(date),
> next == $l2 )
>
> It's also more easily extensible to longer sequences.
>
> GreG
>
>
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users