58

I have found this great solution for rounding:

static Double round(Double d, int precise) {
    BigDecimal bigDecimal = new BigDecimal(d);
    bigDecimal = bigDecimal.setScale(precise, RoundingMode.HALF_UP);
    return bigDecimal.doubleValue();
}

However, the results are confusing:

System.out.println(round(2.655d,2)); // -> 2.65
System.out.println(round(1.655d,2)); // -> 1.66

Why is it giving this output? I'm using jre 1.7.0_45.

pushistic
  • 3,406
  • 3
  • 21
  • 35
  • Can you print the value of `BigDecimal` in the `round` method? – Abimaran Kugathasan Feb 26 '14 at 09:26
  • 1
    Related: http://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency – Stig Hausberg Feb 26 '14 at 09:27
  • 14
    It's not wrong. That's how [floating point works](http://floating-point-gui.de/). `2.655d` is probably `2.654999...` – zapl Feb 26 '14 at 09:28
  • Yea, I wondered what neighbour meant in the java doc. The next internal bit representation or the next string? – mvw Feb 26 '14 at 09:30
  • 1
    You create a `BigDecimal` from a `double`... That's like trying to make gold from pyrite: it may look like it but that's not it (ie, don't do that, use gold to start with) – fge Feb 26 '14 at 09:36

6 Answers6

80

You have to replace

BigDecimal bigDecimal = new BigDecimal(d);

with

BigDecimal bigDecimal = BigDecimal.valueOf(d);

and you will get the expected results:

2.66
1.66

Explanation from Java API:

BigDecimal.valueOf(double val) - uses the double's canonical string representation provided by the Double.toString() method. This is preferred way to convert a double (or float) into a BigDecimal.

new BigDecimal(double val) - uses the exact decimal representation of the double's binary floating-point value and thus results of this constructor can be somewhat unpredictable.

Boris
  • 22,667
  • 16
  • 50
  • 71
  • 2
    +1, I didn't know that. But you should explain [why](http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#BigDecimal%28double%29) that makes a difference. – zapl Feb 26 '14 at 09:43
  • 2
    @zapl:- I tried to explain that in my answer! Do let me know if i missed anything – Rahul Tripathi Feb 26 '14 at 09:43
  • user3301492, You can edit your answer, it looks better if you put it there instead of a comment :) - @RahulTripathi +1 as well, nothing missing, maybe more explanation of string conversion and that the string constructor is then creating a precise representation by not using a normal double as internal representation. – zapl Feb 26 '14 at 10:16
  • 1
    Let me add that is always better to use `valuesOf` than `new` when dealing with numbers. The reason is that, having `BigDecimal first = new BigDecimal(x)` and `BigDecimal second = new BigDecimal(x)`, `first == second` may output `false`, while using `valueOf` instead of `new` leads to a more consistent behaviour with primitive type (if `first = BigDecimal.valueOf(x)` and `second = BigDecimal.valueOf(x)`, then `first == second` will always be `true`). NOTE: I am not so sure this is valid for `BigDecimal`s, but it lasts for the others `Number`s – ThanksForAllTheFish Feb 26 '14 at 12:12
  • @mardavi actually it is not guaranteed that `valueOf(x) == valueOf(x)` for _any_ of the standard library `Number` types. Current OpenJDK implementations of `Integer` and `Long` cache some commonly-used values (but not all values, as that would cost more in memory than it's worth), but `Float` and `Double` `valueOf` methods just call the constructor. Still I agree that it is best to use `valueOf` in general. – MikeFHay Feb 26 '14 at 13:06
  • @MikeFHay, thank you! `Integer` caches to 128 (I think) and that's why `==` works as expected with `new Integer` for integers smaller than 128 (I don't know for negative numbers). However, I didn't know the behavior of `valueOf` is not consistent with `Float` and `Double` – ThanksForAllTheFish Feb 26 '14 at 13:14
26

You may try to change your program like this:-

static Double round(Double d, int precise) 
{
BigDecimal bigDecimal = BigDecimal.valueOf(d);
bigDecimal = bigDecimal.setScale(precise, RoundingMode.HALF_UP);
return bigDecimal.doubleValue();
}

Sample Ideone

Success  time: 0.07 memory: 381184 signal:0
Rounded: 2.66
Rounded: 1.66

Success  time: 0.07 memory: 381248 signal:0
Rounded: 2.66
Rounded: 1.66

Reason why you are getting the expected result with BigDecimal.valueOf and not with new BigDecimal, in the words of Joachim Sauer:

BigDecimal.valueOf(double) will use the canonical String representation of the double value passed in to instantiate the BigDecimal object. In other words: The value of the BigDecimal object will be what you see when you do System.out.println(d).

If you use new BigDecimal(d) however, then the BigDecimal will try to represent the double value as accurately as possible. This will usually result in a lot more digits being stored than you want.

Hence resulting in some confusion which you are watching in your program.

From the Java Doc:

BigDecimal.valueOf(double val) - Translates a double into a BigDecimal, using the double's canonical string representation provided by the Double.toString(double) method.

new BigDecimal(double val) -

Translates a double into a BigDecimal which is the exact decimal representation of the double's binary floating-point value. The scale of the returned BigDecimal is the smallest value such that (10scale × val) is an integer. Notes:

  • The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a
    BigDecimal which is exactly equal to 0.1 (an unscaled value of 1,
    with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that
    matter, as a binary fraction of any finite length). Thus, the value
    that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding.
  • The String constructor, on the other hand, is perfectly predictable: writing new BigDecimal("0.1") creates a BigDecimal which is exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the String constructor be used in preference to this one.
  • When a double must be used as a source for a BigDecimal, note that this constructor provides an exact conversion; it does not give the
    same result as converting the double to a String using the
    Double.toString(double) method and then using the BigDecimal(String)
    constructor. To get that result, use the static valueOf(double)
    method.
Community
  • 1
  • 1
Rahul Tripathi
  • 168,305
  • 31
  • 280
  • 331
18

This test case ends up pretty self-explanatory:

public static void main (String[] args) throws java.lang.Exception
{
    System.out.println("Rounded: " + round(2.655d,2)); // -> 2.65
    System.out.println("Rounded: " + round(1.655d,2)); // -> 1.66
}

public static Double round(Double d, int precise)
{       
    BigDecimal bigDecimal = new BigDecimal(d);
    System.out.println("Before round: " + bigDecimal.toPlainString());
    bigDecimal = bigDecimal.setScale(precise, RoundingMode.HALF_UP);
    System.out.println("After round: " + bigDecimal.toPlainString());
    return bigDecimal.doubleValue();
}

Output:

Before round: 2.654999999999999804600747665972448885440826416015625
After round: 2.65
Rounded: 2.65

Before round: 1.6550000000000000266453525910037569701671600341796875
After round: 1.66
Rounded: 1.66

A dirty hack to fix it would be to round in two steps:

static Double round(Double d, int precise)
{
    BigDecimal bigDecimal = new BigDecimal(d);
    System.out.println("Before round: " + bigDecimal.toPlainString());
    bigDecimal = bigDecimal.setScale(15, RoundingMode.HALF_UP);
    System.out.println("Hack round: " + bigDecimal.toPlainString());
    bigDecimal = bigDecimal.setScale(precise, RoundingMode.HALF_UP);
    System.out.println("After round: " + bigDecimal.toPlainString());
    return bigDecimal.doubleValue();
}

Here, 15 is a bit under the maximum number of digits a double can represent in base 10. Output:

Before round: 2.654999999999999804600747665972448885440826416015625
Hack round: 2.655000000000000
After round: 2.66
Rounded: 2.66

Before round: 1.6550000000000000266453525910037569701671600341796875
Hack round: 1.655000000000000
After round: 1.66
Rounded: 1.66
Martijn Courteaux
  • 67,591
  • 47
  • 198
  • 287
  • 2
    It seems like a hack, but it's very similar to the process that `valueOf` is using, just more explicit. The conversion to a string does the first rounding. – Mark Ransom Feb 26 '14 at 22:53
8

As said in API

  1. The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding.

  2. The String constructor, on the other hand, is perfectly predictable: writing new BigDecimal("0.1") creates a BigDecimal which is exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the String constructor be used in preference to this one.

  3. When a double must be used as a source for a BigDecimal, note that this constructor provides an exact conversion; it does not give the same result as converting the double to a String using the Double.toString(double) method and then using the BigDecimal(String) constructor. To get that result, use the static valueOf(double) method.

It's because of cannot represent double value exactly. So you have to use BigDecimal bigDecimal = BigDecimal.valueOf(d); instead of BigDecimal bigDecimal = new BigDecimal(d);

Abimaran Kugathasan
  • 31,165
  • 11
  • 75
  • 105
7

Rounding a double resp Double in itself does not make much sense, as a double datatype cannot be rounded (easily, or at all?).

What you are doing is:

  1. Take a Double d as input and a int precise number of digits behind the seperator.
  2. Create a BigDecimal from that d.
  3. Round the BigDecimal correctly.
  4. Return the double value of that BigDecimal, which has no rounding applied to it anymore.

You can go two ways:

  1. You can return a BigDecimal that represents the rounded double, and later decide what you do with it.
  2. You can return a String representing the rounded BigDecimal.

Either of those ways will make sense.

skiwi
  • 66,971
  • 31
  • 131
  • 216
  • +1 as this is the most correct answer. One nitpick though: you certainly can round doubles, in fact they are implicitly rounded - but to binary, digits, not decimal ones. – Michael Borgwardt Feb 27 '14 at 13:10
6

Decimal numbers can't be represented exactly in double.

So 2.655 ends up being this: 2.65499999999999980460074766597

whereas 1.655 ends up being this: 1.655000000000000026645352591

Lev
  • 434
  • 2
  • 9
  • Why the first is `499999..` and the second is `500000..`? – Maroun Feb 26 '14 at 09:31
  • 5
    This is not accurate; *some/many* decimal numbers can't be represented. – Oliver Charlesworth Feb 26 '14 at 09:31
  • Well yes, to be exact. Since double is a binary format, all decimal numbers which have an exact binary representation (which fits into double) can be represented, all others can't. Maroun, take a look at this: http://www.binaryconvert.com/convert_double.html – Lev Feb 26 '14 at 09:33