BigDecimal - to use new or valueOf

Question

I came across two ways of getting BigDecimal object out of a double d.

1. new BigDecimal(d)
2. BigDecimal.valueOf(d)

Which would be a better approach? Would valueOf create a new object?

In general (not just BigDecimal), what is recommended - new or valueOf?

Answer 1

Those are two separate questions: "What should I use for BigDecimal?" and "What do I do in general?"

For BigDecimal: this is a bit tricky, because they don't do the same thing. 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. Strictly speaking, it's more correct than valueOf(), but it's a lot less intuitive.

There's a nice explanation of this in the JavaDoc:

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.

In general, if the result is the same (i.e. not in the case of BigDecimal, but in most other cases), then valueOf() should be preferred: it can do caching of common values (as seen on Integer.valueOf()) and it can even change the caching behaviour without the caller having to be changed. new will always instantiate a new value, even if not necessary (best example: new Boolean(true) vs. Boolean.valueOf(true)).

Answer 2

If you are using your BigDecimal objects to store currency values, then I strongly recommend that you do NOT involve any double values anywhere in their calculations.

As stated in another answer, there are known accuracy issues with double values and these will come back to haunt you big time.

Once you get past that, the answer to your question is simple. Always use the constructor method with the String value as the argument to the constructor, as there is no valueOf method for String.

If you want proof, try the following:

BigDecimal bd1 = new BigDecimal(0.01);
BigDecimal bd2 = new BigDecimal("0.01");
System.out.println("bd1 = " + bd1);
System.out.println("bd2 = " + bd2);

You'll get the following output:

bd1 = 0.01000000000000000020816681711721685132943093776702880859375
bd2 = 0.01

See also this related question

Answer 3

Basically valueOf(double val) just does this:

return new BigDecimal(Double.toString(val));

Therefore -> yep, a new object will be created :).

In general I think it depends upon your coding style. I would not mixure valueOf and "new", if both are the same outcome.

Answer 4

Foreword

Why are we having these discussions about floating-point type, numbers & arithmetic? Simple. We count in base 10, but the machine count in base 2.

BigDecimal - Need for an exact representation (not approximation)

If you are using BigDecimal, this means that you want an exact representation of 0.1 and other negative powers of ten (usually you would be dealing with money or arithmetic involving decimals).

Double means trouble (where BigDecimal is concerned)

Then, if you are finding yourself having to manipulate double(or float) values using BigDecimal, then you are in double trouble, because it is impossible to represent 0.1 as a double in base 2. The machine "stores" doubles(IEEE-754 standard for floating-point arithmetic) as base 2. Here is a good write-up of what's really happening if you are interested.). Duncan's answer illustrates what i am trying to say, of what to do and not do.

Any programming language that you think can store 0.1 accurately is actually not. It is just an approximation.

System.out.println(0.1d);
//Prints 0.1 or so you think ;-)

//If you are not convinced, try this:
double x = 1.1; double y = 1.0;
if (x-y == 0.1) {// print true } else {// print false}

//or perhaps this:
double amount1 = 2.15;
double amount2 = 1.10;
System.out.println("Difference: " + (amount1 - amount2));

Examples

  double smallD = 0.0001;
  double smallDNoScientificNotation = 0.001; //>= 10E-3
  double normalD = 10.345678;
  double bigDNoScientificNotation = 1234567.123456789; //<=10E7 
  double bigD = 56_789_123_456_789.123456789;

  //double
  System.out.println(smallD); //1.0E-4, computerized scientific notation, this is how Double toString works
  System.out.println(smallDNoScientificNotation); //0.001, OK
  System.out.println(normalD); //10.345678, OK
  System.out.println(bigDNoScientificNotation); //1234567.123456789, OK
  System.out.println(bigD); //5.6789123456789125E13, computerized scientific notation, this is how Double toString works
  
  //new BigDecimal(double): not OK, don't use! Attempting to representing the base-2 representation as accurately as possible
  System.out.println(new BigDecimal(smallD)); //0.000100000000000000004792173602385929598312941379845142364501953125
  System.out.println(new BigDecimal(smallDNoScientificNotation)); //0.001000000000000000020816681711721685132943093776702880859375
  System.out.println(new BigDecimal(normalD)); //10.34567799999999948568074614740908145904541015625
  System.out.println(new BigDecimal(bigDNoScientificNotation)); //1234567.12345678894780576229095458984375
  System.out.println(new BigDecimal(bigD)); //56789123456789.125
  
  //BigDecimal.valueOf (Dont use if the range is >= 10E-3, >= 10E7), under the hood it's using Double.toString
  System.out.println(BigDecimal.valueOf(smallD)); //0.00010 - notice the extra 0, stemming from 1.0E-4
  System.out.println(BigDecimal.valueOf(smallDNoScientificNotation)); //0.001
  System.out.println(BigDecimal.valueOf(normalD)); //10.345678
  System.out.println(BigDecimal.valueOf(bigDNoScientificNotation)); //1234567.123456789
  System.out.println(BigDecimal.valueOf(bigD)); //56789123456789.125 //loss of accuracy 

Computerized scientific notation - more here.

BONUS 1 - Pitfalls

Here

BONUS 2 - Effective Java 3rd edition (Joshua Bloch)

Item 60: Avoid float or double if exact answers are required

The float and double types are particularly ill-suited for monetary calculations because it is impossible to represent 0.1 (or any other negative power of ten) as a float or double exactly.
:
There are, however, two disadvantages to using BigDecimal: it's a lot less convenient than using a primitive arithmetic type, and it's a lot slower. The latter disadvantage is irrelevant if you're solving a single short problem, but the former may annoy you.
:
An alternative to using BigDecimal is to use int or long, depending on the amounts involved, and to keep track of the decimal point yourself. In this example, the obvious approach is to do all computation in cents.

Extra reading for the mathematically inclined ;-)

What Every Computer Scientist Should Know About Floating-Point Arithmetic