[JBoss JIRA] Created: (JBRULES-1322) Accumulate functions are highly unreliable for long's and BigDecimals
9:26 a.m.
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: 4.1.0
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
9:28 a.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Accumulate functions are highly unreliable for long's and BigDecimals
[ http://jira.jboss.com/jira/browse/JBRULES-1322?page=all ]
Geoffrey De Smet updated JBRULES-1322:
--------------------------------------
Attachment: JBRULES-1322-testcase.patch
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: 4.1.0
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
2:17 a.m.
New subject: [JBoss JIRA] Commented: (JBRULES-1322) Accumulate functions are highly unreliable for long's and BigDecimals
[ 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
2:21 a.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[ http://jira.jboss.com/jira/browse/JBRULES-1322?page=all ]
Geoffrey De Smet updated JBRULES-1322:
--------------------------------------
Summary: Build in accumulate functions are highly unreliable for long's and
BigDecimals (was: Accumulate functions are highly unreliable for long's and
BigDecimals)
Build in 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
2:28 a.m.
New subject: [JBoss JIRA] Commented: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[ http://jira.jboss.com/jira/browse/JBRULES-1322?page=comments#action_12405015 ]
Geoffrey De Smet commented on JBRULES-1322:
-------------------------------------------
By the way, there is of course a workaround: just write your own sumBigDecimal function
Build in 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
11:25 a.m.
New subject: [JBoss JIRA] Commented: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[ http://jira.jboss.com/jira/browse/JBRULES-1322?page=comments#action_12413726 ]
Geoffrey De Smet commented on JBRULES-1322:
-------------------------------------------
Actually, 45.1 and 40.0 are bad examples, because they get rounded by to the correct
double
Try this line of code:
System.out.println("0.05 + 0.01 = " + (0.05 + 0.01));
it gives
0.05 + 0.01 = 0.060000000000000005
Or try these numbers:
0.05 + 0.01 = 0.060000000000000005 not 0.06
0.06 + 0.01 = 0.06999999999999999 not 0.07
0.07 + 0.02 = 0.09000000000000001 not 0.09
0.07 + 0.04 = 0.11000000000000001 not 0.11
0.07 + 0.05 = 0.12000000000000001 not 0.12
0.08 + 0.07 = 0.15000000000000002 not 0.15
0.09 + 0.01 = 0.09999999999999999 not 0.1
0.09 + 0.08 = 0.16999999999999998 not 0.17
0.1 + 0.02 = 0.12000000000000001 not 0.12
0.1 + 0.05 = 0.15000000000000002 not 0.15
0.11 + 0.06 = 0.16999999999999998 not 0.17
0.11 + 0.1 = 0.21000000000000002 not 0.21
0.12 + 0.02 = 0.13999999999999999 not 0.14
0.12 + 0.05 = 0.16999999999999998 not 0.17
0.12 + 0.11 = 0.22999999999999998 not 0.23
0.13 + 0.08 = 0.21000000000000002 not 0.21
0.14 + 0.01 = 0.15000000000000002 not 0.15
0.14 + 0.04 = 0.18000000000000002 not 0.18
0.14 + 0.07 = 0.21000000000000002 not 0.21
0.14 + 0.08 = 0.22000000000000003 not 0.22
0.14 + 0.1 = 0.24000000000000002 not 0.24
0.15 + 0.02 = 0.16999999999999998 not 0.17
0.15 + 0.08 = 0.22999999999999998 not 0.23
0.15 + 0.14 = 0.29000000000000004 not 0.29
0.16 + 0.05 = 0.21000000000000002 not 0.21
0.16 + 0.13 = 0.29000000000000004 not 0.29
0.16 + 0.14 = 0.30000000000000004 not 0.3
0.17 + 0.01 = 0.18000000000000002 not 0.18
0.17 + 0.04 = 0.21000000000000002 not 0.21
0.17 + 0.05 = 0.22000000000000003 not 0.22
0.17 + 0.07 = 0.24000000000000002 not 0.24
0.17 + 0.12 = 0.29000000000000004 not 0.29
0.17 + 0.13 = 0.30000000000000004 not 0.3
0.17 + 0.14 = 0.31000000000000005 not 0.31
0.18 + 0.02 = 0.19999999999999998 not 0.2
0.18 + 0.05 = 0.22999999999999998 not 0.23
0.18 + 0.15 = 0.32999999999999996 not 0.33
0.18 + 0.16 = 0.33999999999999997 not 0.34
0.19 + 0.1 = 0.29000000000000004 not 0.29
0.19 + 0.15 = 0.33999999999999997 not 0.34
0.2 + 0.01 = 0.21000000000000002 not 0.21
0.2 + 0.04 = 0.24000000000000002 not 0.24
0.2 + 0.09 = 0.29000000000000004 not 0.29
0.2 + 0.1 = 0.30000000000000004 not 0.3
0.21 + 0.02 = 0.22999999999999998 not 0.23
0.21 + 0.12 = 0.32999999999999996 not 0.33
0.21 + 0.13 = 0.33999999999999997 not 0.34
0.21 + 0.2 = 0.41000000000000003 not 0.41
0.22 + 0.07 = 0.29000000000000004 not 0.29
0.22 + 0.12 = 0.33999999999999997 not 0.34
0.22 + 0.19 = 0.41000000000000003 not 0.41
0.22 + 0.2 = 0.42000000000000004 not 0.42
0.23 + 0.01 = 0.24000000000000002 not 0.24
0.23 + 0.06 = 0.29000000000000004 not 0.29
0.23 + 0.07 = 0.30000000000000004 not 0.3
0.23 + 0.18 = 0.41000000000000003 not 0.41
0.23 + 0.19 = 0.42000000000000004 not 0.42
0.23 + 0.2 = 0.43000000000000005 not 0.43
0.24 + 0.04 = 0.27999999999999997 not 0.28
0.24 + 0.09 = 0.32999999999999996 not 0.33
0.24 + 0.1 = 0.33999999999999997 not 0.34
0.24 + 0.17 = 0.41000000000000003 not 0.41
0.24 + 0.21 = 0.44999999999999996 not 0.45
0.24 + 0.22 = 0.45999999999999996 not 0.46
0.26 + 0.03 = 0.29000000000000004 not 0.29
0.26 + 0.15 = 0.41000000000000003 not 0.41
0.26 + 0.16 = 0.42000000000000004 not 0.42
0.26 + 0.17 = 0.43000000000000005 not 0.43
0.27 + 0.02 = 0.29000000000000004 not 0.29
0.27 + 0.03 = 0.30000000000000004 not 0.3
0.27 + 0.08 = 0.35000000000000003 not 0.35
0.27 + 0.14 = 0.41000000000000003 not 0.41
0.27 + 0.15 = 0.42000000000000004 not 0.42
0.27 + 0.16 = 0.43000000000000005 not 0.43
0.27 + 0.17 = 0.44000000000000006 not 0.44
0.27 + 0.2 = 0.47000000000000003 not 0.47
0.28 + 0.01 = 0.29000000000000004 not 0.29
0.28 + 0.02 = 0.30000000000000004 not 0.3
0.28 + 0.03 = 0.31000000000000005 not 0.31
0.28 + 0.07 = 0.35000000000000003 not 0.35
0.28 + 0.08 = 0.36000000000000004 not 0.36
0.28 + 0.13 = 0.41000000000000003 not 0.41
0.28 + 0.14 = 0.42000000000000004 not 0.42
0.28 + 0.15 = 0.43000000000000005 not 0.43
0.28 + 0.16 = 0.44000000000000006 not 0.44
0.28 + 0.17 = 0.45000000000000007 not 0.45
0.28 + 0.19 = 0.47000000000000003 not 0.47
0.28 + 0.2 = 0.48000000000000004 not 0.48
0.29 + 0.03 = 0.31999999999999995 not 0.32
0.29 + 0.04 = 0.32999999999999996 not 0.33
0.29 + 0.05 = 0.33999999999999997 not 0.34
0.29 + 0.11 = 0.39999999999999997 not 0.4
0.29 + 0.15 = 0.43999999999999995 not 0.44
0.29 + 0.16 = 0.44999999999999996 not 0.45
0.29 + 0.17 = 0.45999999999999996 not 0.46
0.29 + 0.28 = 0.5700000000000001 not 0.57
0.3 + 0.03 = 0.32999999999999996 not 0.33
0.3 + 0.04 = 0.33999999999999997 not 0.34
0.3 + 0.15 = 0.44999999999999996 not 0.45
0.3 + 0.16 = 0.45999999999999996 not 0.46
Build in 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
7:20 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Mark Proctor updated JBRULES-1322:
----------------------------------
Fix Version/s: 5.0.0.M2
(was: 5.0.0.M1)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/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
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.0.0.M2
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:01 p.m.
New subject: [JBoss JIRA] Commented: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Geoffrey De Smet commented on JBRULES-1322:
-------------------------------------------
Any progress on this issue?
If I understand it, Mvel now supports the plumbing to do this, doesn't it?
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/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
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.0.0.M2
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:42 a.m.
New subject: [JBoss JIRA] Assigned: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Geoffrey De Smet reassigned JBRULES-1322:
-----------------------------------------
Assignee: Geoffrey De Smet (was: Edson Tirelli)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/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
Assignee: Geoffrey De Smet
Priority: Critical
Fix For: 5.0.0.M2
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:44 a.m.
New subject: [JBoss JIRA] Assigned: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Geoffrey De Smet reassigned JBRULES-1322:
-----------------------------------------
Assignee: Edson Tirelli (was: Geoffrey De Smet)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/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
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.0.0.M2
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:34 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Mark Proctor updated JBRULES-1322:
----------------------------------
Fix Version/s: 5.0.0.M3
(was: 5.0.0.M2)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/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
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.0.0.M3
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:51 a.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Edson Tirelli updated JBRULES-1322:
-----------------------------------
Fix Version/s: 5.0.0.CR1
(was: 5.0.0.M3)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/jira/browse/JBRULES-1322
Project: JBoss Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.0.0.CR1
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:32 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Mark Proctor updated JBRULES-1322:
----------------------------------
Fix Version/s: 5.0.0.CR1
(was: 5.0.0.M5)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/jira/browse/JBRULES-1322
Project: JBoss Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.0.0.CR1
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:28 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Mark Proctor updated JBRULES-1322:
----------------------------------
Fix Version/s: 5.0.0.GA
(was: 5.0.0.CR1)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/jira/browse/JBRULES-1322
Project: JBoss Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.0.0.GA
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:07 a.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Edson Tirelli updated JBRULES-1322:
-----------------------------------
Fix Version/s: 5.1.0.M1
(was: 5.0.1.FINAL)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/jira/browse/JBRULES-1322
Project: JBoss Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.1.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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:27 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/jira/browse/JBRULES-1322?page=com.atlassian.jira.p...
]
Edson Tirelli updated JBRULES-1322:
-----------------------------------
Fix Version/s: 5.1.0.M2
(was: 5.1.0.M1)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/jira/browse/JBRULES-1322
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.1.0.M2
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:32 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/browse/JBRULES-1322?page=com.atlassian.jira.plugin...
]
Edson Tirelli updated JBRULES-1322:
-----------------------------------
Fix Version/s: 5.1.0.CR1
(was: 5.1.0.M2)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/browse/JBRULES-1322
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.1.0.CR1
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:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:40 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://jira.jboss.org/browse/JBRULES-1322?page=com.atlassian.jira.plugin...
]
Mark Proctor updated JBRULES-1322:
----------------------------------
Fix Version/s: 5.2.0.M1
(was: 5.1.0.CR1)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://jira.jboss.org/browse/JBRULES-1322
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.2.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:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:42 a.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://issues.jboss.org/browse/JBRULES-1322?page=com.atlassian.jira.plug...
]
Mark Proctor updated JBRULES-1322:
----------------------------------
Fix Version/s: 5.2.0.CR1
(was: 5.2.0.M1)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://issues.jboss.org/browse/JBRULES-1322
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.2.0.CR1
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:50 a.m.
New subject: [JBoss JIRA] Commented: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://issues.jboss.org/browse/JBRULES-1322?page=com.atlassian.jira.plug...
]
Geoffrey De Smet commented on JBRULES-1322:
-------------------------------------------
IMO, The only decent way to fix this is by fixing JBRULES-1075.
But it's important, it means that accumulate of financial data (such as insurances or
mortgages) is plain wrong.
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://issues.jboss.org/browse/JBRULES-1322
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.2.0.CR1
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:44 a.m.
New subject: [JBoss JIRA] Commented: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://issues.jboss.org/browse/JBRULES-1322?page=com.atlassian.jira.plug...
]
Edson Tirelli commented on JBRULES-1322:
----------------------------------------
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
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://issues.jboss.org/browse/JBRULES-1322
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.2.0.CR1
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:40 p.m.
New subject: [JBoss JIRA] Updated: (JBRULES-1322) Build in accumulate functions are highly unreliable for long's and BigDecimals
[
https://issues.jboss.org/browse/JBRULES-1322?page=com.atlassian.jira.plug...
]
Edson Tirelli updated JBRULES-1322:
-----------------------------------
Fix Version/s: FUTURE
(was: 5.2.0.CR1)
Build in accumulate functions are highly unreliable for long's
and BigDecimals
------------------------------------------------------------------------------
Key: JBRULES-1322
URL: https://issues.jboss.org/browse/JBRULES-1322
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-compiler
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: FUTURE
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4977
days inactive
6262
days old
21 comments
3 participants
participants (3)
-
Edson Tirelli (JIRA) -
Geoffrey De Smet (JIRA)
-
Mark Proctor (JIRA)