> Java rounding help please!?

Java rounding help please!?

Posted at: 2014-12-18 
That's a property of binary floating point.

The problem is that most terminating decimal fractions are NOT terminating fractions in base 2. There is not exact representation of 6.05 or 6.10, for example. The only numbers with exactly two decimal places in that 6-7 range that have exact binary representations are 6.00, 6.25, 6.50, 6.75 and 7.00.

The fix is to use System.out.printf() or String.format() to round to a specific number of decimal places or significant digits.

System.out.println("The rounded result is " + String.format("%.2f", b));

System.out.printf("The rounded result is %.2f\n", b);

You have to add the \n to end the line with printf(), since it doesn't come in two forms line .print() and .println() do.

Warning: %f formatting will round to the nearest in the last displayed digit, so you can't tell from its output whether you have correctly rounded the number or not. You can verify that it's at least very close by printing several more decimal places and see that the rounded result is 6.10000000, out to as many trailing 0's as you want.

On most fractions, there will eventually be nonzero digits out there, so don't go beyond about 14 significant digits (whole and fraction parts combined.)

Edit: By the way, banking and other "money" applications have had a tradition of using an integer number of pennies (in the US) precisely to avoid rounding and representation problems like this.

Floating point doesn't follow mathematical rules. The constants are imprecise and the calculations using them are ALSO imprecise. For example, the value of your constant 0.1 cannot be and is not exactly 0.1. It is very close, but not exact. It is stored as "3FB999999999999A". I think you can almost "see" the repeated 9's there, with the tail end rounded up to A (hex for 10.) (These are hexadecimal codes.)

Worse, math rules like "a*b+a*c" being the same as "a*(b+c)" also don't work on computers using floating point notation. They will be close, usually. But not exactly the same. These rules don't apply anymore. (They do with integers, just not with floating point.)

So the problem is with your thinking. Computers don't work the way you think they do. They work in binary and base 2 often requires infinite binary digits for decimal constants having finite decimal digits. And computations with these imprecise constants are themselves also imprecise, as mentioned. So of course you get values that are "slightly off."

Anything you will ever do on a computer needs to cope with these facts. There are methods under the general area of "numerical methods analysis" that will help cope. But the bottom line is that you need to change how you think about things before you code.

This applies to most languages you will encounter, unless the language specifically addresses this problem in some very explicit fashion. Safer to assume the problem exists, unless you find clear evidence to the contrary.

Doubles/Floats are not exactly real numbers. There are finite number of bits to represents a number.

You get the same results with:

System.out.println((double)(61*0.1));

Here is an example on how to round numbers to nth decimal place:

http://javacodex.com/Math-Examples/Round...

so im trying to round numbers to the nearest decimal and it works for a lot of numbers but its weird when i use 6.05000001

public class Main

{

public static void main (String [] args) {

double a = 6.05000001;

double b;



a = a*10;

int c = (int)Math.round(a);

b = c*0.1;



System.out.println("The rounded result is " + b);

}

}

when i run this i get 6.1000000000000005