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.
posted 11 years ago
I was curious how I ended up with 193.98565656 in the first place when multiplying by 100.
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?
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.
A good workman is known by his tools.
Squanch that. And squanch this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop