[
https://issues.jboss.org/browse/JBRULES-1075?page=com.atlassian.jira.plug...
]
Edson Tirelli commented on JBRULES-1075:
----------------------------------------
Geoffrey,
Just for documentation purposes for possible readers of this thread, I will state here
what we discussed before:
* the problem you describe is inherent to the accumulate function implementation of the
default functions that ship with drools. On the other hand, anyone dealing with data that
requires precision can easily implement their own accumulate functions using BigDecimal,
BigIntegers or whatever data type best fits their requirement and they will have no
rounding problems at all.
* the automatic selection of different functions based on the result type of the
expression is tricky as it is not always possible to determine the result type. It would
also be dangerous to those same users that you mention (like those doing financial
calculations) as they must guarantee that a given function implementation is being used
and not let the engine chose based on types that can mutate due to inheritance. Finally,
it also requires users to always provide multiple function implementations for each
datatype supported. I still intend to add a feature to do that, but at the moment I am not
convinced this is the best way of doing it, so I haven't prioritized this ticket yet.
If anyone has a better suggestion, I am open to ideas.
Edson
Support overloading of accumulate functions: Add int (or long) based
sum's, int based avarage's, etc
-----------------------------------------------------------------------------------------------------
Key: JBRULES-1075
URL:
https://issues.jboss.org/browse/JBRULES-1075
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.0.GA
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Minor
Fix For: FUTURE
Attachments: JBRULES-1075.patch
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to
sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a
sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be
theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors.
For example
sum($myString)
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira