I have got 2 questions here. I would like to know why the following conversion is messed up.
As you may see, the BigDecimal is way off the mark. Why is it so?
The second question is, why is it so inconvenient to perform arithmetic on BigDecimals? I was being lazy and used double to calculate and printed as a BigDecimal so that I can see the full result of my calculation. Printing a double results in use of exponential notation. The arithmetic part is a bit complicated as well and I don't want to make too many function calls which I would end up doing if I used numbers of "BigDecimal" type.
If you check the API documentation for BigDecimal's constructors, you will see the difference between creating an instance using a double (whose precision has already been compromised by forcing it into IEEE 754 standards) and creating an instance using a String (which can be translated accurately). This is illustrated with the code below.
BigDecimal instances are objects -- not simple values. So you need to perform calculations using method calls -- not simple operators. That's just the price of precision over IEEE 754 standards.
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Originally posted by marc weber: BigDecimal instances are objects -- not simple values. So you need to perform calculations using method calls -- not simple operators. That's just the price of precision over IEEE 754 standards.
Actually, it may be possible that in Java 7 BigInteger and BigDecimal will support "normal" mathematical operations. They would be special cases just like String, the only class to date to support operators.