A financial system stores prices as Java double. A tester runs 10,000 tax calculations sequentially. Why is the CUMULATIVE result more suspicious than any single result?

• Running 10,000 calculations changes the CPU floating-point mode, making later results less precise than earlier ones — a common assumption, but the actual mechanism works differently at the implementation level
• Java's garbage collector introduces rounding during double object reallocation in long-running loops
• Floating-point errors are small per operation but compound across thousands of additions, potentially reaching cents-level discrepancies
• The result is no more suspicious than any single result — floating-point precision does not worsen with repetition

What is the CORRECT way to compare two double values for equality in financial code?

• if (a == b) — Java's == operator uses bitwise comparison which is always accurate for double types
• Math.abs(a - b) < EPSILON where EPSILON is a small tolerance like 0.000001 — or use BigDecimal for exact comparison
• a.equals(b) — Java's equals() method for Double objects handles floating-point imprecision automatically
• Convert both values to String and use a.toString().equals(b.toString()) — string comparison avoids float comparison issues

A tester calculates: 19.99 × 0.15 (15% VAT). The expected result is $2.9985, stored as $3.00 (rounded). The system stores $2.9984999999999997. What should happen?

• Accept it — $2.9984999999999997 rounds to $3.00, so the final stored value would be correct after display formatting
• Reject it as a major bug — any deviation from the expected value in financial calculations is unacceptable
• The tester made an error — $2.9985 rounded to 2 decimal places is $2.99, not $3.00, so the rounding spec should be re-checked
• File a bug: the system stores the raw unrounded float value instead of applying rounding before persistence

Which data type should be used for ALL monetary values in a Java backend to guarantee exact arithmetic?

• float — single precision is sufficient for monetary values up to $999,999.99 and faster than double
• double — 64 bits provides enough precision for financial calculations in the vast majority of real-world cases
• BigDecimal or long integer cents throughout — never mixing floating-point types into the calculation chain
• long (storing raw cents) combined with double for intermediate percentage calculations