As specified in javadoc, a BigDecimal is defined by an integer value and a scale.
The value of the number represented by the BigDecimal is therefore (unscaledValue × 10^(-scale)).
So BigDecimal("1761e+5") has scale -5 and BigDecimal(176100000) has scale 0.
The division of the two BigDecimal is done using the -5 and 0 scales respectively because the scales are not specified when dividing. The divide documentation explains why the results are different.
dividepublic BigDecimal divide(BigDecimal divisor)Returns a
BigDecimalwhose value is(this / divisor), and whose preferred scale is(this.scale() - divisor.scale()); if the exact quotient cannot be represented (because it has a non-terminating decimal expansion) anArithmeticExceptionis thrown.Parameters:
divisor- value by which this BigDecimal is to be divided.Returns:
this / divisorThrows:
ArithmeticException— if the exact quotient does not have a terminating decimal expansionSince:
1.5
If you specify a scale when dividing, e.g. dividendo.divide(BigDecimal.valueOf(1000), 0, RoundingMode.HALF_UP) you will get the same result.
As specified in javadoc, a BigDecimal is defined by an integer value and a scale.
The value of the number represented by the BigDecimal is therefore (unscaledValue × 10^(-scale)).
So BigDecimal("1761e+5") has scale -5 and BigDecimal(176100000) has scale 0.
The division of the two BigDecimal is done using the -5 and 0 scales respectively because the scales are not specified when dividing. The divide documentation explains why the results are different.
dividepublic BigDecimal divide(BigDecimal divisor)Returns a
BigDecimalwhose value is(this / divisor), and whose preferred scale is(this.scale() - divisor.scale()); if the exact quotient cannot be represented (because it has a non-terminating decimal expansion) anArithmeticExceptionis thrown.Parameters:
divisor- value by which this BigDecimal is to be divided.Returns:
this / divisorThrows:
ArithmeticException— if the exact quotient does not have a terminating decimal expansionSince:
1.5
If you specify a scale when dividing, e.g. dividendo.divide(BigDecimal.valueOf(1000), 0, RoundingMode.HALF_UP) you will get the same result.
The expressions new BigDecimal("176100000") and new BigDecimal("1761e+5") are not equal. BigDecimal keeps track of both value, and precision.
BigDecimal("176100000") has 9 digits of precision and is represented internally as the BigInteger("176100000"), multiplied by 1. BigDecimal("1761e+5") has 4 digits of precision and is represented internally as the BigInteger("1761"), multiplied by 100000.
When you a divide a BigDecimal by a value, the result respects the digits of precision, resulting in different outputs for seemingly equal values.
You haven't specified a scale for the result. Please try this
2019 Edit: Updated answer for JDK 13. Cause hopefully you've migrated off of JDK 1.5 by now.
import java.math.BigDecimal;
import java.math.RoundingMode;
public class Main {
public static void main(String[] args) {
BigDecimal a = new BigDecimal("1");
BigDecimal b = new BigDecimal("3");
BigDecimal c = a.divide(b, 2, RoundingMode.HALF_UP);
System.out.println(a + "/" + b + " = " + c);
}
}
Please read JDK 13 documentation.
Old answer for JDK 1.5 :
import java.math.*;
public class x
{
public static void main(String[] args)
{
BigDecimal a = new BigDecimal("1");
BigDecimal b = new BigDecimal("3");
BigDecimal c = a.divide(b,2, BigDecimal.ROUND_HALF_UP);
System.out.println(a+"/"+b+" = "+c);
}
}
this will give the result as 0.33. Please read the API
import java.math.*;
class Main{
public static void main(String[] args) {
// create 3 BigDecimal objects
BigDecimal bg1, bg2, bg3;
MathContext mc=new MathContext(10,RoundingMode.DOWN);
bg1 = new BigDecimal("2.4",mc);
bg2 = new BigDecimal("32301",mc);
bg3 = bg1.divide(bg2,mc); // divide bg1 with bg2
String str = "Division result is " +bg3;
// print bg3 value
System.out.println( str );
}
}
giving wrong answer
public static double divide(double d1, double d2) {
BigDecimal b1 = new BigDecimal(d1);
BigDecimal b2 = new BigDecimal(d2);
return b1.divide(b2, 2, RoundingMode.DOWN).doubleValue();
}
This example returns 105.0000
public class TestBigDecimal {
static BigDecimal decimal = new BigDecimal(1050).setScale(4, BigDecimal.ROUND_HALF_UP);
static BigDecimal ONE_HUNDRED = new BigDecimal(100);
static BigDecimal TEN = new BigDecimal(10);
public static void main(String[] args)
{
BigDecimal decimalResult = decimal.divide(ONE_HUNDRED).multiply(TEN) ;
System.out.println(decimalResult);
}
}
You should adjust the scale during the creation of decimal variable.
That's because the division you are computing is made with a scale of 0. Quoting the method divide(divisor, roundingMode) Javadoc:
Returns a
BigDecimalwhose value is(this / divisor), and whose scale isthis.scale().
In this case, this.scale() refers to the scale of the numerator, which is 0 because the numerator is BigDecimal.valueOf(n), with n being an integer.
You need to change this division to use divide(divisor, scale, roundingMode) instead and specify the scale you want.
From the java doc
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:
// numberator / denominator (round down)
probT = BigDecimal.valueOf(numerator).divide(BigDecimal.valueOf(denominator), 10,RoundingMode.DOWN);
where 10 is precision(decimal places precision) and RoundingMode.DOWN is rounding mode