Conversion of float to double

On the page you sent i found an applet and a table describing the conversions. From float to double is writed:
// to double d from float f
// no conversion necessary in Java 1.5+


double number 1.53 exists.

So, why conversion brings a result with many decimals?

One solution could be to use String as an intermediate type but is slow. Any other solution ?

>>So, why conversion brings a result with many decimals?

I've already explained that. See link above

>>Any other solution ?

Already given one

Explanation is:
1.53 is a double
you convert it to float
then back to double.

IMHO

double d = new BigDecimal("1.53").doubleValue();

As I understood, sey7 has the value 1.53 as float  (NOT AS STRING)

He want to get a double representing the same value 1.53

The only solution for that is :
      float val = 1.53f;
      double doubleVal = Double.parseDouble("" + val);
      System.out.println(doubleVal);

but as I said it's slow

     float f = 1.53f;
      java.math.BigDecimal bi = java.math.BigDecimal.valueOf(f);
      bi = bi.setScale(2, java.math.BigDecimal.ROUND_HALF_UP);
      double d = bi.doubleValue();
      System.out.println(d);

Wrong:
      float val = 1.534f;
      double doubleVal = Double.parseDouble("" + val);
      System.out.println("marius :" + doubleVal);


      java.math.BigDecimal bi = new java.math.BigDecimal(val);
      bi = bi.setScale(2, java.math.BigDecimal.ROUND_HALF_UP);
      double d = bi.doubleValue();
      System.out.println("CEH :" + d);

result:
marius :1.534
CEH :1.53

Not quite sure what your point is there mariuso ...

I mean your example with BigDecimal only works for 1.53 (for 2 decimals)

Solution with string also works for other numbers (e.g. 1.534)

>> I mean your example with BigDecimal only works for 1.53 (for 2 decimals)

? It'll work for any decimal:

float val = 1.534f;
...

bi = bi.setScale(3, java.math.BigDecimal.ROUND_HALF_UP);

Joking? I hope so.

These are only examples (1.53, 1.534)

String solution works for any number without any source code modification.

So:
1. how do i find out number of decimals
2. why do you ROUND_HALF_UP ? This is a particular case

Well the String solution is not really different from what i posted earlier:

>> double d = new BigDecimal("1.53").doubleValue();

except it'd be

 double d = new BigDecimal("" + f).doubleValue();

Yes. This works too.

Whatever you do, you are always looking at - and verifying with String representations
of data that can not be expressed exactly.
So, before making up conclusions, realise what deviations are introduced
by formats, field capabilities, expression conversions, and finally the way a number is converted
into what you want to look at.

My professor told me long ago: "you can't really do math with a computer:
                                               you are just jumping from bit pattern to bit pattern in a limited collection".

;JOOP!

None of the comments answered the question, which is about roundoff and why it happens, not on how to use BigDecimal when there is absolutely no reason to do so.

double precision takes 64 bits. It holds approximately 15 digits accuracy. It is encoded in binary, so numbers that are powers of 2 are exact:

.5
.25
.125

Numbers that are "not nice" fractions in decimal that we are used to have roundoff error in decimal. If you only remember 6 digits:

1/3 = .333333

which has an error, because there should be an infinite repeating string of 33333333....
In the same way, numbers that humans think of as nice, like 1/10 are repeating fractions in binary, which is how float and double are stored.

The original code given has a double precision constant:

double x = 1.53;

This is not actually exactly 1.53, as that number cannot be exactly represented in binary, but leave that for a moment. If you printed it, it would appear correct:

System.out.println(x);

Then, you cast to float, which I will split into a separate line:

float y = (float) x;

This truncates the answer to 32 bits, which only has 7-8 digits accuracy. Since the number is not exactly 1.53, now it is less accurate, having been chopped short. Then you copy it back as a double:

double x = y;

printing it out yields the wrong value.

There are a few lessons to be learned:

1. Don't use float unless you really know what you are doing.
2. Don't use float for financial calculations, there aren't enough digits precision: 123,456.78 (the 8 might be a 7 or a 9)
3. Don't cast intermediate results to float


Try this:

double x = 0;
for (int i = 0; i < 100; i++, x += 0.1) {
  System.out.println(x);
}

After 30 or 40 iterations, suddenly there is enough cumulative roundoff that you start seeing a lot of digits.
You can stop the display by rounding to the nearest value you believe. Since we're adding .01, we know there shouldn't be any digits smaller than that:

double x = 0;
for (int i = 0; i < 100; i++, x += 0.1) {
  System.out.println(Math.round(x*100)/100);
}


Lesson:

4. Even double precision value are slowly poisoned by roundoff. double is more suitable to scientific use than business.

Integers in double are exact, so if you want to represent dollars in a double, multiply by 100, compute integer numbers of pennies, and only divide by 100 when printing.

>>
None of the comments answered the question, which is about roundoff and why it happens, not on how to use BigDecimal when there is absolutely no reason to do so.
>>

Then you haven't read the comments and links properly. The only way to get full control over rounding/precision issues is to use BigDecimal