See inline.

On 14/08/2013, Raphael Jolivet <raphael.jolivet@gmail.com> wrote:
> Hi Drools guys.
>
> I just asked the following question on

> StackOverlow<http://stackoverflow.com/questions/18219841/using-drools-fusion-to-compute-overlaps-of-many-intervals>

> .
> Could you please help :
>

> I am already using Drools to do some *preprocessing of an allocation
> problem
> * (resources vs operations). The operations are already time *intervals*

> but
> I did not need to leverage the Drools Fusion features yet.
>

> There is a new requirement for having some *attributes of my resources
> changing over time*.
>
> I am willing to model this (the change of values over time) as *"events" in
> Drools* and take advantage of Drools Fusion, in *Cloud* mode.

>
> Hence I will have to match those "dynamic" attributes events against my
> operations (again declared as events in Drools fusion). This will require

> Drools to *compute a great amount of intervals overlaps*.
>
> I have several questions :
>
>    - I have found the *overlap* operator to be kind of counter-intuitive,
>    and to not actually process*overlap* as we usually describe it.

The definition of temporal operators in Drools follows
well-established research. The intent is to be able to pinpoint very
specific relations, with more general or symmetric relations requiring
disjunctions.

> I would
>    expect [a;b] and [c;d] to overlap if *(b > c) and (a < c)*. Is there a

>    time operator for that ?

There are only those described in the Fusion manual.

> Or should I use a composition of several time
>    operators ?

Basically: yes, but see below.

>    - Does Drools Fusion uses any kind of internal optimization for this
>    kind of problem ?

Not anything beyond the optimization provided by Rete (or whatever
algorithm the Engine uses). You can look at the implementations of the
operators: it's a pretty straightforward set of comparison, although
the operator parameters add a level of complexity.

You probably should implement your specific concept of "overlap" as a
custom operator.

> Naively matching N intervals against M intervals would

>    require *0(N x M)* operations. I have found a way to go down to *(M x
>    log(M) + N x log(N))*, by sorting the intervals beforehand : Should I

>    prepare the pair of overlaps for Drools in advance ?

You may have to design an approach that accumulates events as they
occur, determining whether a new event is one that joins a set of
overlapping events or not.

>    - Related to the previous question : Is there any benefit in this case
>    (in term of performances), of using *Drools Fusion* instead of *regular
>    Drools* together with conditions over timestamps and duration ?

Drools Fusion *is* what you call "regular Drools". It is just a
marketing curlicue, to put a tag on a relatively small set of
features: timestamp/duration, temporal ops, windows, cloud/stream, and
event expiry. But there's only one Engine. Especially temporal
operators is just syntactic sugar.

-W

>
> Thanks for your advice
> Brgds,
>
> -- Raphael
>

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