Why do we bias the exponent of a floating-point number?

so.very.tired picture so.very.tired · Nov 8, 2013 · Viewed 7.5k times · Source

I'm trying to wrap my head around this floating point representation of binary numbers, but I couldn't find, no matter where I looked, a good answer to the question.

Why is the exponent biased?

What's wrong with the good old reliable two's complement method?

I tried to look at the Wikipedia's article regarding the topic, but all it says is: "the usual representation for signed values, would make comparison harder."

Answer

Mark Dickinson picture Mark Dickinson · Nov 8, 2013

The IEEE 754 encodings have a convenient property that an order comparison can be performed between two positive non-NaN numbers by simply comparing the corresponding bit strings lexicographically, or equivalently, by interpreting those bit strings as unsigned integers and comparing those integers. This works across the entire floating-point range from +0.0 to +Infinity (and then it's a simple matter to extend the comparison to take sign into account). Thus for example in IEEE 754 binary 64 format, 1.1 is encoded as the bit string (msb first)

0011111111110001100110011001100110011001100110011001100110011010

while 0.01 is encoded as the bit string

0011111110000100011110101110000101000111101011100001010001111011

which occurs lexicographically before the bit string for 1.1.

For this to work, numbers with smaller exponents need to compare before numbers with larger exponents. A biased exponent makes that work, while an exponent represented in two's complement would make the comparison more involved. I believe this is what the Wikipedia comment applies to.

Another observation is that with the chosen encoding, the floating-point number +0.0 is encoded as a bit string consisting entirely of zeros.