Floating-point arithmetic

What it is and why it exists

Binary floating-point represents a finite number with a sign, a fixed-width significand, and a power-of-two exponent. It resembles scientific notation, but its digits are binary. A 64-bit format can therefore represent very small and very large magnitudes with roughly constant significant precision.

The format is an approximation system, not a store for arbitrary real numbers. Fractions whose reduced denominator contains factors other than two have repeating binary expansions. Decimal 0.1 is one example, so a runtime must select a nearby representable value when it converts that literal.

Arithmetic produces the same kind of choice. The mathematical result is computed conceptually, then rounded to a representable value. A sequence of individually small rounding decisions can make an expected equality fail, and changing the order of operations can change which information is lost.

Floating-point exists because fixed storage cannot encode every real number. Its design trades exactness for range, predictable hardware operations, and an error that usually scales with the value’s magnitude. That trade is well suited to measurements, graphics, simulations, statistics, and many machine-learning calculations.

You also meet floating-point where the domain did not choose it deliberately. JavaScript’s Number type uses the IEEE 754 binary64 value set for ordinary numeric values, so JSON data, browser APIs, and application formulas often inherit these semantics. The examples use Node 24 to make those rules directly runnable.

Approximation is not automatically a bug. A temperature sensor with resolution of 0.01 degrees already has physical uncertainty, and a much smaller representation error may be irrelevant. The engineering question is whether the representation and accumulated error fit a stated accuracy contract.

Some domains require different semantics. Account balances often use integer minor units or a decimal type with an explicit scale and rounding rule. Identifiers and counters need integer operations, while symbolic or rational computation may preserve exact relationships at a higher cost.

How it works

Finite encodings

IEEE 754 binary64, the format behind JavaScript Number, divides 64 bits into three fields. The fraction field contributes 52 stored bits, and normal values have an implicit leading 1, giving 53 bits of precision.

For a normal finite value, the fields describe (-1)^sign × (1.fraction) × 2^(exponent - 1023). This notation explains why moving to a larger exponent spreads adjacent representable values farther apart. The bit pattern does not carry a fixed number of decimal places.

Exponent patterns at the edges have special meanings. An all-zero exponent represents zero or a subnormal number, allowing values to approach zero gradually. An all-one exponent represents an infinity when the fraction is zero and a NaN when the fraction is nonzero.

Conversion and rounding

When source text such as 0.1 is parsed, the implementation chooses the binary64 value required by the language’s conversion rule. The stored value can be above or below the mathematical decimal value. Printing usually chooses a short decimal string that parses back to the same binary value, so the approximation may stay hidden.

Basic Number arithmetic rounds results to the nearest representable binary64 value, resolving an exact halfway case with an even low bit. This round-to-nearest, ties-to-even rule avoids a persistent upward or downward bias across many ties. It cannot prevent error when the exact result falls between representable values.

Each operation receives already-rounded operands. For 0.1 + 0.2, neither input is the exact decimal fraction, and the exact sum of their stored values needs another rounding. The final value is slightly above the binary64 value selected for the literal 0.3.

Rounding error is bounded relative to an ordinary result, but it is not a fixed decimal offset. Number.EPSILON is the gap between 1 and the next larger Number. Near 2, the gap is twice as large; near very small normal values, it is far smaller.

Precision, range, and spacing

Binary64 represents every integer from -2^53 + 1 through 2^53 - 1 exactly. Beyond that safe-integer range, some integers are skipped. Adding 1 to 2^53 produces no change because the next representable value is two units away.

Range and precision are separate limits. Number.MAX_VALUE is the largest finite Number; a result beyond the overflow boundary rounds to an infinity. Number.MIN_VALUE is the smallest positive subnormal value, and dividing it by two rounds to positive zero.

Subnormal numbers trade significant precision for gradual underflow. They fill the interval between the smallest normal magnitude and zero with evenly spaced values. An algorithm near that boundary can lose relative accuracy even before its result becomes zero.

Operations are not real-number algebra

Floating-point addition and multiplication are commutative for ordinary finite operands, apart from details involving NaN and signed zero. They are not generally associative. (a + b) + c can round at a different point from a + (b + c) and produce another value.

Subtraction between nearly equal values is especially risky. Leading significant digits cancel, leaving a result whose remaining digits came from lower-precision parts of the operands. This catastrophic cancellation does not make subtraction itself faulty; it reveals that earlier approximation now dominates the small difference.

Optimizers, vector libraries, databases, and parallel reductions may group operations differently. A numerically valid result may therefore vary in its last bits across execution plans or platforms. Reproducibility must be an explicit requirement with a defined algorithm, not an assumption derived from the same source expression.

Comparison contracts

Exact equality is appropriate when the contract promises the same representation. Examples include comparing a value with itself after excluding NaN, checking a parsed integer inside the safe range, or detecting an exact sentinel produced by the same operation. It is not a universal mistake.

Computed measurements often need a tolerance. An absolute tolerance protects comparisons near zero, while a relative tolerance scales with the operand magnitudes. A robust predicate commonly accepts a difference no larger than the greater of those two bounds.

The tolerances must come from the domain and the algorithm’s error budget. Copying Number.EPSILON compares only at the spacing near 1, while multiplying it by a large arbitrary constant merely hides the missing requirement. Units, sensor resolution, iteration count, and acceptable business error are better inputs.

Special values need policy before tolerance logic. NaN is unequal to every value under ===, including itself. Positive and negative zero compare equal with ===, although Object.is() distinguishes them and their reciprocals have opposite infinities.

Examples

The examples progress from representation and comparison to information loss and range boundaries. Every output shown below came from executing the file with Node v24.14.0.

Seeing the stored approximation

This tax calculation prints the familiar short representation, then asks for 17 significant decimal digits. The comparison helper combines a relative bound with an optional absolute floor and handles nonfinite values before subtracting them.

The exact comparison is false because the two expressions select adjacent binary64 values. toPrecision(17) exposes enough decimal digits to distinguish those values. It does not reveal the bits directly, but it makes the representation difference visible.

The 1e-12 relative tolerance is an example policy, not a universal constant. A production tax system should normally avoid binary floating-point for monetary amounts and define exact decimal rounding. The helper better fits approximate measurements whose accepted relative error is actually 1e-12.

Near zero, a relative tolerance alone shrinks toward zero and may reject harmless noise. Set absolute from the smallest meaningful magnitude in the domain. Nonfinite values bypass the subtraction because Infinity - Infinity would produce NaN and accidentally fail an intended exact-infinity policy.

Watching addition lose information

These adjustments have a mathematical total of 1. The same three values produce different results when the two large terms cancel before the small term is added.

const adjustments = [1e16, 1, -1e16];

function sum(values) {
  let total = 0;
  for (const value of values) total += value;
  return total;
}

const smallFirst = [...adjustments].sort(
  (left, right) => Math.abs(left) - Math.abs(right),
);
const cancelFirst = [adjustments[0], adjustments[2], adjustments[1]];

console.log(`input order: ${sum(adjustments)}`);
console.log(`small first: ${sum(smallFirst)}`);
console.log(`cancel first: ${sum(cancelFirst)}`);
console.log(`mathematical total: 1`);

input order: 0
small first: 0
cancel first: 1
mathematical total: 1

At magnitude 1e16, the gap between nearby binary64 values is larger than 1. Adding the small adjustment to either large value rounds it away. Sorting by increasing magnitude does not save it here because the next operation still combines the partial sum with 1e16.

The cancelFirst order forms an exact zero from the large opposite values, then adds 1. This is a demonstration, not a general instruction to search for canceling pairs. Pairwise summation, compensated summation, or a higher-precision representation should be chosen from the data’s scale and accuracy requirement.

Order sensitivity matters in batch and parallel work. Splitting a dataset into chunks changes the partial sums, and merging those partial sums introduces another rounding tree. Tests should state an error bound unless bit-for-bit reproducibility is a real interface promise.

Checking range and special values

This example crosses both ends of the positive range and then inspects special comparison behavior. Console formatting hides the sign of zero, so the code uses Object.is() and a reciprocal to expose it.

const overflowed = Number.MAX_VALUE * 2;
const underflowed = Number.MIN_VALUE / 2;
const invalidRatio = 0 / 0;
const signedZero = -1 / Infinity;

console.log(`overflow: ${overflowed}`);
console.log(`underflow: ${underflowed}`);
console.log(`invalid equals itself: ${invalidRatio === invalidRatio}`);
console.log(`invalid detected: ${Number.isNaN(invalidRatio)}`);
console.log(`finite overflow result: ${Number.isFinite(overflowed)}`);
console.log(`signed zero prints as: ${signedZero}`);
console.log(`signed zero preserved: ${Object.is(signedZero, -0)}`);
console.log(`reciprocal: ${1 / signedZero}`);

overflow: Infinity
underflow: 0
invalid equals itself: false
invalid detected: true
finite overflow result: false
signed zero prints as: 0
signed zero preserved: true
reciprocal: -Infinity

JavaScript floating-point overflow and invalid arithmetic do not necessarily throw. The values can travel through a calculation unless the input or result boundary rejects them. Use Number.isFinite() when an API accepts only ordinary finite measurements.

Number.isNaN() states the NaN check directly and does not coerce strings. The old value !== value idiom works because NaN is the only JavaScript value unequal to itself, but it hides intent. Prefer the named predicate in application validation.

Whether negative zero matters is domain-specific. It can encode an approach direction in numerical work, but many business domains want to normalize it before formatting, serialization, or hashing. Decide at that boundary rather than assuming the printed 0 proves the sign is gone.

Pitfalls

Treating decimal input as exact

Fix: choose integer minor units when the range and fixed scale allow them, or use a verified decimal implementation with an explicit scale and rounding mode. Parse and validate the decimal text at the boundary; converting it to binary floating-point first has already changed the representation.

Using one epsilon everywhere

Fix: derive a relative tolerance from the algorithm’s error and an absolute tolerance from domain resolution. Handle nonfinite values separately, document units, and test values near zero as well as at the largest expected magnitude.

Rounding by scaling without a decimal contract

Fix: state whether the requirement concerns display, storage, or settlement and name the midpoint rule. Use formatting for display only; use integer or decimal arithmetic for an exact decimal contract, with range checks before scaling.

Letting nonfinite results cross a boundary

Fix: validate finite inputs and outputs at domain boundaries with Number.isFinite(). Decide whether overflow should reject, saturate, or switch representations, and attach the operation and units to the reported error.

Assuming algebraic rearrangement is harmless

Fix: review intermediate magnitudes and conditioning before rearranging numeric code. Test adversarial scale mixtures, retain a stable algorithm when accuracy matters, and specify a tolerance or reproducibility requirement for the output.

Ignoring the integer precision boundary

Fix: require Number.isSafeInteger() for integer-valued Number inputs. Use BigInt, validated decimal text, or another integer representation when the domain can exceed the safe range, and avoid lossy round trips through Number.

Further reading

• ECMAScript specification: the Number type
• MDN Web Docs: Number.EPSILON
• MDN Web Docs: Number.isFinite()
• Oracle Numerical Computation Guide: What Every Computer Scientist Should Know About Floating-Point Arithmetic
• IEEE 754-2019 standard