We Keep Coding

Is there a way to get right results from BigDecimal.floatValue() function? [duplicate]

I am working with an application that is based entirely on doubles, and am having trouble in one utility method that parses a string into a double. I've found a fix where using BigDecimal for the conversion solves the issue, but raises another problem when I go to convert the BigDecimal back to a double: I'm losing several places of precision. For example:
import java.math.BigDecimal;
import java.text.DecimalFormat;
public class test {
public static void main(String [] args){
String num = "299792.457999999984";
BigDecimal val = new BigDecimal(num);
System.out.println("big decimal: " + val.toString());
DecimalFormat nf = new DecimalFormat("#.0000000000");
System.out.println("double: "+val.doubleValue());
System.out.println("double formatted: "+nf.format(val.doubleValue()));
}
}
This produces the following output:
$ java test
big decimal: 299792.457999999984
double: 299792.458
double formatted: 299792.4580000000
The formatted double demonstrates that it's lost the precision after the third place (the application requires those lower places of precision).
How can I get BigDecimal to preserve those additional places of precision?
Thanks!
Update after catching up on this post. Several people mention this is exceeding the precision of the double data type. Unless I'm reading this reference incorrectly:
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3
then the double primitive has a maximum exponential value of Emax = 2K-1-1, and the standard implementation has K=11. So, the max exponent should be 511, no?

You've reached the maximum precision for a double with that number. It can't be done. The value gets rounded up in this case. The conversion from BigDecimal is unrelated and the precision problem is the same either way. See this for example:
System.out.println(Double.parseDouble("299792.4579999984"));
System.out.println(Double.parseDouble("299792.45799999984"));
System.out.println(Double.parseDouble("299792.457999999984"));
Output is:
299792.4579999984
299792.45799999987
299792.458
For these cases double has more than 3 digits of precision after the decimal point. They just happen to be zeros for your number and that's the closest representation you can fit into a double. It's closer for it to round up in this case, so your 9's seem to disappear. If you try this:
System.out.println(Double.parseDouble("299792.457999999924"));
You'll notice that it keeps your 9's because it was closer to round down:
299792.4579999999
If you require that all of the digits in your number be preserved then you'll have to change your code that operates on double. You could use BigDecimal in place of them. If you need performance then you might want to explore BCD as an option, although I'm not aware of any libraries offhand.
In response to your update: the maximum exponent for a double-precision floating-point number is actually 1023. That's not your limiting factor here though. Your number exceeds the precision of the 52 fractional bits that represent the significand, see IEEE 754-1985.
Use this floating-point conversion to see your number in binary. The exponent is 18 since 262144 (2^18) is nearest. If you take the fractional bits and go up or down one in binary, you can see there's not enough precision to represent your number:
299792.457999999900 // 0010010011000100000111010100111111011111001110110101
299792.457999999984 // here's your number that doesn't fit into a double
299792.458000000000 // 0010010011000100000111010100111111011111001110110110
299792.458000000040 // 0010010011000100000111010100111111011111001110110111

The problem is that a double can hold 15 digits, while a BigDecimal can hold an arbitrary number. When you call toDouble(), it attempts to apply a rounding mode to remove the excess digits. However, since you have a lot of 9's in the output, that means that they keep getting rounded up to 0, with a carry to the next-highest digit.
To keep as much precision as you can, you need to change the BigDecimal's rounding mode so that it truncates:
BigDecimal bd1 = new BigDecimal("12345.1234599999998");
System.out.println(bd1.doubleValue());
BigDecimal bd2 = new BigDecimal("12345.1234599999998", new MathContext(15, RoundingMode.FLOOR));
System.out.println(bd2.doubleValue());

Only that many digits are printed so that, when parsing the string back to double, it will result in the exact same value.
Some detail can be found in the javadoc for Double#toString
How many digits must be printed for the fractional part of m or a? There must be at least one digit to represent the fractional part, and beyond that as many, but only as many, more digits as are needed to uniquely distinguish the argument value from adjacent values of type double. That is, suppose that x is the exact mathematical value represented by the decimal representation produced by this method for a finite nonzero argument d. Then d must be the double value nearest to x; or if two double values are equally close to x, then d must be one of them and the least significant bit of the significand of d must be 0.

If it's entirely based on doubles ... why are you using BigDecimal? Wouldn't Double make more sense? If it's too large of value (or too much precision) for that then ... you can't convert it; that would be the reason to use BigDecimal in the first place.
As to why it's losing precision, from the javadoc
Converts this BigDecimal to a double. This conversion is similar to the narrowing primitive conversion from double to float as defined in the Java Language Specification: if this BigDecimal has too great a magnitude represent as a double, it will be converted to Double.NEGATIVE_INFINITY or Double.POSITIVE_INFINITY as appropriate. Note that even when the return value is finite, this conversion can lose information about the precision of the BigDecimal value.

You've hit the maximum possible precision for the double. If you would still like to store the value in primitives... one possible way is to store the part before the decimal point in a long
long l = 299792;
double d = 0.457999999984;
Since you are not using up (that's a bad choice of words) the precision for storing the decimal section, you can hold more digits of precision for the fractional component. This should be easy enough to do with some rounding etc..

I am trying to divide a 19 digit number by 100 (19 digit number/100) in java

I am trying to divide a 19 digit number by 100, i.e. 19 digit number/100, in java. It can be divisible using long data type but I'm not getting the full value as 17 digits and a decimal point followed by another 2 digits. Instead, I'm only getting 17 digits as it was a long data type so I need that digit like mathematical expression.
long cardValue = ("1234567891234567891");
long divide = (cardValue/100);
System.out.println(divide);
Output: 12345678912345678
I need output as 12345678912345678.91

longs are large integers, and when you divide one by another you use integer division, which omits everything right of the decimal point.
You could use a BigDecimal instead:
BigDecimal divide = new BigDecimal(String.valueOf(cardValue)).divide(new BigDecimal(100));

Firstly, you are doing integer division, and then expecting a decimal value. In Java, 1234 / 10 results in 123, and not 123.4. If you want a decimal result, make one of the values decimal, i.e., 1234.0 / 10 or 1234 / 10.0. This will yield 123.4
As of your problem, since the number is very large, using BigDecimal is a better idea (not BigInteger, as it will again perform integer division, while you want a decimal result). So, try
BigDecimal b = new BigDecimal("1234567891234567891");
BigDecimal res = b.divide(new BigDecimal("100"));
Or you can do a one-liner as
new BigDecimal("1234567891234567891").divide(new BigDecimal("100"))
In first, res = 12345678912345678.91, and the other will also result in the same.
Note : Although BigInteger and BigDecimal are all included in java.math package, but if it raises an error, import it by using
import java.math.BigDecimal;

Integer and long don't have decimal point.
Instead, use double.
double a = 123456789.00
double answer = (a/100.00)
Refer primitive data types in java.
If you want to get the string and want to dive, then use parseDouble() method to convert it to double. After this step perform division.

The divide variable is long type, that means no decimal fractions, just integer values. If you use double, you can obtain decimals, but that type don't have the precision you need in this case because it gives up to 15 significant numbers.
Your only solution is to use BigDecimal class. You can obtain whatever digit numbers you want. We used it for Banks and accounting applications, and is easy to understand how to work with it.
HTH

Converting String to BigDecimal with leading zeros

I am trying to convert an inputstream to objects and am having trouble with converting the below string to BigDecimal. I get 87.00 as the 0's are ignored. I am experimenting with DecimalFormat. Any help is appreciated. Thanks!
E.g. 0087 has to be converted to 00.87

You seem to indicate in comments that the initial string, "0087", is a fixed-point representation with two decimal places, there therefore being an implicit decimal point before the last two digits. There are several ways that you could convert that to a corresponding BigDecimal, but myself, I would go with this:
BigDecimal result = BigDecimal.valueOf(Long.parseLong("0087"), 2);
The key here is to understand that BigDecimals have two characteristic properties: an arbitrary-length sequence of decimal digits, and a scale conveying the place value of the least-significant digit, in the form of the number of digits to the right of the decimal point. The particular factory method demonstrated above accepts those as separate arguments, though it only works if the digit string is short enough to be represented as a long. The 2 corresponds directly to the number of (implicitly) fractional digits in your input.
Outputting the resulting BigDecimal as "00.87" instead of "0.87" is a separate issue, but doable, if it's really something you want.

Try this code
String str="0087";
int pos=str.lastIndexOf("0");
String resultat=str.substring(0,pos+1);
resultat+=".";
resultat+=str.substring(pos+1);
System.out.println(resultat);
new BigDecimal(resultat);

Java keep trailing 0 in float operations

the code:
Float f = Float.parseFloat("1.80");
System.out.println(f);
prints "1.8" on screen.
I need to keep the 0 in the float value (Float f) for some validation. How do I do this?

You are confusing a number value and its formatting. It is not possible to actually store 1.80 as a float, however it is possible to display the number as a formatted String which forces two decimal places. Your options are:
Keep the original String that the user entered, if the number of decimal places they gave
matters
Store the number as a float, but when displaying the number force it to display with two decimal places like this:
System.out.printf("%.2f\n", f);

That's simply a formatting issue:
System.out.printf("%.2f\n", f);

Floating point variables don't have decimal places. They have binary places.
1.8 and 1.80 are the same number, and they are represented the same way in a float or double.
If you want them presented with a certain number of decimal places, you have to convert to a decimal radix, via either BigDecimal or DecimalFormat, where you can control the number of decimal places.
In short the question doesn't really make sense as posed.

What kind of number is aa568 and how do I convert to it from decimal in Java?

I assume aa568 uses a different base than 10.
What type of number is this most likely?
And how do you convert a decimal number into this base using Java?

Could it be hexadecimal? If it is then just precede that by 0x ie. 0xaa568.

Assuming it is hexadecimal (0-9 + A-F instead of 0-9), you can convert it from hex to decimal as follows:
int i = Integer.parseInt(hexStr,16);
Where 16 is the base of the number system. Decimal is base 10, hexadecimal is base 16.
And back from decimal to hexadecimal:
String hexStr = Integer.toHexString(i);

Converting a number into a hexadecimal string can be done by the Integer.toHexString() method:
int number = 697704;
System.out.println(Integer.toHexString(number));
will print "aa568".

I'd assume that it's hexadecimal and more typically written 0xAA568 which is decimal 697704.
If you're asking how you would print a decimal number in a hexadecimal representation using Java ... see this stackoverflow article.

What kind of number may depend on the context, of none of the above fits, then it may be an integer sequence, I looked it up in the online encyclopedia of known integer sequences. Example a000045 is a Fibonacci sequence, (Formerly M0692 N0256), if it has to do with math it may also be a library reference to a paper written by AA. Only the Context can tell. Mathnet.ru had one reference "The behavior of the Lebesgue constants of two-dimensional Fourier sums over polygons" which fits the questioned number aa568.