Debug Java BigDecimal in Eclipse


I have been debugging some code recently using eclipse and I came across something that I can't explain and wanted to get an answer.  The following is a JUnit test that is successful.  When I attempted to debug it I get an odd result in the debug screen for csp at the end.  I would expect the intCompact to be: 231246....... , but it is -9223372036854775808. Yet the test is successful.

What am I missing?

import static org.junit.Assert.assertEquals;

import java.math.BigDecimal;

import org.junit.Test;

public class BigDecimalTest {

	public void Test1() {
		BigDecimal opp = new BigDecimal("1.5");
		BigDecimal liq = new BigDecimal("1.5");
		BigDecimal div = new BigDecimal("0.08");

		//Date startDate = new Date("5/9/2013");
		//Date endDate = new Date("11/15/2013");
		//BigDecimal years = startDate.getYearsBetweenBigDecimal(endDate);
		BigDecimal years = new BigDecimal(5.20547945205479E-01);

		BigDecimal dsp = opp.multiply(years).multiply(div);
		BigDecimal csp = opp.multiply(liq);
		csp = csp.add(dsp);

Open in new window

Who is Participating?
dpearsonConnect With a Mentor Commented:
The docs indicate that this is a form of "narrowing primitive conversion" as described here:

From a more practical standpoint, the toString() method in BigInteger is in some sense the gold standard for how the internal representation is turned back into a number that you can look at.  If you want to spend the time to work through this it will explain (implicitly) how the underlying representation works:

    public String toString(int radix) {
	if (signum == 0)
	    return "0";
	if (radix < Character.MIN_RADIX || radix > Character.MAX_RADIX)
	    radix = 10;

	// Compute upper bound on number of digit groups and allocate space
	int maxNumDigitGroups = (4*mag.length + 6)/7;
	String digitGroup[] = new String[maxNumDigitGroups];
	// Translate number to string, a digit group at a time
	BigInteger tmp = this.abs();
	int numGroups = 0;
	while (tmp.signum != 0) {
            BigInteger d = longRadix[radix];

            MutableBigInteger q = new MutableBigInteger(),
                              a = new MutableBigInteger(tmp.mag),
                              b = new MutableBigInteger(d.mag);
            MutableBigInteger r = a.divide(b, q);
            BigInteger q2 = q.toBigInteger(tmp.signum * d.signum);
            BigInteger r2 = r.toBigInteger(tmp.signum * d.signum);

            digitGroup[numGroups++] = Long.toString(r2.longValue(), radix);
            tmp = q2;

	// Put sign (if any) and first digit group into result buffer
	StringBuilder buf = new StringBuilder(numGroups*digitsPerLong[radix]+1);
	if (signum<0)

	// Append remaining digit groups padded with leading zeros
	for (int i=numGroups-2; i>=0; i--) {
	    // Prepend (any) leading zeros for this digit group
	    int numLeadingZeros = digitsPerLong[radix]-digitGroup[i].length();
	    if (numLeadingZeros != 0)
	return buf.toString();

Open in new window

Is your goal here to understand how BigDecimal is implemented?

intCompact is an internal part of the representation which BigDecimal can decide to use when it believes the value can be safely represented as an integer (long actually).

However, if the value being represented by BigDecimal is outside that range (or it believes it may be - such as doing a multiplication) then intCompact may no longer be in use - so checking the value can show you garbage essentially.

At that point, BigDecimal relies on intValue instead, which is itself a BigInteger and intCompact is ignored.

Does that make sense?

If you want to learn more about exactly how BigDecimal is processing these calculations, you can set a breakpoint inside the BigDecimal source code and step through it to see how the multiply and add operations are being implemented in this case.

Hope that helps,

infinidemAuthor Commented:
Interesting.  From the rt.jar file I did find this that relates to what Doug said.

static final long INFLATED = -9223372036854775808L

Open in new window

Which indicates that the values I am working with did hit the INFLATED threshold.  Okay in this example it does quickly go out to 56 decimal points, which would easily put it over the threshold.  From the source code I see that it would put it into a BigInteger.  Taking a look at the Debug I can see the intCompact is "Set" to inflated which means it is coming from intVal (BigInteger).  Then BigInteger is using an array of type int.  Which is supposingly in Big Endian.  Yet how would 158225327 translate into 231246...

csp	BigDecimal  (id=72)	
	intCompact	-9223372036854775808	
	intVal	BigInteger  (id=74)	
		bitCount	0	
		bitLength	0	
		firstNonzeroIntNum	0	
		lowestSetBit	0	
		mag	 (id=75)	
			[0]	158225327	
			[1]	-1753700659	
			[2]	1201931299	
			[3]	-1388385198	
			[4]	-1612795011	
			[5]	446100184	
		signum	1	
	precision	0	
	scale	56	
	stringCache	"2.31246575342465747748832427532761357724666595458984375000" (id=76)	

Open in new window

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.