3:30 a.m.
Compare these three quotes from the current Expert documentation:
(1) Return Value restriction (...) must return results that do not depend on
time.
(2) An inline eval constraint (...) expression (...) expression must be
constant over time.
(3) [CE] Evals (...) are (...) ideal (...) when functions return values that
change over time.
Note that this appears to mean that the behaviour of (1) == (2) != (3).
Many things can or must "change over time:" fact data, global data, results
of constructors such as new Date() or methods such as
System.currentTimeMillis().
So what can I use in an Eval CE that cannot be used in a Return Value or
Inline Eval?
Perhaps this is trying to convey some notion of caching for constraints and
the evaluation strategy for LHS, but then the wording is insufficient. Let's
make an experiment.
Example 1: Given these rules and one pair of facts A, B, which of the three
rules ab1, ab2, ab3 will fire after the last rule (a) fires? There are 8
possible answers. (You may notice that there is some redundancy in each
rule.)
rule ab1
when
A( $va:va, $b: b ) eval( $va + $b.getVb() > 100 )
B( this == $b, $vb: vb ) eval( $va + $vb > 100 )
then
System.out.println( "ab1: a+b > 100" );
end
rule ab2
when
A( $va:va, $b: b , eval( $va + $b.getVb() > 100 ) )
B( this == $b, $vb: vb, eval( $va + $vb > 100 ) )
then
System.out.println( "ab2: a+b > 100" );
end
rule ab3
when
$a: A( $b: b , $va: va > ( 100 - $b.getVb() ) )
B( this == $b, $vb: vb > ( 100 - $a.getVa() ) )
then
System.out.println( "ab3: a+b > 100" );
end
rule a
salience -10
no-loop true
when
$a: A( $va: va )
$b: B( $vb: vb )
then
modify( $b ){ setVb( 200 ) }
end
Example 2: Now change the first line in the when parts according to:
ab1:
A( $va:va, $b: b )
ab2:
A( $va:va, $b: b )
ab3:
$a: A( $b: b )
Which of the three rules ab1, ab2, ab3 will fire now after the last rule (a)
fires?
Wolfgang
PS: Scroll down for the answers.
v
v
v
v
v
v
v
Example 1: None of the rules fires.
Example 2: All three rules fire.
9:12 a.m.
On 14/02/2011 09:30, Wolfgang Laun wrote:
Compare these three quotes from the current Expert documentation:
(1) Return Value restriction (...) must return results that do not
depend on time.
(2) An inline eval constraint (...) expression (...) expression must
be constant over time.
(3) [CE] Evals (...) are (...) ideal (...) when functions return
values that change over time.
There are two aspects here. One was indexing. Field
constraint are
potentially indexed, evals were not. For indexing to work the
evaluations must be time constant or the update and retract fails.
Eval nodes have no joins and no indexing so they are safe from time
sensitive changes.
Drools 4.0 implemented shadow facts in the same way that Jess did.
Further more Drools allows nested access access. When a modify or
retract was done if something had changed and the engine was not aware
of it, or a nested field changed, it effectively broke the engine -
modifies and retracts would not work. Eval was/is slightly less immune
from that.
Drools 5.0 uses tree graph approach and now retracts will always work
and aren't sensitive to any data. Modifies can still potentially be a
problem as it can screw up indexing if you changed a nested field
without notifying the engine. Eval has no indexing, so is not impacted
by this.
Mark
Note that this appears to mean that the behaviour of (1) == (2) != (3).
Many things can or must "change over time:" fact data, global data,
results of constructors such as new Date() or methods such as
System.currentTimeMillis().
So what can I use in an Eval CE that cannot be used in a Return Value
or Inline Eval?
Perhaps this is trying to convey some notion of caching for
constraints and the evaluation strategy for LHS, but then the wording
is insufficient. Let's make an experiment.
Example 1:Given these rules and one pair of facts A, B, which of the
three rules ab1, ab2, ab3 will fire after the last rule (a) fires?
There are 8 possible answers. (You may notice that there is some
redundancy in each rule.)
rule ab1
when
A( $va:va, $b: b ) eval( $va + $b.getVb() > 100 )
B( this == $b, $vb: vb ) eval( $va + $vb > 100 )
then
System.out.println( "ab1: a+b > 100" );
end
rule ab2
when
A( $va:va, $b: b , eval( $va + $b.getVb() > 100 ) )
B( this == $b, $vb: vb, eval( $va + $vb > 100 ) )
then
System.out.println( "ab2: a+b > 100" );
end
rule ab3
when
$a: A( $b: b , $va: va > ( 100 - $b.getVb() ) )
B( this == $b, $vb: vb > ( 100 - $a.getVa() ) )
then
System.out.println( "ab3: a+b > 100" );
end
rule a
salience -10
no-loop true
when
$a: A( $va: va )
$b: B( $vb: vb )
then
modify( $b ){ setVb( 200 ) }
end
Example 2: Now change the first line in the when parts according to:
ab1:
A( $va:va, $b: b )
ab2:
A( $va:va, $b: b )
ab3:
$a: A( $b: b )
Which of the three rules ab1, ab2, ab3 will fire now after the last
rule (a) fires?
Wolfgang
PS: Scroll down for the answers.
v
v
v
v
v
v
v
Example 1: None of the rules fires.
Example 2: All three rules fire.
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:16 a.m.
New subject: Misleading documentation? Eval-uate your understanding!
On 14/02/2011 15:12, Mark Proctor wrote:
On 14/02/2011 09:30, Wolfgang Laun wrote:
> Compare these three quotes from the current Expert documentation:
>
> (1) Return Value restriction (...) must return results that do not
> depend on time.
> (2) An inline eval constraint (...) expression (...) expression must
> be constant over time.
> (3) [CE] Evals (...) are (...) ideal (...) when functions return
> values that change over time.
There are two aspects here. One was indexing. Field constraint are
potentially indexed, evals were not. For indexing to work the
evaluations must be time constant or the update and retract fails.
Eval nodes have no joins and no indexing so they are safe from time
sensitive changes.
Drools 4.0 implemented shadow facts in the same way that Jess did.
Further more Drools allows nested access access. When a modify or
retract was done if something had changed and the engine was not aware
of it, or a nested field changed, it effectively broke the engine -
modifies and retracts would not work. Eval was/is slightly less immune
from that.
Drools 5.0 uses tree graph approach and now retracts will always work
and aren't sensitive to any data. Modifies can still potentially be a
problem as it can screw up indexing if you changed a nested field
without notifying the engine. Eval has no indexing, so is not impacted
by this.
I would add that currently no version of Drools indexes nested fields
constraints. So you aren't seeing the problem above with regards to
indexing and changes of nested fields. It really was more of a future
concern, to make sure your code doesn't break as the engine progresses.
I've just got indexing working for nested accessors in Drools 5.2 so if
anyone is changing nested accessors and not notifying the engine, that
will now be broken :)
Mark
Mark
>
> Note that this appears to mean that the behaviour of (1) == (2) != (3).
>
> Many things can or must "change over time:" fact data, global data,
> results of constructors such as new Date() or methods such as
> System.currentTimeMillis().
>
> So what can I use in an Eval CE that cannot be used in a Return Value
> or Inline Eval?
>
> Perhaps this is trying to convey some notion of caching for
> constraints and the evaluation strategy for LHS, but then the wording
> is insufficient. Let's make an experiment.
>
> Example 1:Given these rules and one pair of facts A, B, which of the
> three rules ab1, ab2, ab3 will fire after the last rule (a) fires?
> There are 8 possible answers. (You may notice that there is some
> redundancy in each rule.)
>
> rule ab1
> when
> A( $va:va, $b: b ) eval( $va + $b.getVb() > 100 )
> B( this == $b, $vb: vb ) eval( $va + $vb > 100 )
> then
> System.out.println( "ab1: a+b > 100" );
> end
>
> rule ab2
> when
> A( $va:va, $b: b , eval( $va + $b.getVb() > 100 ) )
> B( this == $b, $vb: vb, eval( $va + $vb > 100 ) )
> then
> System.out.println( "ab2: a+b > 100" );
> end
>
> rule ab3
> when
> $a: A( $b: b , $va: va > ( 100 - $b.getVb() ) )
> B( this == $b, $vb: vb > ( 100 - $a.getVa() ) )
> then
> System.out.println( "ab3: a+b > 100" );
> end
>
> rule a
> salience -10
> no-loop true
> when
> $a: A( $va: va )
> $b: B( $vb: vb )
> then
> modify( $b ){ setVb( 200 ) }
> end
>
> Example 2: Now change the first line in the when parts according to:
> ab1:
> A( $va:va, $b: b )
> ab2:
> A( $va:va, $b: b )
> ab3:
> $a: A( $b: b )
>
> Which of the three rules ab1, ab2, ab3 will fire now after the last
> rule (a) fires?
>
> Wolfgang
>
> PS: Scroll down for the answers.
>
> v
>
>
> v
>
>
> v
>
>
> v
>
>
> v
>
>
> v
>
>
> v
>
>
> Example 1: None of the rules fires.
> Example 2: All three rules fire.
>
>
>
> _______________________________________________
> 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
5079
days inactive
5079
days old
2 comments
2 participants
participants (2)
-
Mark Proctor -
Wolfgang Laun