Jason Bourne

Greenhorn

Posts: 9

posted 10 years ago

Hi,

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.

Can you suggest an alternative?

Thanks,

Jason.

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.

Can you suggest an alternative?

Thanks,

Jason.

posted 10 years ago

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

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.

*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

posted 10 years ago

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.

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.

SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6

How To Ask Questions How To Answer Questions

posted 10 years ago

Interesting. I hadn't heard this, but it sounds like something Sun would pursue (similar to unboxing wrapper instances for arithmetic).

But until then, we need to use methods.

Originally posted by Rob Prime:

... Actually, it may be possible that in Java 7 BigInteger and BigDecimal will support "normal" mathematical operations...

Interesting. I hadn't heard this, but it sounds like something Sun would pursue (similar to unboxing wrapper instances for arithmetic).

But until then, we need to use methods.

*~Joe Strummer*

sscce.org

Jason Bourne

Greenhorn

Posts: 9

posted 10 years ago

Actually, it is what I read in a presentation found here. The PDF itself is found here.

Please note that these are only proposals at the moment.

Please note that these are only proposals at the moment.

SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6

How To Ask Questions How To Answer Questions

posted 10 years ago

Cool. Thanks for the links!

Cool. Thanks for the links!

*~Joe Strummer*

sscce.org