It's a natural consequence of the IEEE 754 standard for floating point numbers.

To be clear, it was added to the standard because there was user demand for it.

Zero is already special cased in IEEE 754 (along with the rest of the denormals, because of the implied leading mantissa bit), the implementation would be no harder if you just only had a single zero. However, back when the standard was being created, when a single zero value was proposed there was pushback from people in the user community who depended on knowing which side of the zero they underflowed on their own floating point implementations.

Many people think that negative zero is just an engineering artefact. This is not true, it is a feature that was asked for, debated, and then added...

... almost certainly because it was an engineering artefact in a previous system that someone managed to depend on, https://xkcd.com/1172/ style.

> Many people think that negative zero is just an engineering artefact. This is not true, it is a feature that was asked for, debated, and then added...

Allowing zero to be represented with two bit patterns was a feature that was advocated for to make bit operations easier - it was not decided that both zeroes should be distinguishable. This absolutely is an engineering artifact but you're quite correct that it was quite intentional.

i think the rationale in https://people.freebsd.org/~das/kahan86branch.pdf goes well above and beyond 'an engineering artefact in a previous system that someone managed to depend on'

unfortunately this scan is missing some pages

Because two binary values that are not bit-for-bit equal should have an equality operator that can reflect that without resorting to conversion

1/Infinity in 754 is 0. 1/(-Infinity) is -0. These numbers are not strictly equal in real number terms.

These numbers are inequal in terms of storage - in real number terms zero has no sign and thus -0 and +0 are the same number. The source of their distinction is also important as it's just a pure point of convenience at the bit level - there are two separate bit patterns for 0 but both numbers are the same number.

+/-0 often indicates an underflow on one side of 0 or the other. Certainly in real terms 1/(infinity) != -1/(infinity).

You are overloading the word “real”. In terms of the mathematics of the reals, there is no difference. In terms of real-life pragmatics, 0 and -0 could be used to differentiate between different outcomes in a way that is sometimes useful.

Infinity and -0 are not in the real numbers, so the expression there makes no sense if you are thinking strictly in the real numbers. If you assign real number bounds to what the floating point numbers mean, the expressions make sense.

In floating point terms infinity tends to indicate overflow (any number that is too big to represent) and the 0's indicate underflows. So in more verbose terms,

1/(positive overflow) = (positive underflow)

While

-1/(positive overflow) = (negative underflow)

In this case, since the positive overflow isn't really infinity and the underflows aren't really 0, they are not equal. In practice, -0 and the 0 can both also arise from situations that produce 0 exactly, too, but this is not that case.

You may be thinking about how lim{x->inf}(1/x) = 0 = lim{x->inf}(-1/x), which is true. Infinity in floating point does not necessarily represent that limit, though, just any number that is too big.

You may also notice that the limit is not in the range of the functions inside the limit. For all real x, 1/x != 0

We are saying the same thing.

Float stuff like 1.f / (+0.f) = infinity and 1.f / (-0.f) = -infinity.

And maybe complex number shenanigans and multi valued functions? Maybe someone familiar with mathematics can tell us more. :)

The best example on kahan's webpage is Borda's mouthpiece. Signed zero makes it look right, unsigned creates a singularity

There are actually very clear and technical numerical analysis reasons for all of the weird stuff that happens in IEEE 754. The zero behavior, in particular, is because of this sort of thing.

Preserving the sign in case of arithmetic overflow/underflow.

Floating point numbers don't represent all possible values, just a subset of values representable by a number of bits used. Therefore, in some cases it's reasonable to treat floating point numbers not as "exact point on a number scale", but rather a range between a number and the next possible representable number.

In the case of +0.0 and -0.0, they can be treated as values between zero and the smallest representable number (about 5.4E-079 for 32 bit floats). It isn't a very common use case since dealing with such small numbers isn't a very common thing, but it is definitely a possibility.