posted 7 years ago

Hi ,

can anybody let me know how a java.math.BigDecimal differs from a double or a float data types in java .

Thanks in advance .

can anybody let me know how a java.math.BigDecimal differs from a double or a float data types in java .

Thanks in advance .

Save India From Corruption - Anna Hazare.

Nicola Garofalo

Ranch Hand

Posts: 308

posted 7 years ago

Well, first of all:

A float is a decimal numeric type represented with

On javadoc you will find a quite clear description of BigDecimal class instead, but look at one of the many constructors of that class:

This constructor uses a BigInteger to represent arbitrary-precision integers values on the left of the decimal point, and an int (32 bit) to represent values on the right of the decimal point.

So BigDecimal is able to represent very precise decimal values and you should typically use it when you need really accurate computations.

Size counts Ravi

**float**and**double**are two primitive types, BigDecimal is a class. It doesn't just represent numbers but operations too.A float is a decimal numeric type represented with

**32 bit**. A double is a**64 bit**decimal number, so it can represent larger values than a float.On javadoc you will find a quite clear description of BigDecimal class instead, but look at one of the many constructors of that class:

BigDecimal(BigInteger unscaledVal, int scale)

Translates a BigInteger unscaled value and an int scale into a BigDecimal.

This constructor uses a BigInteger to represent arbitrary-precision integers values on the left of the decimal point, and an int (32 bit) to represent values on the right of the decimal point.

So BigDecimal is able to represent very precise decimal values and you should typically use it when you need really accurate computations.

Size counts Ravi

Bye,

Nicola

posted 7 years ago

Another often used constructor of BigDecimal is that which takes a String. This will use the exact number from the String without losing any of the precision. Compare this with double:

Because BigDecimal never rounds automatically or loses precision it is highly preferred in calculations where automatic rounding or losing precision could be disastrous - like financial programs.

That said, BigDecimal does come with a few drawbacks:

- they take up more memory than double

- they are always stored in the heap, not in the stack like double local variables

- you can't use +, -, * etc, but have to call methods like add, subtract and multiply. These all require another BigDecimal as operand so again more memory

The latter may be changed in Java 7; there have been rumours of adding support for +, -, * and / for BigDecimal and BigInteger as has been done with + and String.

Because BigDecimal never rounds automatically or loses precision it is highly preferred in calculations where automatic rounding or losing precision could be disastrous - like financial programs.

That said, BigDecimal does come with a few drawbacks:

- they take up more memory than double

- they are always stored in the heap, not in the stack like double local variables

- you can't use +, -, * etc, but have to call methods like add, subtract and multiply. These all require another BigDecimal as operand so again more memory

The latter may be changed in Java 7; there have been rumours of adding support for +, -, * and / for BigDecimal and BigInteger as has been done with + and String.

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

How To Ask Questions How To Answer Questions

Mike Simmons

Ranch Hand

Posts: 3090

14

posted 7 years ago

In some situations, it' s impossible to avoid losing precision, even with BigDecimal. Try dividing 2 by 3 with BigDecimal without losing precision at some point.

Well, almost always. Except when they aren't. Like most sentences with "always" (without "almost"), this is, actually, not always true. Look up "escape analysis" for details if you want them.

Rob Prime wrote:Because BigDecimal never rounds automatically or loses precision

In some situations, it' s impossible to avoid losing precision, even with BigDecimal. Try dividing 2 by 3 with BigDecimal without losing precision at some point.

Rob Prime wrote:they are always stored in the heap

Well, almost always. Except when they aren't. Like most sentences with "always" (without "almost"), this is, actually, not always true. Look up "escape analysis" for details if you want them.

It is sorta covered in the JavaRanch Style Guide. |