Retain precision with double in Java

Question

public class doublePrecision {
    public static void main(String[] args) {

        double total = 0;
        total += 5.6;
        total += 5.8;
        System.out.println(total);
    }
}

The above code prints:

11.399999999999

How would I get this to just print (or be able to use it as) 11.4?

Strick

Related: Is floating point math broken? – Kotta

Answer 1

As others have mentioned, you'll probably want to use the BigDecimal class, if you want to have an exact representation of 11.4.

Now, a little explanation into why this is happening:

The float and double primitive types in Java are floating point numbers, where the number is stored as a binary representation of a fraction and a exponent.

More specifically, a double-precision floating point value such as the double type is a 64-bit value, where:

• 1 bit denotes the sign (positive or negative).
• 11 bits for the exponent.
• 52 bits for the significant digits (the fractional part as a binary).

These parts are combined to produce a double representation of a value.

(Source: Wikipedia: Double precision)

For a detailed description of how floating point values are handled in Java, see the Section 4.2.3: Floating-Point Types, Formats, and Values of the Java Language Specification.

The byte, char, int, long types are fixed-point numbers, which are exact representions of numbers. Unlike fixed point numbers, floating point numbers will some times (safe to assume "most of the time") not be able to return an exact representation of a number. This is the reason why you end up with 11.399999999999 as the result of 5.6 + 5.8.

When requiring a value that is exact, such as 1.5 or 150.1005, you'll want to use one of the fixed-point types, which will be able to represent the number exactly.

As has been mentioned several times already, Java has a BigDecimal class which will handle very large numbers and very small numbers.

From the Java API Reference for the BigDecimal class:

Immutable, arbitrary-precision signed decimal numbers. A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale. If zero or positive, the scale is the number of digits to the right of the decimal point. If negative, the unscaled value of the number is multiplied by ten to the power of the negation of the scale. The value of the number represented by the BigDecimal is therefore (unscaledValue × 10^-scale).

There has been many questions on Stack Overflow relating to the matter of floating point numbers and its precision. Here is a list of related questions that may be of interest:

• Why do I see a double variable initialized to some value like 21.4 as 21.399999618530273?
• How to print really big numbers in C++
• How is floating point stored? When does it matter?
• Use float or decimal for accounting application dollar amount?

If you really want to get down to the nitty gritty details of floating point numbers, take a look at What Every Computer Scientist Should Know About Floating-Point Arithmetic.

Indomitable

In fact, there are usually 53 significant bits because the 1 before the "decimal" point is implied for all but denormalised values, giving an additional bit of precision. e.g. 3 is stored as (1.)1000... x 2^1 whilst 0.5 is stored as (1.)0000... x 2^-1 When the value is denormalised (all exponent bits are zero) there can, and usually will, be fewer significant digits e.g. 1 x 2^-1030 is stored as (0.)00000001 x 2^-1022 so seven significant digits have been sacrificed to scale. – Rife

It should be noted that while BigDecimal is much slower than double in this case it isn't needed as double has 15 decimal places of accuracy, you just need rounding. – Fluctuation

@PeterLawrey It has 15 decimal digits of accuracy, if they are all before the decimal point. Anything can happen after the decimal point, because of the incommensurability of decimal and binary fractions. – Goldin

@EJP You are right, it has around 15 significant digits of precision. It can be 16 but it's safer to assume it is 15 or perhaps 14. – Fluctuation

@PeterLawrey EJP's correction was due to my question: #36345258 could you please expand on why its not exactly 15 and what situations it can be 16 or 14 ? – Ireful

Answer 2

When you input a double number, for example, 33.33333333333333, the value you get is actually the closest representable double-precision value, which is exactly:

33.3333333333333285963817615993320941925048828125

Dividing that by 100 gives:

0.333333333333333285963817615993320941925048828125

which also isn't representable as a double-precision number, so again it is rounded to the nearest representable value, which is exactly:

0.3333333333333332593184650249895639717578887939453125

When you print this value out, it gets rounded yet again to 17 decimal digits, giving:

0.33333333333333326

Misbehavior

To anyone who is reading this in the future and is puzzled as to why the answer has nothing to do with the question: some moderator decided to merge the question I (and others) had answered with this, rather different, question. – Misbehavior

How do you know the exact double value? – Fluorescence

@mikeyaworski en.wikipedia.org/wiki/Double-precision_floating-point_format See double precision examples – Trichromatic

Answer 3

If you just want to process values as fractions, you can create a Fraction class which holds a numerator and denominator field.

Write methods for add, subtract, multiply and divide as well as a toDouble method. This way you can avoid floats during calculations.

EDIT: Quick implementation,

public class Fraction {

private int numerator;
private int denominator;

public Fraction(int n, int d){
    numerator = n;
    denominator = d;
}

public double toDouble(){
    return ((double)numerator)/((double)denominator);
}


public static Fraction add(Fraction a, Fraction b){
    if(a.denominator != b.denominator){
        double aTop = b.denominator * a.numerator;
        double bTop = a.denominator * b.numerator;
        return new Fraction(aTop + bTop, a.denominator * b.denominator);
    }
    else{
        return new Fraction(a.numerator + b.numerator, a.denominator);
    }
}

public static Fraction divide(Fraction a, Fraction b){
    return new Fraction(a.numerator * b.denominator, a.denominator * b.numerator);
}

public static Fraction multiply(Fraction a, Fraction b){
    return new Fraction(a.numerator * b.numerator, a.denominator * b.denominator);
}

public static Fraction subtract(Fraction a, Fraction b){
    if(a.denominator != b.denominator){
        double aTop = b.denominator * a.numerator;
        double bTop = a.denominator * b.numerator;
        return new Fraction(aTop-bTop, a.denominator*b.denominator);
    }
    else{
        return new Fraction(a.numerator - b.numerator, a.denominator);
    }
}

}

Septima

Surely numerator and denominator should be ints? Why would you want floating-point precision? – Machismo

Guess it's not really necessary but it avoids casting in the toDouble function so the code reads better. – Septima

ViralShah: It also potentially introduces floating-point error when dealing with mathematical operations. Given that the point of this exercise is to avoid exactly that, it seems prudent to alter it. – Machismo

Edited to use ints instead of doubles, for the reasons mentioned by Samir Talwar above. – Septima

This implementation of fractions has problems as it does not reduce them to a simplest form. 2/3*1/2 give 2/6 where you really want the answer to be 1/3. Ideally in the constructor you want to find the gcd of numerator and divisor and divide both by that. – Redwood

it gives ERROR incompatible types: possible lossy conversion from double to int ---- – Richman

Answer 4

Observe that you'd have the same problem if you used limited-precision decimal arithmetic, and wanted to deal with 1/3: 0.333333333 * 3 is 0.999999999, not 1.00000000.

Unfortunately, 5.6, 5.8 and 11.4 just aren't round numbers in binary, because they involve fifths. So the float representation of them isn't exact, just as 0.3333 isn't exactly 1/3.

If all the numbers you use are non-recurring decimals, and you want exact results, use BigDecimal. Or as others have said, if your values are like money in the sense that they're all a multiple of 0.01, or 0.001, or something, then multiply everything by a fixed power of 10 and use int or long (addition and subtraction are trivial: watch out for multiplication).

However, if you are happy with binary for the calculation, but you just want to print things out in a slightly friendlier format, try java.util.Formatter or String.format. In the format string specify a precision less than the full precision of a double. To 10 significant figures, say, 11.399999999999 is 11.4, so the result will be almost as accurate and more human-readable in cases where the binary result is very close to a value requiring only a few decimal places.

The precision to specify depends a bit on how much maths you've done with your numbers - in general the more you do, the more error will accumulate, but some algorithms accumulate it much faster than others (they're called "unstable" as opposed to "stable" with respect to rounding errors). If all you're doing is adding a few values, then I'd guess that dropping just one decimal place of precision will sort things out. Experiment.

Folksy

No, do not use double with monetary values! You need precision with money, use BigDecimal instead. Otherwise, your answer is good. Anything you need precision with, use BigDecimal, if precision isn't that important, you can use float or double. – Threatt

The question no longer states or implies that money is involved. I specifically say to use BigDecimal or integers for money. What's the problem? – Folksy

And equal to "don't use double for money" is "don't use BigDecimal or double for thirds". But sometimes a problem involves division, in which cases all bases not divisible by all prime factors of all denominators are about equally bad. – Folksy

.9999 = 1 if your precision is less than 4 significant digits – Beaudry

Answer 5

You may want to look into using java's java.math.BigDecimal class if you really need precision math. Here is a good article from Oracle/Sun on the case for BigDecimal. While you can never represent 1/3 as someone mentioned, you can have the power to decide exactly how precise you want the result to be. setScale() is your friend.. :)

Ok, because I have way too much time on my hands at the moment here is a code example that relates to your question:

import java.math.BigDecimal;
/**
 * Created by a wonderful programmer known as:
 * Vincent Stoessel
 * [email protected]
 * on Mar 17, 2010 at  11:05:16 PM
 */
public class BigUp {

    public static void main(String[] args) {
        BigDecimal first, second, result ;
        first = new BigDecimal("33.33333333333333")  ;
        second = new BigDecimal("100") ;
        result = first.divide(second);
        System.out.println("result is " + result);
       //will print : result is 0.3333333333333333


    }
}

and to plug my new favorite language, Groovy, here is a neater example of the same thing:

import java.math.BigDecimal

def  first =   new BigDecimal("33.33333333333333")
def second = new BigDecimal("100")


println "result is " + first/second   // will print: result is 0.33333333333333

Retaretable

Answer 6

You can't, because 7.3 doesn't have a finite representation in binary. The closest you can get is 2054767329987789/2**48 = 7.3+1/1407374883553280.

Take a look at http://docs.python.org/tutorial/floatingpoint.html for a further explanation. (It's on the Python website, but Java and C++ have the same "problem".)

The solution depends on what exactly your problem is:

• If it's that you just don't like seeing all those noise digits, then fix your string formatting. Don't display more than 15 significant digits (or 7 for float).
• If it's that the inexactness of your numbers is breaking things like "if" statements, then you should write if (abs(x - 7.3) < TOLERANCE) instead of if (x == 7.3).
• If you're working with money, then what you probably really want is decimal fixed point. Store an integer number of cents or whatever the smallest unit of your currency is.
• (VERY UNLIKELY) If you need more than 53 significant bits (15-16 significant digits) of precision, then use a high-precision floating-point type, like BigDecimal.

Poindexter

7.3 may not have a finite representation in binary, but I sure do get -7.3 when I try the same thing out in C++ – Isopod

wrongusername: No, you don't. It just displays that way. Use "%.17g" format (or better yet, "%.51g") to see the real answer. – Poindexter

Answer 7

Pretty sure you could've made that into a three line example. :)

If you want exact precision, use BigDecimal. Otherwise, you can use ints multiplied by 10 ^ whatever precision you want.

Raby

Answer 8

As others have noted, not all decimal values can be represented as binary since decimal is based on powers of 10 and binary is based on powers of two.

If precision matters, use BigDecimal, but if you just want friendly output:

System.out.printf("%.2f\n", total);

Will give you:

11.40

Brandnew

Answer 9

You're running up against the precision limitation of type double.

Java.Math has some arbitrary-precision arithmetic facilities.

Pusan

... such as the java.math package. java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html – Junkojunkyard

Answer 10

private void getRound() {
    // this is very simple and interesting 
    double a = 5, b = 3, c;
    c = a / b;
    System.out.println(" round  val is " + c);

    //  round  val is  :  1.6666666666666667
    // if you want to only two precision point with double we 
            //  can use formate option in String 
           // which takes 2 parameters one is formte specifier which 
           // shows dicimal places another double value 
    String s = String.format("%.2f", c);
    double val = Double.parseDouble(s);
    System.out.println(" val is :" + val);
    // now out put will be : val is :1.67
}

Food

Answer 11

        /*
        0.8                     1.2
        0.7                     1.3
        0.7000000000000002      2.3
        0.7999999999999998      4.2
        */
        double adjust = fToInt + 1.0 - orgV;
        
        // The following two lines works for me. 
        String s = String.format("%.2f", adjust);
        double val = Double.parseDouble(s);

        System.out.println(val); // output: 0.8, 0.7, 0.7, 0.8

Thad

Answer 12

Use java.math.BigDecimal

Doubles are binary fractions internally, so they sometimes cannot represent decimal fractions to the exact decimal.

Standardbearer

-1 for blindly recommending BigDecimal. If you don't actually need decimal arithmetic (i.e., if you're doing calculations with money), then BigDecimal doesn't help you. It doesn't solve all of your floating-point errors: You still have to deal with 1/3*3=0.9999999999999999999999999999 and sqrt(2)**2=1.999999999999999999999999999. Furthermore, BigDecimal carries a huge speed penalty. Worse, because of Java's lack of operator overloading, you have to rewrite all of your code. – Poindexter

@Poindexter - If you do calculation with money why use floating representation knowing the inherent error in it.... Since there are no fraction of cents you can use decimal and calculate cents instead of using approximate dollar you have exact cent amount. If you really want the fraction of cent use a a long and calculate thousands of cents. Further more the OP made no mention of irrational numbers, all he was concerned about was addition. Do read the post carefully and understand the problem before you answer, might save you some embarrassment. – Map

@Newtopian: I have nothing to be embarrassed about. The OP made NO mention of money, nor any indication that his problem has any inherent decimalness. – Poindexter

@ dan04 - No the OP did not... YOU did And Blindly offered out of context opinion to what most likely was a perfectly acceptable answer given the poor amount of details provided – Map

Answer 13

Doubles are approximations of the decimal numbers in your Java source. You're seeing the consequence of the mismatch between the double (which is a binary-coded value) and your source (which is decimal-coded).

Java's producing the closest binary approximation. You can use the java.text.DecimalFormat to display a better-looking decimal value.

Mobley

Answer 14

Short answer: Always use BigDecimal and make sure you are using the constructor with String argument, not the double one.

Back to your example, the following code will print 11.4, as you wish.

public class doublePrecision {
    public static void main(String[] args) {
      BigDecimal total = new BigDecimal("0");
      total = total.add(new BigDecimal("5.6"));
      total = total.add(new BigDecimal("5.8"));
      System.out.println(total);
    }
}

Fronniah

Answer 15

Multiply everything by 100 and store it in a long as cents.

Chopin

@Brandnew - look at the post before the last edit - all that "shoppingTotal" and "calcGST" and "calcPST" stuff looks like money to me. – Chopin

Answer 16

Computers store numbers in binary and can't actually represent numbers such as 33.333333333 or 100.0 exactly. This is one of the tricky things about using doubles. You will have to just round the answer before showing it to a user. Luckily in most applications, you don't need that many decimal places anyhow.

Anton

I am doing some odds calculations I would prefer to have the highest precision possible. But I understand there are limitations – Deuced

Answer 17

Floating point numbers differ from real numbers in that for any given floating point number there is a next higher floating point number. Same as integers. There's no integer between 1 and 2.

There's no way to represent 1/3 as a float. There's a float below it and there's a float above it, and there's a certain distance between them. And 1/3 is in that space.

Apfloat for Java claims to work with arbitrary precision floating point numbers, but I've never used it. Probably worth a look. http://www.apfloat.org/apfloat_java/

A similar question was asked here before Java floating point high precision library

Cooncan

Answer 18

Use a BigDecimal. It even lets you specify rounding rules (like ROUND_HALF_EVEN, which will minimize statistical error by rounding to the even neighbor if both are the same distance; i.e. both 1.5 and 2.5 round to 2).

Phenology

Answer 19

Why not use the round() method from Math class?

// The number of 0s determines how many digits you want after the floating point
// (here one digit)
total = (double)Math.round(total * 10) / 10;
System.out.println(total); // prints 11.4

Apophysis

Answer 20

Check out BigDecimal, it handles problems dealing with floating point arithmetic like that.

The new call would look like this:

term[number].coefficient.add(co);

Use setScale() to set the number of decimal place precision to be used.

Lording

Answer 21

If you have no choice other than using double values, can use the below code.

public static double sumDouble(double value1, double value2) {
    double sum = 0.0;
    String value1Str = Double.toString(value1);
    int decimalIndex = value1Str.indexOf(".");
    int value1Precision = 0;
    if (decimalIndex != -1) {
        value1Precision = (value1Str.length() - 1) - decimalIndex;
    }

    String value2Str = Double.toString(value2);
    decimalIndex = value2Str.indexOf(".");
    int value2Precision = 0;
    if (decimalIndex != -1) {
        value2Precision = (value2Str.length() - 1) - decimalIndex;
    }

    int maxPrecision = value1Precision > value2Precision ? value1Precision : value2Precision;
    sum = value1 + value2;
    String s = String.format("%." + maxPrecision + "f", sum);
    sum = Double.parseDouble(s);
    return sum;
}

Brightman

Answer 22

You can Do the Following!

System.out.println(String.format("%.12f", total));

if you change the decimal value here %.12f

Sianna

Answer 23

So far I understand it as main goal to get correct double from wrong double.

Look for my solution how to get correct value from "approximate" wrong value - if it is real floating point it rounds last digit - counted from all digits - counting before dot and try to keep max possible digits after dot - hope that it is enough precision for most cases:

public static double roundError(double value) {
    BigDecimal valueBigDecimal = new BigDecimal(Double.toString(value));
    String valueString = valueBigDecimal.toPlainString();
    if (!valueString.contains(".")) return value;
    String[] valueArray = valueString.split("[.]");
    int places = 16;
    places -= valueArray[0].length();
    if ("56789".contains("" + valueArray[0].charAt(valueArray[0].length() - 1))) places--;
    //System.out.println("Rounding " + value + "(" + valueString + ") to " + places + " places");
    return valueBigDecimal.setScale(places, RoundingMode.HALF_UP).doubleValue();
}

I know it is long code, sure not best, maybe someone can fix it to be more elegant. Anyway it is working, see examples:

roundError(5.6+5.8) = 11.399999999999999 = 11.4
roundError(0.4-0.3) = 0.10000000000000003 = 0.1
roundError(37235.137567000005) = 37235.137567
roundError(1/3) 0.3333333333333333 = 0.333333333333333
roundError(3723513756.7000005) = 3.7235137567E9 (3723513756.7)
roundError(3723513756123.7000005) = 3.7235137561237E12 (3723513756123.7)
roundError(372351375612.7000005) = 3.723513756127E11 (372351375612.7)
roundError(1.7976931348623157) = 1.797693134862316

Swanky

Answer 24

Do not waste your efford using BigDecimal. In 99.99999% cases you don't need it. java double type is of cource approximate but in almost all cases, it is sufficiently precise. Mind that your have an error at 14th significant digit. This is really negligible!

To get nice output use:

System.out.printf("%.2f\n", total);

Aldosterone

I think he is worried by the output, not the numerical precision. and BigDecimal would be no help if you eg. divide by three. It can even make things worse... – Aldosterone

You should never never never use floating-point for money. I've seen major rework enforced on a contractor who broke this rule despite being so instructed. – Goldin