Is there any in built function in java to tell me how many decimal places in a double. For example:
101.13 = 2
101.130 = 3
1.100 = 3
1.1 = 1
-3.2322 = 4 etc
// ****************************************************************
public int getDecimals(double doubleValue) {
// ****************************************************************
BigDecimal bd1 = new BigDecimal(Double.toString(doubleValue)).stripTrailingZeros();
return bd1.scale();
}
From many long years ago, I recall an answer of 16 digits, total of before and after the decimal point.
I wrote a tiny bit of code to test that.
public class test {
public static void main(String[] args) {
double x;`enter code here`
x = 3411.999999999999;
System.out.println("16: "+x); // gives 3411.999999999999
x = 3411.9999999999999;
System.out.println("17: "+x); // gives 3412.0
x = 0.9999999999999999;
System.out.println("16: "+x); // gives 0.9999999999999999
x = 0.99999999999999999;
System.out.println("17: "+x); // gives 1.0
}
}
There 4+12 = 16 digits. A run outputs 3411.999999999999.
Now add one more 9 behind the decimal point for a total of 17 - 3411.9999999999999 - and rerun. The value printed is 3412.0. In this case, we overload the internal representation of x, and the number is rounded internally to store.
The println faithfully prints what it sees internally. There are only so many bits - 64 to be exact - to hold the double floating number (significand and exponent - see IEEE 754 for the gory details).
Play around with the value of x and you'll see the effects. For instance, 0.9999999999999999 (16 9s)give output 0.9999999999999999; 0.99999999999999999 (17 9s) gives 1.0.
Hope this helps.
The number of decimal places in a double is 16.
64-bit numbers. 52-bit Mantissa. 52 bits is about 16 decimal digits.
See http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html.
double, whose values include the 64-bit IEEE 754 floating-point numbers.
See http://en.wikipedia.org/wiki/IEEE_754-2008
StringBuffer stringBuffer = new StringBuffer(Double.toString(ratioGrossYield));
int i; // general purpose character index
int exponent;
int decimalPlaces;
if ((i = stringBuffer.indexOf("E")) > -1) { // scientific notation...
// turn scientific notation exponent into an integer
exponent = Integer.parseInt(stringBuffer.substring(i + 1));
// truncate the exponent from the StringBuffer
stringBuffer = stringBuffer.delete(i, stringBuffer.length());
} else { // decimal notation, could be trailing zero
exponent = 0; // no exponent, so zero
// point i to trailing zero and truncate it, if there is one
if (stringBuffer.charAt((i = stringBuffer.length() - 1)) == '0') {
stringBuffer = stringBuffer.deleteCharAt(i); // delete trailing zero
}
}
// stringBuffer now contains only significant digits to the
// right of the decimal point, if there are any
decimalPlaces = stringBuffer.length() - 1 - stringBuffer.indexOf(".") - exponent;
// zero or positive number is decimal places
// negative number is number of zeroes to the left of the decimal point
// between the decimal point and the least significant digit
if (stringBuffer.charAt(stringBuffer.length() - 1) == '0') {
return decimalPlaces-1;
} else {
return decimalPlaces;
}
No.
1.100 and 1.1 are exactly the same value (they are represented exactly the same bit-for-bit in a double
).
Therefore you can't ever get that kind of information from a double
.
The only thing you can do is to get the minimum number of decimal digits necessary for a decimal number to be parsed into the same double
value. And that is as easy as calling Double.toString()
and checking how many decimal digits there are.
You could use BigDecimal.scale() if you pass the number as a String like this:
BigDecimal a = new BigDecimal("1.31");
System.out.println(a.scale()); //prints 2
BigDecimal b = new BigDecimal("1.310");
System.out.println(b.scale()); //prints 3
but if you already have the number as string you might as well just parse the string with a regex to see how many digits there are:
String[] s = "1.31".split("\\.");
System.out.println(s[s.length - 1].length());
Using BigDecimal might have the advantage that it checks if the string is actually a number; using the string method you have to do it yourself. Also, if you have the numbers as double you can't differentiate between 1.31
and 1.310
(they're exactly the same double) like others have pointed out as well.