-
Feature Request
-
Resolution: Duplicate
-
Critical
-
None
-
None
-
None
-
None
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
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)
- duplicates
-
DROOLS-1175 Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
- Closed
- is blocked by
-
JBRULES-1074 Support the use of Integer, Float, Short and Byte in accumulate functions
- Closed
- relates to
-
DROOLS-314 Build in accumulate functions are highly unreliable for long's and BigDecimals
- Closed