IEEE 754 Converter

How the three fields combine

An IEEE 754 float is three fields packed into one bit pattern: a sign bit, a biased exponent, and a mantissa (the fractional part of the significand). The value is (-1)^sign × 1.mantissa × 2^(exponent - bias) for a normal number — the "1." is an implicit leading bit that is never stored, because a normalised binary significand is always between 1 and 2. The bias (127 for binary32, 1023 for binary64) lets the exponent field represent negative powers of two using only unsigned bits.

What the implicit leading bit is, and why subnormals don't have it

The implicit "1." only holds while the exponent field is non-zero. When the exponent field is all zeros, the format switches to subnormal representation: the implicit leading bit becomes 0 instead of 1, and the exponent is fixed at its minimum rather than continuing to decrease. This fills the gap between the smallest normal number and zero with reduced precision instead of an abrupt jump to zero — and it is the single most commonly mis-implemented part of the spec, because the switch is easy to miss if you only test normal numbers.

What ULP means

A unit in the last place (ULP) is the gap between one representable float and the next one up, at a given magnitude — it grows as the exponent grows, because the mantissa always has the same number of bits regardless of how large the value is. This is why floating-point precision is described as relative rather than absolute: two numbers a billion apart in magnitude can both be exact to the same number of significant digits, but the absolute gap between adjacent representable values at the larger magnitude is far bigger.

The 0.1 + 0.2 walkthrough, end to end

0.1 and 0.2 both have infinite binary expansions, so each is rounded to the nearest binary64 double when typed. Those two doubles are not exactly 0.1 and 0.2 — they're the closest representable values, each off by a tiny amount. Adding them produces the double nearest to their (slightly-off) true sum, which lands a hair above the double that 0.3 rounds to on its own. The mismatch isn't a bug in addition; it's two independent rounding errors that happen not to cancel out. The demonstrator above shows the exact stored value of each operand and of the sum, so the gap is visible rather than asserted.

When to use bfloat16 and when binary16

binary16 (IEEE half precision) trades range for precision: 10 mantissa bits give more significant digits, but only 5 exponent bits limit the representable magnitude, which is fine for graphics and audio but risks overflow in neural network training, where activations and gradients can span many orders of magnitude. bfloat16 trades back: 7 mantissa bits (less precision) for 8 exponent bits — exactly matching binary32's range — which is why it's become the default for training many models on hardware that supports it. Both are 16 bits; a value read as the wrong one isn't a rounding difference, it's a different number entirely.

Common use cases

• Debugging a floating-point comparison bug by seeing the exact stored value on both sides
• Understanding why a sum, difference or comparison didn't come out as expected
• Checking whether a quantised model weight (bfloat16 or float16) round-trips as intended
• Learning the IEEE 754 field layout by flipping individual bits and watching the value change
• Converting a hex dump of a register or file format back to a readable decimal value