Binary floating-point numbers cannot precisely represent base-10 decimals like $0.10. NEVER store financial transactions in double or float. Always use java.math.BigDecimal or store integer cents (e.g. long cents = 199;).
📋 Copy Java Precision Math & Safe Arithmetic Template
import java.math.BigDecimal;
import java.math.RoundingMode;
// Financial / Exact Currency Calculation
BigDecimal price = new BigDecimal("19.99");
BigDecimal taxRate = new BigDecimal("0.0825");
BigDecimal total = price.multiply(taxRate).setScale(2, RoundingMode.HALF_UP);
// Safe Modulo for Negative Numbers
int safeMod = Math.floorMod(-7, 4); // Returns 1 (unlike -7 % 4 which returns -3)
// Overflow-Safe Arithmetic (Throws ArithmeticException on overflow)
long safeSum = Math.addExact(2000000000L, 500000000L);
⚠️ 5 Fatal Traps & Engineering Pitfalls
Trap #1: The new BigDecimal(double) Inexact Constructor Trap
Instantiating new BigDecimal(0.1) does NOT create an exact 0.1; it creates 0.1000000000000000055511151231257827021181583404541015625 because 0.1 cannot be represented precisely in binary float. Always use new BigDecimal("0.1") or BigDecimal.valueOf(0.1).
In Java, the % operator is a remainder operator based on truncated division, meaning -7 % 4 evaluates to -3 rather than 1. When calculating array wrap-around or cyclic clock positions, always use Math.floorMod(-7, 4).
Trap #3: The Math.abs(Integer.MIN_VALUE) Trap
Due to two's complement binary representation, the negative range is 1 greater than the positive range. Math.abs(-2147483648) returns -2147483648, completely failing to make the number positive! Always handle Integer.MIN_VALUE before calling absolute value.
Trap #4: Silent Floating-Point NaN and Infinity Propagation
In double arithmetic, dividing 0.0 / 0.0 yields Double.NaN, and 1.0 / 0.0 yields Double.POSITIVE_INFINITY without raising an exception. Any further math with NaN produces NaN, silently poisoning entire physics simulation states.
Writing short s = 5; s += 10.5; compiles without warnings because compound assignment inserts an invisible cast: s = (short)(s + 10.5). This silently truncates floating-point numbers and discards high-order bits without developer awareness.
💬 Frequently Asked Questions
Why should floating-point double and float never be used for financial transactions in Java?
IEEE 754 binary floating-point numbers cannot represent simple base-10 decimal fractions like 0.10 or 0.05 exactly. Cumulative rounding errors cause bank accounts to drift by pennies. Always use java.math.BigDecimal or store monetary values as whole cents in a long.
How does Math.floorMod() differ from the standard % remainder operator?
The % operator rounds division toward zero (truncated division), producing negative results for negative dividends (-7 % 4 = -3). Math.floorMod() rounds division toward negative infinity (floored division), guaranteeing results match the divisor sign (Math.floorMod(-7, 4) = 1).
Why does Math.abs(Integer.MIN_VALUE) fail to return a positive integer?
32-bit signed integers range from -2,147,483,648 to +2,147,483,647. Because +2,147,483,648 does not exist in 32-bit two's complement, attempting to negate Integer.MIN_VALUE overflows back to itself.
What is the difference between float and double precision in memory?
A float occupies 32 bits (1 sign, 8 exponent, 23 mantissa) providing ~7 decimal digits of precision. A double occupies 64 bits (1 sign, 11 exponent, 52 mantissa) providing ~15 to 17 decimal digits of precision.
How do Math.addExact() and Math.multiplyExact() prevent silent arithmetic overflows?
Unlike the standard + and * operators which silently wrap around upon exceeding bit limits, Math.addExact() checks CPU overflow flags and immediately throws an ArithmeticException, preventing data corruption.