CODEWITHSUNDEEP
javabigdecimal
Volnyar
Volnyar

Reputation: 11

How can BigDecimal make no floating point inaccuracy?

I have known there is floating point inaccuracy regardless of OS, programming language. I, however, found there is no inaccuracy in this example. How can be this possible? I think converting stirng to double is needed for calculation, so there should be floating point inaccuracy!

import java.math.*;

class NoErrorBigDecimal {
    public static void main(String[] args)
    {
        BigDecimal e1=new BigDecimal("1.6");
        BigDecimal e2=new BigDecimal("0.1");


        System.out.println("result of add : "+e1.add(e2));
        System.out.println("result of multiplication : "+e1.multiply(e2));
    }
}

Upvotes: 0

Views: 1503

Answers (2)

David Olson
David Olson

Reputation: 22

Okay, so the inference here is that Double offers greater precision than BigDecimal, or provides "no floating point inaccuracy." You are correct in stating that every programming language has to make concessions for rounding. Java is no different.

Relative to other number types, BigDecimal offers greater control to the programmer over scale and rounding through numerous constructors such as 'BigDecimal(long val, MathContext mc)' and rounding modes (e.g., 'ROUND_UP') [see Java 7 API- http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html]. This is the reason that BigDecimal is the preferred type when dealing with currency.

Upvotes: -2

Stephen C
Stephen C

Reputation: 718788

How can BigDecimal make no floating point inaccuracy?

The answer is that it cannot.

Floating point inaccuracy (as you call it) is a fundamental of practical number representations used in computers.

The counter example for the proposition for BigDecimal is that the value of 1 / 3 cannot be represented precisely using a single BigDecimal (or a float or double for that matter).

  • It would be representable precisely using a base-3 floating point representation, but that is impractical.

  • It would be representable precisely by a (hypothetical) arbitrary precision rational number representation, but there is no standard Java SE class that implements that.

Another counter-example is Pi (3.14159...). Since it is irrational, it does not have a finite numeric representation (except in an impractical sense that involves circular logic ...)

On the other hand, if you confine yourself to numbers that you can represent precisely as finite decimal floating-point strings (like "1.6" and "0.1"), then BigDecimal can represent all of those numbers ... precisely.

I think converting stirng to double is needed for calculation, so there should be floating point inaccuracy!

Actually, it doesn't follow that there will be inaccuracy. It depends on the specific calculation, the specific representation, and (often) the actual values. For example:

  • I can (trivially) implement the calculation 1 / 2 and (provided the hardware works) guarantee that the the result will be represented accurately as a float or double.

  • The conversion of a decimal number in String form to a BigDecimal does not involve any calculation that has risk of loss of accuracy. (As implemented by the standard libraries, and assuming that there is O(N) available memory ... where N is the input string length.)

Upvotes: 3

Related Questions