So I have a double set to equal 1234, I want to move a decimal place over to make it 12.34
So to do this I multiply .1 to 1234 two times, kinda like this
double x = 1234;
for(int i=1;i<=2;i++)
{
x = x*.1;
}
System.out.println(x);
This will print the result, "12.340000000000002"
Is there a way, without simply formatting it to two decimal places, to have the double store 12.34 correctly?
In financial software it is common to use integers for pennies. In school, we were taught how to use fixed-point instead of floating, but that is usually powers of two. Storing pennies in integers might be called "fixed point" as well.
In class, we were asked in general what numbers can be exactly represented in a base.
For
base=p1^n1*p2^n2
... you can represent any N where N=n*p1^m1*p2^m2.Let
base=14=2^1*7^1
... you can represent 1/7 1/14 1/28 1/49 but not 1/3I know about financial software -- I converted Ticketmaster's financial reports from VAX asm to PASCAL. They had their own formatln() with codes for pennies. The reason for the conversion was 32 bit integers were no longer enough. +/- 2 billion pennies is $20 million and that overflowed for the World Cup or Olympics, I forgot.
I was sworn to secrecy. Oh well. In academea, if it's good you publish; in industry, you keep it secret.
Yes, there is. With each double operation you may lose accuracy but the amount of accuracy differs for each operation and can be minimized by choosing the right sequence of operations. For example when multiplying set of numbers, it is best to sort set by exponent before multiplying.
Any decent book on number crunching describes this. For example: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
And to answer your question:
Use divide instead of multiply, this way you get correct result.
Funny that numerous posts mention to use BigDecimal but no-one bothers to give the correct answer based on BigDecimal? Because even with BigDecimal, you can still go wrong, as demonstrated by this code
Gives this output
The BigDecimal constructor specifically mentions that it is better to use String constructor than a numeric constructor. Ultimate precision is also influenced by the optional MathContext.
According to the BigDecimal Javadoc it is possible to create a BigDecimal which is exactly equal to 0.1, provided you use the String constructor.
No, as Java floating point types (indeed all floating point types) are a trade-off between size and precision. While they're very useful for a lot of tasks, if you need arbitrary precision, you should use
BigDecimal
.you can try integer number representation
If you use
double
orfloat
, you should use rounding or expect to see some rounding errors. If you can't do this, useBigDecimal
.The problem you have is that 0.1 is not an exact representation, and by performing the calculation twice, you are compounding that error.
However, 100 can be represented accurately, so try:
which prints:
This works because
Double.toString(d)
performs a small amount of rounding on your behalf, but it is not much. If you are wondering what it might look like without rounding:prints:
In short, rounding is unavoidable for sensible answers in floating point whether you are doing this explicitly or not.
Note:
x / 100
andx * 0.01
are not exactly the same when it comes to rounding error. This is because the round error for the first expression depends on the values of x, whereas the0.01
in the second has a fixed round error.prints