BigDecimal math operations problem (Groovy)

[Anthony Bailey]

Hello,

I am trying to do various math operations using BigDecimal and are experiencing weird results. Here are some examples. Here's the groovy code.

MathContext mathContext = new MathContext(4, RoundingMode.DOWN)
        BigDecimal a = null
        def BigDecimal b = null
        def BigDecimal c = null 
 
        a = (someBigDecimal()).multiply(anotherBigDecimal(), mathContext)
        System.out.println("a = " + a)
        b = new BigDecimal(a, mathContext).divide(new BigDecimal("100"), mathContext)
        System.out.println("b = " + b)
        c = new BigDecimal(b, mathContext).multiply(new BigDecimal("100"), mathContext)
        System.out.println("c = " + c)

I am getting the following results. Shouldn't c in the last run be 194.0. Before I used MathContext, I was getting something like 193.98797566565.

a = 550.0
b = 5.5
c = 550.0

a = 194.0
b = 1.94
c = 193.9

THANKS!!!
[ December 02, 2008: Message edited by: Martijn Verburg ]

[Bill Shirley]

This is obviously not actual java code. If you Post Real Code we can better help you.

[Anthony Bailey]

I don't understand....this is real code in Groovy. I may have posted in the wrong place perhaps?

[Mike Simmons]

This would probably be better in the Groovy forum. Perhaps some nice bartender will move it for you.

Still, the underlying issue is fairly straightforward Java. The problem (if you consider it a problem) is that you've specified a MathContext with 4 digits of precision and RoundingMode.DOWN. This means that when you round 193.98797566565 to four digits you get 193.9 - even though the next digit is 8, you've sait to round down, so that's what happens. If you want "normal" rounding as it's taught in most science and engineering classes, use RoundingMode.HALF_UP.

[Anthony Bailey]

I was curious how I ended up with 193.98565656 in the first place when multiplying by 100.

[Marc Peabody]

Here's a good learning point. Be aware that Groovy additionally makes some object changes to what you're probably assuming are primitive doubles.

There's a consequence that isn't blatantly obvious in the two snippets below:
... new BigDecimal(a, mathContext) ...
... new BigDecimal(b, mathContext) ...

There is no constructor for BigDecimal that takes a (BigDecimal, MathContext)!!! Why isn't this throwing an exception? Groovy is automatically changing types under the covers for... um... convenience. Let's look at example to see what kinds of things Groovy does under the covers.


Consider the following code:
MathContext mathContext = new MathContext(5, RoundingMode.DOWN)
println 5.6789
println new BigDecimal(5.6789)
println new BigDecimal(5.6789, mathContext)

In the first print line, Groovy automatically treats 5.6789 as a BigDecimal under the covers. You can confirm this with println ((5.6789).class) which will print out that the type is BigDecimal.

In the second print line, we now know that the 5.6789 is already a BigDecimal. However, there is no constructor for BigDecimal that accepts another BigDecimal... so Groovy forces our value into a double to satisfy the constructor. This sends the precision into absolute craziness and we get 5.67889999999999961488583721802569925785064697265625 in the console.

The third print line is where things get dangerous because the MathContext is going to hide the precision craziness we saw from line 2. It prints 5.6788 - which is .0001 off from what we expected.

So what could be done differently in your code?

import java.math.MathContext
import java.math.RoundingMode
 
def someBigDecimal = {0.12345}
def anotherBigDecimal = {52.71325}
 
MathContext mathContext = new MathContext(4, RoundingMode.DOWN)
 
def a = (someBigDecimal()).multiply(anotherBigDecimal(), mathContext)
println "a = $a"
def b = a.divide(100 as BigDecimal, mathContext)
println "b = $b"
def c = b.multiply(100 as BigDecimal, mathContext)
println "c = $c"    

Notice that I went straight for a.divide and b.divide.

Also, I'm using a little trick to make Groovy treat my 100 values as BigDecimals. If I hadn't done this, Groovy would have treated them as BigInteger. I code have alternatively made them 100.0 (with the decimal) and Groovy would have treated them as BigDecimal automatically.

Tricky, huh?