Mary Joe
Greenhorn
Posts: 20

Printing out as
d1 + d2 : 2098700.0300000003
while I expect 2098700.03, can anyone explain the reason?

Matthew Brown
Bartender
Posts: 4567
8
Floating point variables aren't very good at storing exact values. Remember that the number is stored internally in binary, and 2095475.03 won't be represented exactly in binary.

So you've got two options.

- If you need the calculations to be exact, then look at using the BigDecimal class to represent numbers and do calculations.

- If you don't care about these tiny inaccuracies, but all you care about is getting sensible output, do the calculations as you are, and try the DecimalFormat class to produce output to the accuracy you want.

Wouter Oet
Saloon Keeper
Posts: 2700
That is how floating point calculations work. It basically is because not every number can be stored in a double so it will take the closed value. If you want it to have a certain format then you can use NumberFormat.

Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15356
39
• 2

Mary Joe
Greenhorn
Posts: 20
Thanks what I was trying to do was importing a file.

which will be compared against the total of the relevant filed(of Numeric(5,2)) which is a double in the body
which can be from upto a total of 50000 rows.
This total also represented as a double was returning as 2098700.0300000003 and hence it was throwing an error beacuse the values didn't match.
I will try using BigDecimal

Any example you have on addition on BigDecimal

Vinay Chaudhary
Greenhorn
Posts: 4
BigDecimal bd1= new BigDecimal("2095475.03");
BigDecimal bd2 = new BigDecimal("3225.0");
System.out.println("BIG DECI " + bd1);

This will print the result you want

Mary Joe
Greenhorn
Posts: 20
What I didn't understand though was the same logic was used to calculate the header total as well, which didn't present with the same issue.

total += row.getFee().doubleValue();

Winston Gutkowski
Bartender
Posts: 10422
63
Mary Joe wrote:Printing out as
d1 + d2 : 2098700.0300000003
while I expect 2098700.03, can anyone explain the reason?

Unfortunately, the original Goldberg page seems to have disappeared, but this one looks similar. If you really need fixed decimal values, you're usually better off using BigDecimal than double.

fred rosenberger
lowercase baba
Bartender
Posts: 12144
30
Comparing floating point numbers for equality is ALWAYS risky in any computer language. if you have to do so, you generally figure out some delta that the difference should be less than...i.e.:

And even this is dangerous if the magnitude of your numbers can vary.

Mary Joe
Greenhorn
Posts: 20
I have overcome the issue firt mentioned in my post using BigDecimal.

Now I have a different one.

Bigdecimal one = 2948.0
Bigdecimal one = 2948 (this is being returned from a jdbc query of Double value new BigDecimal(resultRow.getFee().toString());)
Again failing on comparison, anway to impose the decimal ?

Joshua Barrett
Greenhorn
Posts: 27
I do believe your BigDecimal object has its current scale set to Zero.

The scale defines the number of decimal places the object will hold.

Take a look at the various setScale() Methods in the API, you can also define the scale in several constructors.

Java BigDecimal

Also I would suggest when setting scale you also define the rounding mode. BigDecimal.ROUND_HALF_UP is the standard rounding we all should know from school.

Mary Joe
Greenhorn
Posts: 20
Thanks Joshua that helped a lot.

All issues resolved