Back to Predict the Output
Q3Question 3 of 10

Predict the output: 0.1 + 0.2 == 0.3

Key Concepts
  • Output: false – 0.1 + 0.2 = 0.30000000000000004 in IEEE 754
  • double cannot represent 0.1 exactly in binary
  • Never use == for floating-point comparison – use Math.abs(a-b) < epsilon or BigDecimal
  • For money: always BigDecimal with String constructor
  • Understanding this concept is essential for Java interviews at senior level

Definition

false. 0.1 + 0.2 in double is 0.30000000000000004, not exactly 0.3. IEEE 754 cannot represent 0.1 exactly in binary.

The issue:

  • 0.1 in binary is a repeating fraction (like 1/3 in decimal).
  • 0.1 + 0.2 gives 0.30000000000000004 due to floating-point rounding.
  • 0.30000000000000004 == 0.3 is false.

Trying to express 1/3 exactly in decimal gives 0.333333... with rounding. Same issue: 0.1 in binary is a repeating fraction with rounding.

Understanding the Concepts

The code

JAVA
System.out.println(0.1 + 0.2 == 0.3);
System.out.println(0.1 + 0.2);

Output

TEXT
false
0.30000000000000004

How to compare doubles correctly

JAVA
// Epsilon comparison
double a = 0.1 + 0.2;
double b = 0.3;
boolean close = Math.abs(a - b) < 1e-9;  // true

// For money: BigDecimal
BigDecimal x = new BigDecimal("0.1").add(new BigDecimal("0.2"));
BigDecimal y = new BigDecimal("0.3");
System.out.println(x.compareTo(y) == 0);  // true (exact)

What are common mistakes?

A common mistake is assuming the output without tracing through the code step by step.

Wrong approach:

JAVA
package com.bank.quiz;

public class OutputQuiz {
    public static void main(String[] args) {
        // Developers often guess the wrong output
        // because they skip the step-by-step evaluation
        String result = "Balance: " + 100 + 50;
        System.out.println(result);
        // Many guess: "Balance: 150"
        // Actual: "Balance: 10050" (left-to-right string concat)
    }
}

Correct reasoning:

JAVA
package com.bank.quiz;

public class OutputQuiz {
    public static void main(String[] args) {
        // Step 1: "Balance: " + 100 = "Balance: 100" (String + int = String)
        // Step 2: "Balance: 100" + 50 = "Balance: 10050" (String + int = String)
        String result = "Balance: " + 100 + 50;
        System.out.println(result);  // Balance: 10050

        // To get arithmetic: use parentheses
        String correct = "Balance: " + (100 + 50);
        System.out.println(correct);  // Balance: 150
    }
}

Always trace left to right and remember that once a String is involved in concatenation, everything after it becomes string concatenation too.

What should a senior engineer know?

A senior engineer working on banking systems should understand the production implications of this concept.

  • Performance impact. Measure with JMH before making assumptions about which approach is faster.
  • Thread safety. In a multi-threaded banking service processing concurrent transactions, always consider whether the approach is thread-safe.
  • Memory footprint. Use JFR and VisualVM to measure actual memory usage under realistic banking workloads.
  • Monitoring. Set up JMX metrics and alerts for production banking applications.
JAVA
package com.bank.monitoring;

import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;

public class MemoryMonitor {
    public static void printMemoryUsage() {
        MemoryMXBean mem = ManagementFactory.getMemoryMXBean();
        System.out.println("Heap: " + mem.getHeapMemoryUsage());
        System.out.println("Non-Heap: " + mem.getNonHeapMemoryUsage());
    }
}

What are the edge cases?

Edge cases can cause unexpected behavior in banking applications. Here are some to watch for.

JAVA
package com.bank.edge;

public class EdgeCaseDemo {
    public static void main(String[] args) {
        // Edge case 1: null handling
        String accountId = null;
        try {
            System.out.println(accountId.length());
        } catch (NullPointerException e) {
            System.out.println("Null account ID");
        }

        // Edge case 2: empty vs null
        String emptyId = "";
        System.out.println(emptyId.isEmpty());  // true
        System.out.println(emptyId == null);     // false

        // Edge case 3: boundary values
        java.math.BigDecimal zero = java.math.BigDecimal.ZERO;
        java.math.BigDecimal negativeBalance = new java.math.BigDecimal("-0.01");
        System.out.println(zero.compareTo(negativeBalance) > 0);  // true
    }
}
TEXT
Null account ID
true
false
true

Always test with null values, empty strings, boundary values, and negative amounts in banking applications.

What are common interview follow-up questions?

Interviewers often follow up with these related questions:

  • How does this concept apply to a high-throughput banking transaction system?
  • What are the performance implications in a production environment?
  • How would you debug issues related to this concept?
  • What tools would you use to monitor this in production?
  • How does this behave differently in Java 8 vs Java 17+?

When answering follow-up questions, always relate your answer back to practical experience. For example, at National Bank of India, Rajesh debugged a production issue related to this concept by using JFR recordings and heap dumps. Providing concrete examples from banking systems shows the interviewer that you understand both the theory and the practice.

Visual Overview

DIAGRAM
  0.1 in binary: 0.000110011001100110011... (repeating)
  0.1 + 0.2 = 0.30000000000000004 (rounding error)
  0.30000000000000004 == 0.3 → false

  Fix: Math.abs(a-b) < epsilon  or  BigDecimal

Key Takeaway

0.1 + 0.2 == 0.3 is false because IEEE 754 cannot represent 0.1 exactly in binary. Never use == for floating-point comparison. Use epsilon comparison or BigDecimal for exact money arithmetic.

One sentence to remember: 0.1 + 0.2 is not exactly 0.3 in double – use BigDecimal for money.

---

Share
Use ← → arrow keys to navigate