Edson Tirelli wrote:
Hey Geoffrey,
Lets talk about short term and long term.
* Long term: we may need to find a way to support primitives. Right now,
primitives are wrapped to simplify custom function developments.
That would be nice indeed. Or at least support all their wrapper types.
Then you can leave it to JIT to optimize it at runtime if performance is
needed.
* Short term: knowing that all primitives are wrapped, we always
recommend you to use Number instead of the concrete wrapper classes
implementations.
public void accumulate(Object context,
Object value) {
SumIntegerAccumulateFunction.SumData data =
(SumIntegerAccumulateFunction.SumData) context;
data.total += ((Number) value).intValue();
}
I 'll probably do a workaround like this for now, but it's a bit slower.
The big advantage will be switching from double to long. That's like
3-5% last I did that switch.
Nevertheless switching from long to int might be noticeable too. I 'd
like to test it in either case :)
Now, the explanation: to add flexibility to the users writing rules
with your function, we support expressions that are MVEL evaluated and
the result is sent to the function implementation. So, in your example,
if the user wanted to sum the double of the distances, he could write
instead:
I am using MVEL? I though I wasn't as I use eval(...) etc?
$totalDistance : Integer() from accumulate(
Hop($distance : distance),
sumInteger( $distance * 2 )
);
So, what goes between () is really any valid mvel expression and as
such, MVEL decides what is the wrapper class to return the result.
Apparently, it is returning a Long for integer type numbers.
Maybe drools could use some sort of overloading of the accumulate function?
A)
sum(int), sum(long), sum(double), ...
Then drools declares that they should always use the same type in one
usage of sum in a rule?
Then if they want to mix double with long, they can do sum((double)
$myDouble)?
B)
Or drools could look at the return type (being Integer in the above
case), but that makes it out of sync with the java spec.
Being brief, it is flexible, powerful and expressive, but it may
require some refactorings in the future to improve performance, if it
becomes an issue.
You know my use case. Performance is everything :)
I can now beat the nl12 TTP record of 2002 in 2 hours.
Once I boost up the performance/scalability some more, I 'll let it run
for a week or more and hope to beat today's records.
Hope it helps.
Help is always welcome :)
Edson
With kind regards,
Geoffrey De Smet
2007/8/11, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com
<mailto:ge0ffrey.spam@gmail.com>>:
It looks like the value objects of the accumulate framework are always
Long's - even when they are Integers?
Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast
to java.lang.Integer
at
org.drools.base.accumulators.SumIntegerAccumulateFunction.accumulate(SumIntegerAccumulateFunction.java:36)
at
org.drools.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java
:79)
Here's the piece of code:
public void accumulate(Object context,
Object value) {
SumIntegerAccumulateFunction.SumData data =
(SumIntegerAccumulateFunction.SumData ) context;
data.total += ((Integer) value).intValue(); // breaks
}
Here's the drl:
when
$totalDistance : Integer() from accumulate(
Hop($distance : distance),
sumInteger($distance)
);
Here's the Hop object:
public int getDistance() {
...
}
Look ma, no longs :) Still a ClassCastException on them though.
I must be missing something really obvious?
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @
www.jboss.com <
http://www.jboss.com>
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev