4.5.4.7–4.5.4.9 - Floating-point range, normalisation and limits

Range and precision trade-offs

Range describes how large or small a representable value can be, while precision describes how finely values can be distinguished.

In fixed point, every bit has the same weight for every stored number. For ten signed bits with five fractional bits, spacing is $2^{-5}=0.03125$ throughout the range $-16$ to 15.96875. Adding fractional positions improves that spacing but reduces the space for integer magnitudes. Fixed point therefore offers constant absolute resolution for values that fit.

In floating point, the mantissa supplies significant digits and the exponent scales them. More mantissa bits improve precision; more exponent bits extend the available scales. With a fixed total allocation, giving a bit to one field takes it from the other. A wider exponent does not by itself give more significant digits.

Consider a simplified ten-bit format with a six-bit two's-complement mantissa, point after the sign bit, and a four-bit two's-complement integer exponent. The mantissa's step is $1/32$, and the exponent covers $-8$ to 7. At exponent 1, adjacent mantissas give a value spacing of $(1/32)\times2=0.0625$. At exponent 4, the spacing is $(1/32)\times16=0.5$. Floating point does not provide constant absolute spacing: values of larger magnitude have coarser gaps for a given significant-bit allocation.

The largest positive mantissa is $0.11111_2=31/32$. With exponent 7, the largest positive value is $(31/32)\times128=124$. The most-negative mantissa is $-1$, so the most-negative value is $-1\times128=-128$. Compared with the ten-bit fixed-point example, floating point stores much larger magnitudes using the same total number of bits. The exact lower nonzero limit also depends on whether the format requires normalisation, taught below.

Comparing representations and calculation

Choosing a representation requires the needed magnitudes, tolerated error and calculation environment to be considered together.

Fixed point suits a known bounded interval with a required absolute resolution. A controller might need readings between $-10$ and $+10$ at steps of no more than 0.03125. The ten-bit/five-fractional-bit format above meets both limits. Its scale is known in advance, and addition of values with that same scale can use integer addition on their encodings. Multiplication still needs rescaling and range checks; it is not automatically exact or safe.

Floating point suits values spanning widely different magnitudes. A simulation may need both 0.002 and 100, which the ten-bit fixed-point example cannot cover accurately. The floating format covers small scales as well as large magnitudes, but it may approximate either input, and its absolute gap near 100 is much larger than near 0.002. Range and exactness are separate requirements.

Floating-point addition must bring operands to a common exponent before their mantissas can be added. Significant low bits can be lost during that alignment. A result may then need rounding and normalisation. Fixed-point addition with a common scale does not need exponent alignment. These extra floating steps mean fixed-point arithmetic can be simpler and faster in a suitable implementation, particularly without floating-point hardware. Actual speed depends on processor hardware and operations; floating point is not universally slower on every modern processor.

Normalising positive and negative mantissas

Normalisation removes redundant leading sign bits so the available mantissa positions retain as many significant digits as the format permits.

In this simplified two's-complement format, a nonzero positive normalised mantissa starts 01, while a negative normalised mantissa starts 10. The sign bit and the next bit differ. Positive values then use $1/2\le m<1$; negative values use $-1\le m<-1/2$. Zero is a special case: it cannot acquire the usual differing first two bits by shifting zeros.

For a mantissa with redundant leading 00 or 11, shift it left one place, retaining the allocated width, and append zero on the right. Each such shift doubles the mantissa's value, so decrease the exponent by one to preserve the represented number:

For six mantissa bits and four exponent bits, the positive fields 000110 and 0100 represent $0.1875\times16=3$. Shifting once gives 001100 and 0011: $0.375\times8=3$. A second shift gives 011000 and 0010: $0.75\times4=3$. The prefix is now 01, so the representation is normalised. The original had two unused significant positions occupied by redundant sign bits.

The negative fields 111010 and 0100 represent $-0.1875\times16=-3$. One left shift gives 110100 and 0011: $-0.375\times8=-3$. A second gives 101000 and 0010: $-0.75\times4=-3$. The prefix is now 10. Testing for a leading 1 alone would stop too early: all three negative mantissas have that sign bit, but only the last is normalised.

The boundary $-0.5$ illustrates the asymmetry. Its six-bit mantissa is 110000, which starts 11. Normalise it as 100000 ($-1$) and decrease the exponent by one. Negatives in two's complement must be checked using their signed value, not by applying the positive 01 rule or treating their lower bits as a magnitude.

Normalisation changes the fields, not the represented value. It also gives a consistent unique encoding for each nonzero representable value under this convention, making equality comparisons simpler than when several mantissa/exponent pairs encode the same value. It cannot recover significant digits already discarded by rounding, and the adjusted exponent must still fit its own field. All shifts above preserve the value exactly because they remove redundant sign bits without losing required significant bits.

Underflow and overflow

Finite exponent and mantissa fields limit both the largest magnitudes and the smallest nonzero magnitudes that a format can store.

Overflow occurs when a value or calculation result has too large a magnitude to fit the available representation. In the normalised six-bit mantissa/four-bit exponent format above, the largest positive value is 124 and the most-negative is $-128$. A positive result of 130 is out of range; simply retaining field bits cannot preserve that result.

Underflow occurs when a nonzero value or calculation result has a magnitude too small for the available nonzero representation. Assume that this format requires all nonzero values to be normalised. Its smallest positive mantissa is 010000, or 0.5, and its smallest exponent is 1000, or $-8$. The smallest positive value is therefore $0.5\times2^{-8}=2^{-9}=1/512=0.001953125$.

A positive result $2^{-10}=0.0009765625$ would need normalised mantissa 0.5 with exponent $-9$, outside the four-bit exponent range. That is underflow in the stated normalised format. If a different format permits unnormalised values at the lowest exponent, its nonzero limit may differ. Never silently add such a rule to a question that requires normalised values.

Underflow may cause a system to round a very small value to zero or report a condition; overflow may cause an error or a special result. The simplified representation alone does not prescribe those implementation behaviours. Diagnose the representability failure the task supplies. IEEE-specific behaviours and special bit encodings are outside this specification.

A value can be in range but inexact. For example, 10.1 is between the limits but may lie between adjacent representable values. That is a precision/rounding issue, rather than overflow. Likewise, an exactly representable operand does not guarantee a representable calculation result: multiplication can create a value above the maximum or below the smallest nonzero magnitude.