How many decimal places in Double (Java)

Question

Is there a built-in function in java to tell me how many decimal places are in double. For example:

101.13 = 2 101.130 = 3 1.100 = 3 1.1 = 1 -3.2322 = 4 etc. 

I am happy to convert to another type, if necessary, first looked at converting to bigdecimal without any luck.

Answer 1

Not.

1.100 and 1.1 are exactly the same value (they are represented in exactly the same bit for bits in double ).

Therefore, you can never get such information from double .

The only thing you can do is get the minimum number of decimal digits needed for the decimal number to be parsed into the same double value. And it's as simple as calling Double.toString() and checking the number of decimal digits.

Answer 2

You can use BigDecimal.scale () if you pass the number as a string as follows:

 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 a string, you can simply parse the regular expression string to find out how many digits there are:

 String[] s = "1.31".split("\\."); System.out.println(s[s.length - 1].length()); 

Using BigDecimal can have the advantage of checking if the string is really a number; using the string method, you have to do it yourself. In addition, if you have double digits, you cannot distinguish between 1.31 and 1.310 (they are exactly the same as the others), as others pointed out.

Answer 3

No, there is no built-in function that I know of.

There is an easy way to do this. Double.toString will give you a string containing ALL significant decimal digits in double. Some properties of this line are listed below:

• A string that can be represented in decimal notation or scientific notation, depending on the value of double.
• Doubles that convert to decimal numbers 10,000,000 or more or less than 1/1000 lead to scientific notation. Otherwise, they are in decimal notation.

Using Double.toString to determine how many decimal places essentially consists of how many significant digits to the right of the decimal point minus the scientific notation indicator, if any. The decimal notation will always have at least one digit to the right of the decimal point and at least one digit to the left of the decimal point, even if it is zero. Since we are concerned about decimals for significant digits, the trailing zero to the right of the decimal point is a problem and should not be considered a decimal point.

The following code will do a good calculation for you:

  StringBuffer stringBuffer = new StringBuffer(Double.toString(1234.567890D)); System.out.println(stringBuffer.toString()); 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 System.out.println(decimalPlaces); 

I have some questions about this question. What accuracy is expected with a decimal representation of a double? Are doubles used to perform decimal calculations improperly? Decimal calculations with decimal fractions using floats and doubles can have results that unexpectedly have 16 or 17 significant digits and can only be approximations of the expected results from equivalent decimal calculations.

One aspect of the float, doubles, doubles (aka quads), which seems to be programmers and designers that all of these formats are actually stored as binary fractional numbers that can only approximate decimal numbers, except for a very, very small number, most of which are pretty are close to the values ​​1, -1, plus the value 0. As you move to positive infinity or zero from 1 or to negative infinity or zero from -1, the approximation sparseness becomes apparent.

Almost all decimal fractions do not have a direct representation in floats and doubles. Only decimal fractions, which may consist of the sum of some combination of the following series of fractions, have an accurate representation:

1, 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, 1/128, 1/256, ..., 1/4503599627370496

All others are approximations.

Integers greater than +9007199254740992 or less than -9007199254740992 may not have an accurate representation, and sparseness increases exponentially, since integers increase above positive or decrease below negative values, respectively.

Another way to look at this is to understand that 64-bit IEEE doubles, normalizes, approximates positive and negative decimal numbers, which have absolute values ​​ranging from 2.225073858507201400 E -308 to 1.797693134862315700 E +308. However, only 1,8446744073709551616 E +19 values ​​are available for these approximations. This means that decimal values ​​in the E + 607 format share the view with some other decimal values ​​that come closer to double.

The behavior of floats and doubles destroys chaos with decimal calculations requiring exact decimal precision, such as financial calculations, and therefore, if high-precision approximation is acceptable, scaled integers and long numbers or classes such as BigInteger and BigDecimal should be used for calculations requiring exact decimal precision, rounding and precision.

Answer 4

The number of decimal places in 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 64-bit floating point numbers of IEEE 754.

See http://en.wikipedia.org/wiki/IEEE_754-2008

Answer 5

 // **************************************************************** public int getDecimals(double doubleValue) { // **************************************************************** BigDecimal bd1 = new BigDecimal(Double.toString(doubleValue)).stripTrailingZeros(); return bd1.scale(); } 

Answer 6

From many years ago, I recall the answer of 16 digits, all before and after the decimal point.

I wrote tiny code to verify this.

 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. Launch outputs 3411.99999999999999.

Now add another 9 behind the decimal point for a total of 17 - 3411.9999999999999 - and try again. The value printed is 3412.0. In this case, we overload the internal representation of x, and the number is rounded inside for storage.

Println faithfully prints what it sees inside. There are only so many bits - 64, to be precise - to hold a double floating number (value and exponent - see IEEE 754 for gory details).

Play with the x value and you will see the effects. For example, 0.999999999999999999 (16 9 s) yield 0.999999999999999999; 0.99999999999999999 (17 9 s) gives 1.0.

Hope this helps.

Answer 7

 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; }