# Why floating point representation uses a sign bit instead of 2's complement to indicate negative numbers

Consider a fixed point representation which can be regarded as a degenerate case of a floating number. It is entirely possible to use 2's complement for negative numbers. But why is a sign bit necessary for floating point numbers, shouldn't mantissa bits be using 2's complements?

Also why do the exponent bits use a bias instead of a signed-magnitude representation (similar to the mantissa bits) or 2's complement representation?

Update: Sorry if I didn't make it clear. I was looking for the reason of how floating point representation is shaped. If there is no strong implementation trade-off between the alternatives, then could someone explain the historical aspects of the floating point representation?

Two's complement makes sense when the two entities in question have the same "units" and the same "width". By width I mean that, say, if you're adding an N bit number and an M bit number, where N and M are different, then you better not use two's complement. For floating point numbers, we have the problem of units: if the exponents are different, then we are mentally shifting one of the mantissas, and now we're at the same problem as before (with the width).

As for the exponent bits, by using a bias instead of sign+magnitude we gain one more value (otherwise we'd have +0 and -0). Here two's-complement makes sense when multiplying or dividing numbers (since then we're adding or subtracting the exponents), but not as much sense when adding or subtracting.

Edit: A commenter remarked that you can add two's complement integers of different lengths using sign extension. There is also some problem with detecting overflow, but that's also fixable. In summary, you could probably use two's complement, if you're careful enough. (You also need to handle multiplication and division.)

• “if you're adding an N bit number and an M bit number, where N and M are different, then you better not use two's complement” -- Could you clarify a little bit? I believe it is entirely possible to sign extend a number using a 2's complement representation using its MSB, e.g. 4'b1111 will extend to 5'b11111, and 4'b0111 -> 5'b00111. Shouldn't it straightforward to add this to the existing barrel shifter within a floating point arithmetic logic?
– koo
Oct 14, 2012 at 13:27
– koo
Oct 16, 2012 at 10:19

From Wikipedia:

The two's-complement system has the advantage that the fundamental arithmetic operations of addition, subtraction, and multiplication are identical to those for unsigned binary numbers...

Two's-complement is a representation of negative numbers that just so happens to be very convenient. That's the whole reason to use it at all.

A mantissa-exponent pair is a representation of a floating point number. Most of the time when using floating point numbers, you aren't doing arithmetic solely on the mantissa or solely on the exponent.

But why is a sign bit necessary for floating point numbers

False assumption. It isn't necessary. I'm pretty sure I've met floating point formats which used 2's complement for the mantissa, but I'd have to dig out for names.

I'm far from being a specialist in numerical analysis, but I get that having signed zero is important for them. It's probably easier to manipulate than ones' complement. That was probably a criteria in the choice for IEEE-754.

Also why do the exponent bits use a bias instead of a signed-magnitude representation

Again it's something not needed and some have done thing differently.

It's the representation for which it is easier to do an hardware implementation for the set of operations which are done on exponents (and here having a representation for -0 isn't wanted).

One of the consequence of that choice is that you can use signed integer comparison to compare FP number if you don't care about NaN, which was perhaps a criteria for some (the fact than NaN needs special handling make me doubt it wasn't for IEEE-754).

• Signed integer comparisons will rank negative FP numbers backward. For them to rank properly, some kind of complement format would have been necessary, with ones' complement probably being the best (negative one would be ...110.1111..., with infinite ones to the left and right). Feb 8, 2015 at 20:18
• MIL-STD-1750A is probably the most widely used processor architecture that specifies a two's complement floating-point representation. In section 4.1: "The instruction set shall support 16-bit fixed point single precision, 32-bit fixed point double precision, 32-bit floating point and 48-bit floating point extended precision data in 2's complement representation." (emphasis mine). May 21, 2016 at 22:34

IEEE 754 uses sign/magnitude, not two's complement or one's complement.

Two's complement has the disadvantage that the positive and negative range are not identical. If all bit patterns are valid, then you have numbers x where you can't easily calculate -x. That's bad. The alternative is that there are invalid bit patterns, which is also bad. In IEEE 754 there are no invalid bit patterns for 64 or 32 bit floating point, so you don't need to worry about that.

One's complement would make multiply / divide more complex (with signed magnitude, you just xor the signs and treat the mantissa as an unsigned number). For add and subtract, I really don't want to think about add and subtract in one's complement, it makes my head hurt.

• The first paragraph of this answer suggests that there are no drawbacks to sign/magnitude. Sign/magnitude has +/-0 and more complicated arithmetic than two's complement. Oct 8, 2017 at 11:40
• Having +/- zero is both a problem and a feature. For example, dividing a tiny number x by 10^100 will give +0 or -0, preserving the sign of x. Oct 15, 2017 at 13:58

Having signed zeros gives increased expressiveness that may be useful in numerical computations. The wikipedia page ‘Signed zero’ says:

It is claimed that the inclusion of signed zero in IEEE 754 makes it much easier to achieve numerical accuracy in some critical problems, in particular when computing with complex elementary functions.

One of the main designers of IEEE 754 floating point, W.H. Kahan is a proponent of signed zero for these reasons. His opinion will have likely carried much weight.

I think it is important to understand that floating-point calculations produce approximate values, not exact values. That is, if a floating-point calculation yields an encoded value X, then this represents a theoretically ideal value which is almost certainly NOT X, but is in the range [X .. X+e) { where 'e' is the 'machine epsilon', i.e there is no floating-point number between X and X+e }. More specifically, a floating-point zero represents an ideal number which is probably not exactly zero, but which is too small to represent with a nonzero floating-point encoded value.

Given that, using sign-and-magnitude representation is a way of allowing the encoding to 'remember' exactly which side of zero the ideal value is on, the positive or the negative. This is critical in certain complex (in the 'a + bi' sense) calculations - complex->complex functions are often 'multi-valued', so for proper computation it is critical to pay attention to the locations of 'branch cuts'. Signed zeros then in a sense mark the locations of these branch cuts - the calculation done on the positive side will be different from that on the negative side.

• Floating-point calculations produce exact values. They are just slightly different from the values that mathematical real numbers produce. A floating point number represents one number, not a range. Apr 19, 2017 at 0:31

Most floating-point formats take advantage of the fact that, in a binary system, any non-zero value with a non-minimum exponent will have a "1" as the most significant bit of the mantissa. Thus, in a system with a 23-bit field for the mantissa, the mantissas of positive numbers don't range from 0 to 8,388,607 but instead from 8,388,608 to 16,777,215. The mantissas of numbers that may or may not be positive range from -16,777,215 to -8,388,608 and from +8,388,608 to +16,777,215. While two's-complement is best numerical format when it is necessary to have calculations "smoothly" cross zero, the discontinuous ranges of mantissa values mean that calculations wouldn't be able to to operate smoothly across zero whether they use two's-complement or something else.