-
Bug
-
Resolution: Duplicate
-
Critical
-
None
-
None
-
None
-
None
When dealing with financial data, one should never ever use double's. Instead BigDecimal should be used.
Not because BigDecimal is bigger (that's rarely a problem) but because it doesn't do any decimal to binary transformation.
For example, it's impossible for a double to correctly represent "0.2", aka 1/5.
Summing many doubles (or even a few differing in scale), can easily give wrong results (and for financial data this tends to be important).
Using doubles to sum longs have the exact same problem.
Attached is a testcase patch which proves this by checking if (MAX_LONG - 4L) and 3L sum up to be (MAX_LONG - 1L).
Currently they don't.
One possible way to solve this is to fix JBRULES-1075,
which just happens to give drools-solver 3% more performance what a coincidence ^^
- duplicates
-
DROOLS-1175 Accumulates: sum(Long), sum(BigDecimal), sum(Integer) and sum(BigInteger)
- Closed
- is related to
-
DROOLS-315 Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
- Resolved
-
JBRULES-1074 Support the use of Integer, Float, Short and Byte in accumulate functions
- Closed
-
JBRULES-2749 Various rules stop firing when they are in unlucky packagename and there is a function declared and also a type declared
- Closed