In Java, I want to take a double value and convert it to a BigDecimal and print out its String value to a certain precision.
import java.math.BigDecimal;
public class Main {
public static void main(String[] args) {
double d=-.00012;
System.out.println(d+""); //This prints -1.2E-4
double c=47.48000;
BigDecimal b = new BigDecimal(c);
System.out.println(b.toString());
//This prints 47.47999999999999687361196265555918216705322265625
}
}
It prints this huge thing:
47.47999999999999687361196265555918216705322265625
and not
47.48
The reason I'm doing the BigDecimal conversion is sometimes the double value will contain a lot of decimal places (i.e. -.000012) and the when converting the double to a String will produce scientific notation -1.2E-4. I want to store the String value in non-scientific notation.
I want to have BigDecimal always have two units of precision like this: "47.48". Can BigDecimal restrict precision on conversion to string?
The reason of such behaviour is that the string that is printed is the exact value - probably not what you expected, but that's the real value stored in memory - it's just a limitation of floating point representation.
According to javadoc, BigDecimal(double val) constructor behaviour can be unexpected if you don't take into consideration this limitation:
The results of this constructor can be somewhat unpredictable. One
might assume that writing new BigDecimal(0.1) in Java creates a
BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with
a scale of 1), but it is actually equal to
0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that
matter, as a binary fraction of any finite length). Thus, the value
that is being passed in to the constructor is not exactly equal to
0.1, appearances notwithstanding.
So in your case, instead of using
double val = 77.48;
new BigDecimal(val);
use
BigDecimal.valueOf(val);
Value that is returned by BigDecimal.valueOf is equal to that resulting from invocation of Double.toString(double).
It prints 47.48000 if you use another MathContext:
BigDecimal b = new BigDecimal(d, MathContext.DECIMAL64);
Just pick the context you need.
You want to try String.format("%f", d), which will print your double in decimal notation. Don't use BigDecimal at all.
Regarding the precision issue: You are first storing 47.48 in the double c, then making a new BigDecimal from that double. The loss of precision is in assigning to c. You could do
BigDecimal b = new BigDecimal("47.48")
to avoid losing any precision.
Why not :
b = b.setScale(2, RoundingMode.HALF_UP);
It's printing out the actual, exact value of the double.
Double.toString(), which converts doubles to Strings, does not print the exact decimal value of the input -- if x is your double value, it prints out exactly enough digits that x is the closest double to the value it printed.
The point is that there is no such double as 47.48 exactly. Doubles store values as binary fractions, not as decimals, so it can't store exact decimal values. (That's what BigDecimal is for!)
The String.format syntax helps us convert doubles and BigDecimals to strings of whatever precision.
This java code:
double dennis = 0.00000008880000d;
System.out.println(dennis);
System.out.println(String.format("%.7f", dennis));
System.out.println(String.format("%.9f", new BigDecimal(dennis)));
System.out.println(String.format("%.19f", new BigDecimal(dennis)));
Prints:
8.88E-8
0.0000001
0.000000089
0.0000000888000000000
BigDecimal b = new BigDecimal(c).setScale(2,BigDecimal.ROUND_HALF_UP);
In Java 9 the following is deprecated:
BigDecimal.valueOf(d).setScale(2, BigDecimal.ROUND_HALF_UP);
instead use:
BigDecimal.valueOf(d).setScale(2, RoundingMode.HALF_UP);
Example:
double d = 47.48111;
System.out.println(BigDecimal.valueOf(d)); //Prints: 47.48111
BigDecimal bigDecimal = BigDecimal.valueOf(d).setScale(2, RoundingMode.HALF_UP);
System.out.println(bigDecimal); //Prints: 47.48
Related
I have two float values:
float value1 = 1.9f;
float value2 = 20;
I want to multiply them and get an exact result, so I use BigDecimal and expect 38 as result:
BigDecimal total = new BigDecimal(value1).multiply(new BigDecimal(value2));
System.out.println(total); // 37.99999952316284179687500
When I do the same test with 10 and 1.9, I get 18.99999976158142089843750 instead of 19.
Why do I lose precision?
This is explained in the javadoc for the BigDecimal(double) constructor:
The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding.
And although your variables are floats, there is not ctor that takes floats, so they are cast as doubles. And like the docs say, if you used Strings for your values, you would get the exact result (38) you expect.
The error is right at the start:
float value1 = 1.9f;
You may think that value1 now contains exactly the value 1.9. But this is not the case. Floating point values are stored in binary. The important thing to remember is that some real values cannot be expressed by a finite sequence of digits, such as a float. 1.9 is such a number (just like in decimal the value 1.333... cannot be expressed by a finite sequence of digits).
So you should use BigDecimal from the start. Then the values can be exactly represented (because it is not stored in binary but in decimal) and the calculation results in the expected answer.
Let's say your value1 is a double as primitive type and want to output 2 decimal places and the value1 is 350. 4432567
double roundTotal = Math.round(value1 * 100.0) / 100.0;
or
double roundTotal = (double) Math.round(value1 * 100) / 100;
Output:
350.44
Note that the 2 digits precision. Zeros indicate the wanted number of decimal to display.
Example #2
double roundTotal = (double) Math.round(value1 * 10000) / 10000;
Output:
350.4432
You can use
Math.floor(float f);
//or
Math.ceil(float f);
functions for the exact value. Or you can override these functions for BigDecimal class.
I am trying to parse string to float but it gives me some different output.
Suppose my code :
String a = "111111111111111111111.23";
Float f = Float.parseFloat(a);
System.out.println(f);
It gives me something like: 1.1111111E20
In a simple manner, it gives me 111111110000000000000
How do I get all the data shown? I do not want to truncate the input data.
How to get whole data as it is. Don't want to truncate the input data.
Then whatever you do, don't use a float. At least use double, but even double will struggle with that value as IEEE-754 double-precision floating point numbers are only precise to roughly 15 digits when expressed in base 10. For greater precision than that, look at BigDecimal.
BigDecimal never rounds automatically or loses precision it is highly preferred in calculations.
A float is a decimal numeric type represented with 32 bit.
A double is a 64 bit decimal number, so it can represent larger values than a float.
You can Use BigDecimal
public static void main(String[] args) {
String a = "111111111111111111111.23";
BigDecimal f = new BigDecimal(a);
System.out.println(f);
}
Output
111111111111111111111.23
I'm trying to create a BigDecimal class that has always a fixed maximum fractions count.
But when printing that number, it is not cut to the fractions I defined in scale. Why?
class MyDecimal extends BigDecimal {
public MyDecimal(double val) {
super(val);
setScale(4, RoundingMode.HALF_UP);
}
}
Sysout(new MyDecimal(0.0001));
//0.000100000000000000008180305391403130954586231382563710212707519531254
BigDecimal is immutable, and should not be extended. setScale() does not modify the BigDecimal instance. It returns a copy of the BigDecimal instance with the scale modified (as every other "mutating" method of BigDecimal, since it's immutable). Calling it and ignoring the returned value is thus useless.
Instead of extending BigDecimal, create a factory method:
public static BigDecimal createWithScale4(double d) {
BigDecimal temp = new BigDecimal(d);
return temp.setScale(4);
}
The problem is that you are putting in your input as a double. This is from the javadoc:
The results of this constructor can be somewhat unpredictable. One
might assume that writing new BigDecimal(0.1) in Java creates a
BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with
a scale of 1), but it is actually equal to
0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that
matter, as a binary fraction of any finite length). Thus, the value
that is being passed in to the constructor is not exactly equal to
0.1, appearances notwithstanding
Since you are using a double, it is being stored as a floating-point number, and not as a precision number. It then converts that non-precision floating-point number to a precision BigDecimal, which then puts it out as a precise number. It works if the input is a String, however, since a String is just text, and converts the string directly to a BigDecimal. See this from here:
Creating a big decimal from a (scalar) double is simple:
bd = new BigDecimal(1.0);
To get a BigDecimal from a Double, get its
doubleValue() first.
However it is a good idea to use the string constructor:
bd = new BigDecimal("1.5");
If you don't, then you'll get the following,
bd = new BigDecimal(1.5);
bd.toString(); // => 0.1499999999999999944488848768742172978818416595458984375
So do it like this:
Sysout(new MyDecimal("0.0001"));
Also, as #JBNizet points out, you're extending an immutable object, a BigDecimal. You're ignoring the return value of setting the scale. This could be changed by using a method such as the one below:
public static BigDecimal createBigDecimal(String s) {
BigDecimal bigdeci = new BigDecimal(s);
return bigdeci.setScale(4);
}
The problem is that you're passing the argument as a double instead of as a string. Before the argument reaches the Big Decimal, it has already been converted into binary form to store as a double, which introduces a tiny error (it's equivalent to trying to write 1/3 as a decimal and getting 0.3333333333; it won't be quite right unless you have infinite precision).
Instead, try:
Sysout((new BigDecimal("0.0001")).setScale(4,RoundingMode.HALF_UP));
float f = 0.00f;
System.out.println(f);
gives the output:
0.00
I'd like to format a number represented by a percentage to 2 decimal places. But the result should be a float and not a string.
e.g.
10.001 needs to be converted to 10.00
0.0 needs to be converted to 0.00
78.8 needs to be converted to 78.80
The values thus formatted will be assigned to a float.. how would one accomplish this?
private float parse(float val){
DecimalFormat twoDForm = new DecimalFormat("#.##");
return Float.valueOf(twoDForm.format(val));
}
As long as you call it passing an valid float, your result will be a float.
But you can't show the right most zero if its not a String.
In the general case, you can't do that. There's no guarantee that a particular decimal value can be represented by a float that has only two digits right of the decimal.
A float is the wrong data type for this kind of precision. You need to use a decimal type or a scaled integer instead.
Assignment works the same way. If you assign the value 133.47 to a floating-point variable, your environment will assign the closest valid floating-point number to the variable. The closest valid floating-point number will probably not be 133.47.
You can compile and execute this program in C.
#include <stdio.h>
int main (void) {
float r;
r = 133.47;
printf("%.2f, %f\n", r, r);
return 0;
}
It prints these values on my system
$ ./a.out
133.47, 133.470001
Formatting to two decimal places changed the way 'r' looks, but it didn't change its value. Your system will do floating-point arithmetic based on the actual value, not the formatted value. (Unless you also change the data type.)
Floats don't have decimal places. They have binary places. It follows that the only fractions that can be represented exactly in a float to two decimal places are 0, 0.25, 0.5, 0.75. In all the other cases what you are asking is impossible.
import java.text.DecimalFormat;
public class Padding {
public static void main(String[] args) {
float value = 10.001f;
DecimalFormat decimal = new DecimalFormat("0.00");
String formattedValue = decimal.format(value);
System.out.println(formattedValue);
}
}
Output : 10.00
I wanted to see if anyone can explain why the following code works with valueOf but not others.
import java.math.BigDecimal;
public class Change {
public static void main(String args[]) {
double a = 4.00d;
double b = 3.10d;
BigDecimal a1 = new BigDecimal(a);
BigDecimal b1 = new BigDecimal(b);
BigDecimal diff = a1.subtract(b1);
System.out.println("Double difference");
System.out.println(diff);
float c = 4.00f;
float d = 3.10f;
BigDecimal a2 = new BigDecimal(c);
BigDecimal b2 = new BigDecimal(d);
BigDecimal diff2 = a2.subtract(b2);
System.out.println("Float difference");
System.out.println(diff2);
System.out.println("Valueof Difference");
System.out.println(BigDecimal.valueOf(4.00).subtract(BigDecimal.valueOf(3.10)));
}
}
The output looks like:
>java Change
Double difference
0.899999999999999911182158029987476766109466552734375
Float difference
0.900000095367431640625
Valueof Difference
0.9
My question is: What does valueOf() do to get the precision?
Is there any other way of getting the correct result without rounding off to the 2 digits manually?
thanks,
Looking at the source code for BigDecimal, it does:
public static BigDecimal valueOf(double val) {
// Reminder: a zero double returns '0.0', so we cannot fastpath
// to use the constant ZERO. This might be important enough to
// justify a factory approach, a cache, or a few private
// constants, later.
return new BigDecimal(Double.toString(val));
}
From its JavaDoc:
Translates a double into a BigDecimal,
using the double's canonical string
representation provided by the
Double.toString(double) method.
Note: This is generally the preferred way to
convert a double (or float) into a
BigDecimal, as the value returned is
equal to that resulting from
constructing a BigDecimal from the
result of using
Double.toString(double).
Because of floating-point representation, a double value is not exactly what you set it as. However, during String representation, it rounds off what it displays. (All of the rules are on it's JavaDoc).
Furthermore, because of this rounding, if you did:
BigDecimal d = BigDecimal.valueOf(4.00000000000000000000000000000000001));
you would get the wrong value. (d == 4.0)
So, it's pretty much always better to initialize these with strings.
BigDecimal.valueOf(double) first does a conversion from double to String, then String to BigDecimal.
In the first case, you're starting with a double or float, converting to BigDecimal, calculating the difference. In the second case, you're starting with double or float, converting to a String, then converting to BigDecimal, then calculating the difference.
From the Javadocs:
public static BigDecimal valueOf(double val)
Translates a double into a BigDecimal,
using the double's canonical string
representation provided by the
Double.toString(double) method. Note:
This is generally the preferred way to
convert a double (or float) into a
BigDecimal, as the value returned is
equal to that resulting from
constructing a BigDecimal from the
result of using
Double.toString(double).
I think this answers both of your questions.
Cheers,
The valueOf works because it calls Double.toString. from the Javadoc:
public static BigDecimal valueOf(double val)
Translates a double into a BigDecimal, using the double's
canonical string representation
provided by the
Double.toString(double) method.
When you pass a double into the BigDecimal constructor, the constructor takes the floating-point value and reproduces it exactly. The toString code finds an approximation for the floating point value.
In case you didn't notice, using System.out.println() to show a floating point number doesn't show the same results as if you wrap the floating point number in a BigDecimal first (using the BigDecimal constructor that takes a double).