This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 855871 - Imprecise number results in Pet Store example
Imprecise number results in Pet Store example
Status: NEW
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: Examples (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Tihomir Surdilovic
Lukáš Petrovický
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-10 09:20 EDT by jgargula
Modified: 2013-01-10 20:36 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jgargula 2012-09-10 09:20:27 EDT
Description of problem:
Pet store example application should present the use of Drools in business world and every ordinary calculator is able to calculate 90 or 95 percent of some number exactly. Hence, it is not a good advertisement if Drools are presenting results in form of 18.900000000000002 or 11.399999999999999 in case that these numbers should be exact 18.9 and 11.4.

Version-Release number of selected component (if applicable):
BRMS 5.3.0.GA

How reproducible:
Follow next steps.

Steps to Reproduce:
1. Run examples by runExamples.sh script and then start PetStoreExample.
2. Click 2x on "Gold Fish" and 1x on "Fish Food" and press "Checkout" and "Yes"
3. You will get discounted total 11.399999999999999
4. Press "Reset" button
5. Press 3x on "Gold Fish" and 3x on "Fish Food" and press "Checkout" and "Yes"
6. You will get discounted total 18.900000000000002
  
Actual results:
Imprecise results (11.399999999999999 and 18.900000000000002)

Expected results:
Mathematically exact results (11.4 and 18.9)

Additional info:
I suppose that this is a problem of type double and rather BigDecimal should be used .

Note You need to log in before you can comment on or make changes to this bug.