double a = 10.0;
double b =3;
double c = a/b;
System.out.println(c*b);//answer = 10.0
BigDecimal bigDecimal1 = BigDecimal.valueOf(c);
BigDecimal bigDecimal2 = new BigDecimal("3");
System.out.println(bigDecimal1.multiply(bigDecimal2));//answer = 10.0000000000000005
I'm trying to make a calculator, but there's a problem with 10/3*3
I don't want to just calculate 10/3*3 this formula, I want to return this formula plus 0.2323232323232 of the float. So use the BigDecimal class. There's something wrong with it
I couldn't get the exact result, that's what I wanted 10,
Rather than get 10.0000000000000005
I believe your problem may be here
double c = a/b;
...
BigDecimal bigDecimal1 = BigDecimal.valueOf(c);
You're expecting that a double can perfectly represent 10/3, and I doubt it can
Maybe try something like this, which always represents numbers as BigDecimal
new BigDecimal("10").divide(new BigDecimal("3"))
At which point you'll notice that 10/3 is not representable as a decimal
Non-terminating decimal expansion; no exact representable decimal result
You need to decide how much precision you want, and then use rounding
new BigDecimal("10")
.setScale(10)
.divide(new BigDecimal("3"), BigDecimal.ROUND_HALF_EVEN)
Or you could use a rational number library, as suggested by Patricia. Perhaps see Is there a commonly used rational numbers library in Java?
Related
Why does the following code raise the exception shown below?
BigDecimal a = new BigDecimal("1.6");
BigDecimal b = new BigDecimal("9.2");
a.divide(b) // results in the following exception.
Exception:
java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
From the Java 11 BigDecimal docs:
When a MathContext object is supplied with a precision setting of 0 (for example, MathContext.UNLIMITED), arithmetic operations are exact, as are the arithmetic methods which take no MathContext object. (This is the only behavior that was supported in releases prior to 5.)
As a corollary of computing the exact result, the rounding mode setting of a MathContext object with a precision setting of 0 is not used and thus irrelevant. In the case of divide, the exact quotient could have an infinitely long decimal expansion; for example, 1 divided by 3.
If the quotient has a nonterminating decimal expansion and the operation is specified to return an exact result, an ArithmeticException is thrown. Otherwise, the exact result of the division is returned, as done for other operations.
To fix, you need to do something like this:
a.divide(b, 2, RoundingMode.HALF_UP)
where 2 is the scale and RoundingMode.HALF_UP is rounding mode
For more details see this blog post.
Because you're not specifying a precision and a rounding-mode. BigDecimal is complaining that it could use 10, 20, 5000, or infinity decimal places, and it still wouldn't be able to give you an exact representation of the number. So instead of giving you an incorrect BigDecimal, it just whinges at you.
However, if you supply a RoundingMode and a precision, then it will be able to convert (eg. 1.333333333-to-infinity to something like 1.3333 ... but you as the programmer need to tell it what precision you're 'happy with'.
You can do
a.divide(b, MathContext.DECIMAL128)
You can choose the number of bits you want: either 32, 64 or 128.
Check out this link :
http://edelstein.pebbles.cs.cmu.edu/jadeite/main.php?api=java6&state=class&package=java.math&class=MathContext
To fix such an issue I have used the below code
a.divide(b, 2, RoundingMode.HALF_EVEN)
Where 2 is scale. Now the problem should be resolved.
I had this same problem, because my line of code was:
txtTotalInvoice.setText(var1.divide(var2).doubleValue() + "");
I change to this, reading previous Answer, because I was not writing decimal precision:
txtTotalInvoice.setText(var1.divide(var2,4, RoundingMode.HALF_UP).doubleValue() + "");
4 is Decimal Precison
AND RoundingMode are Enum constants, you could choose any of this
UP, DOWN, CEILING, FLOOR, HALF_DOWN, HALF_EVEN, HALF_UP
In this Case HALF_UP, will have this result:
2.4 = 2
2.5 = 3
2.7 = 3
You can check the RoundingMode information here: http://www.javabeat.net/precise-rounding-of-decimals-using-rounding-mode-enumeration/
It´s a issue of rounding the result, the solution for me is the following.
divider.divide(dividend,RoundingMode.HALF_UP);
Answer for BigDecimal throws ArithmeticException
public static void main(String[] args) {
int age = 30;
BigDecimal retireMentFund = new BigDecimal("10000.00");
retireMentFund.setScale(2,BigDecimal.ROUND_HALF_UP);
BigDecimal yearsInRetirement = new BigDecimal("20.00");
String name = " Dennis";
for ( int i = age; i <=65; i++){
recalculate(retireMentFund,new BigDecimal("0.10"));
}
BigDecimal monthlyPension = retireMentFund.divide(
yearsInRetirement.divide(new BigDecimal("12"), new MathContext(2, RoundingMode.CEILING)), new MathContext(2, RoundingMode.CEILING));
System.out.println(name+ " will have £" + monthlyPension +" per month for retirement");
}
public static void recalculate (BigDecimal fundAmount, BigDecimal rate){
fundAmount.multiply(rate.add(new BigDecimal("1.00")));
}
Add MathContext object in your divide method call and adjust precision and rounding mode. This should fix your problem
Your program does not know what precision for decimal numbers to use so it throws:
java.lang.ArithmeticException: Non-terminating decimal expansion
Solution to bypass exception:
MathContext precision = new MathContext(int setPrecisionYouWant); // example 2
BigDecimal a = new BigDecimal("1.6",precision);
BigDecimal b = new BigDecimal("9.2",precision);
a.divide(b) // result = 0.17
For me, it's working with this:
BigDecimal a = new BigDecimal("9999999999.6666",precision);
BigDecimal b = new BigDecimal("21",precision);
a.divideToIntegralValue(b).setScale(2)
I know this question has been asked many times but I'm stuck and I don't know what the correct solution should be. I'm writing a program and there's a lot of numbers multiplication. The result must be rounded to 2 decimal places but sometimes the result is not correct.
For example:
I have two doubles v1=99.338 and v2=732.5.
I want to multiply them and have the result rounded to 2 decimal places.
The correct result is 72765.085 so after rounding it should be 72765.09 however in computer the result is 72765.08499999999 and all the rounding methods give 72765.08 which is obviously wrong.
For example
double x= v1 * v2; //x=72765.08499999999
DecimalFormat dec= new DecimalFormat("0.00");
decsetRoundingMode(RoundingMode.HALF_UP);
String v = dec.format(x);
gives 72765.08. The RoundingMode.CEILING in this example works OK but with other values for v and v2 is wrong.
NumberFormat nf= NumberFormat.getInstance();
nf.setMaximumFractionDigits(2);
nf.format(x);
gives 72765.08.
BigDecimal big = new BigDecimal(x, setScale(2, RoundingMode.HALF_UP);
double v = decWartosc.format(x);
gives v=72765.08.
Any other ideas?
I've tried this in C# and the result is correct.
You must use BigDecimal for the calculation itself.
BigDecimal exact = BigDecimal.valueOf(v1).multiply(BigDecimal.valueOf(v2));
BigDecimal big = exact.setScale(2, RoundingMode.HALF_UP);
System.out.println(big.toString());
First of all 99.337 * 732.5 = 72764.3525, and NOT 72765.085.
Now, this code:
BigDecimal b1 = new BigDecimal("99.337");
BigDecimal b2 = new BigDecimal("732.5");
BigDecimal result = b1.multiply(b2).setScale(2, RoundingMode.HALF_UP);
System.out.println(result);
Outputs:
72764.35
I have this strange issue of having to cap the precision of double numbers to a number of decimal places, or no decimal places at all, where the precision is handed to me like so: 0.001, 0.1, 1, 0.00001, etc.
So I could be given, for example, 1.234247324 and a precision indicator of 0.001, and with that I would need to return 1.234. If Instead I had been handed a precision of 1.0, I would then return 1 (no decimal places), and so forth.
I'm not sure how to go about this. Does anyone has pointers on how to tackle this?
Thank you!
Start with your value, and create a BigDecimal, then round to what you want.
double value = 1.23456; //not actually equal to that, but pretend.
BigDecimal better = new BigDecimal(value);
BigDecimal rounded = better.round(new MathContext(3));
Rounded is now the actual value you want. What can you do with the precision indicator?
BigDecimal precision = new BigDecimal("0.001");
Now you can get the scale of the precision, which you can use for rounding.
System.out.println(precision.scale());
//outputs 3.
That would be similar to using the logarithm.
Use a hybrid approach of the two other answers allows unusual precisions like 0.25 to be specified:
BigDecimal rounded = (x / precision).round(new MathContext(0)) * precision;
Try this code
double x = 1.234247324;
double p = 0.001;
double y = (int)(x * 1 / p) / (1 / p);
Don't really understand what you want to do but this results 1.234.
I am working on an currency converter android application in which I am trying to multiply a double with another double value but after multiplying I am not getting the correct value. i also tried BigDecimal and still didn't get the correct amount. What would be best way to multiply doubles?
second_amount = Double.parseDouble(second.getText().toString());
first_amount = Double.parseDouble(first.getText().toString());
result = first_amount * second_amount;
second.setText("" + df.format(result));
after using BigDecimal
second_amount = Double.parseDouble();
bdf = new BigDecimal(second.getText().toString());
//first_amount = Double.parseDouble(first.getText().toString());
bds = new BigDecimal(second.getText().toString());
BigDecimal bdr = bdf.multiply(bds);
//result = first_amount * second_amount;
second.setText("" + bdr);
If you are doing something like currency calculations, where exact representation of short decimal fractions matters, it is best not to involve double at all. Pass the original string representation of the number directly to the BigDecimal constructor, and do your arithmetic in BigDecimal.
For example, new BigDecimal("0.1") has the value 0.1, but new BigDecimal(0.1) has the very slightly different value 0.1000000000000000055511151231257827021181583404541015625, due to rounding on the conversion of the literal to double.
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