[
http://jira.jboss.com/jira/browse/JBRULES-1322?page=comments#action_12405014 ]
Geoffrey De Smet commented on JBRULES-1322:
-------------------------------------------
Here's a good way to test it:
java.math.BigDecimal a = new java.math.BigDecimal("45.1");
java.math.BigDecimal b = new java.math.BigDecimal("40.0");
double c = a.doubleValue() - b.doubleValue();
return new java.math.BigDecimal(c);
(java.math.BigDecimal) 5.10000000000000142108547152020037174224853515625
Accumulate functions are highly unreliable for long's and
BigDecimals
---------------------------------------------------------------------
Key: JBRULES-1322
URL:
http://jira.jboss.com/jira/browse/JBRULES-1322
Project: JBoss Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assigned To: Edson Tirelli
Priority: Critical
Fix For: 5.0.0-M1
Attachments: JBRULES-1322-testcase.patch
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 ^^
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira