IEEE 754

IEEE 754 is the standard for floating-point arithmetic, first published in 1985 and updated in 2008 and 2019. Defines binary and decimal floating-point formats, rounding behaviour, exception handling, and the special values (NaN, ±Infinity, −0).

The standard double-precision format is what JavaScript Numbers, Python floats, and most other “number” types in modern languages use:

• 64 bits total
• 1 bit sign
• 11 bit exponent
• 52 bit mantissa
• ~15-17 significant decimal digits of precision
• Range roughly 4.9e−324 to 1.8e+308

The famous example: 0.1 + 0.2 === 0.3 returns false in nearly every language. The reason: 0.1 and 0.2 don’t have exact binary representations (just like 1/3 has no exact decimal representation). Their stored values are very close to but not exactly 0.1 and 0.2, and the sum compounds the tiny error. The result is 0.30000000000000004.

Implications for our tools: most conversions are accurate to ~15 decimal digits, which is more than any input we accept. Where this matters: cryptocurrency amounts, where 18-decimal Wei exceeds the Number range — we use BigInt there to keep precision exact.

Worked example

Consider the calculation 0.1 + 0.2 in JavaScript. The literal 0.1 in IEEE 754 binary is actually 0.10000000000000000555111512312578… (the closest representable double). 0.2 is 0.20000000000000001110223024625157…. Adding them and rounding to the nearest representable double gives 0.30000000000000004440892098500626…, displayed as 0.30000000000000004. The true mathematical answer 0.3 is not exactly representable in binary — its representation is also approximately 0.299999…9989…. The error is in the last ulp (unit in the last place), about 1 in 10¹⁶. For visible numbers it’s invisible; for sums of millions of small values, it accumulates: summing 0.1 a hundred times in a loop and comparing to 10.0 will return false (the result is 9.99999999999999822364…). Use Kahan summation or compensated summation when accuracy matters in long accumulations.

Two further special-value gotchas worth knowing: subnormal numbers (very small values near zero with reduced precision) trade off representable range for graceful underflow, and signaling NaNs (sNaN) can be used to trap on uninitialised memory, though most languages map all NaNs to quiet NaNs (qNaN) and never expose this distinction to user code.

When and why it matters

IEEE 754 matters whenever code compares floats for equality, sums many small numbers, or handles values near the format’s limits. The classic financial bug is computing “total = total + 0.01” in a loop a million times and discovering the result is slightly off by enough to fail a balance-sheet reconciliation. The fix is to never use floats for money — use BigDecimal, Python’s decimal.Decimal, JavaScript’s decimal.js, or store amounts as integers (cents instead of dollars, satoshis instead of bitcoin, wei instead of ETH). The other classic bug is the catastrophic cancellation that occurs when subtracting two near-equal floats — the leading significant digits cancel, leaving only the noise in the lower bits. Numerical-analysis textbooks devote entire chapters to algorithms (e.g., the stable variance formula, Kahan summation, Welford’s online algorithm) that avoid this trap. Reference: Goldberg D. — What Every Computer Scientist Should Know About Floating-Point Arithmetic.

The five special values everyone forgets about: IEEE 754 defines +0 and −0 as distinct (they compare equal but produce different results in division — 1/+0 is +∞ while 1/−0 is −∞), +Infinity and −Infinity for overflow, and NaN (Not a Number) for undefined operations like 0/0 or √−1. NaN is famously unequal to itself — NaN === NaN is false — which is how IEEE 754 propagates errors through computation rather than masking them. The Number.isNaN() check exists in every modern language precisely because the obvious equality check doesn’t work.

When you genuinely need exact decimal — and what to use instead: for money, never use floats. Java’s BigDecimal, Python’s decimal.Decimal, JavaScript’s libraries like decimal.js, and PostgreSQL’s NUMERIC type all implement exact decimal arithmetic. The cost is roughly 10-100× slower than native float operations, which is fine for any user-facing transaction system. For scientific computing where rounding behaviour matters, IEEE 754’s round-to-nearest-even (banker’s rounding) is what produces stable accumulated sums; round-half-up biases upward. Most languages default to round-half-even for this reason. Reference: IEEE 754-2019 — Floating-Point Arithmetic.