Re: [rules-dev] SumIntegerAccumulateFunction not possible?

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 _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev