[rules-dev] SumIntegerAccumulateFunction not possible?

[Geoffrey De Smet]

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 at gmail.com 
> <mailto:ge0ffrey.spam at 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 at lists.jboss.org <mailto:rules-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev