Haha, -0. After spending literal years of my life dealing with that little encoding nuisance, in everything from the V8 TurboFan JIT, to WebAssembly, to adding floating point to Virgil, I just gotta say, that little turd is so not worth it. I've read a lot of different justifications for it (it's a limit, it represents approaching 0 from the negatives, some algorithms need it, etc), I have to admit, I just don't buy it. It's an encoding artifact that's produced so much accidental complexity that, in my book, has been far more trouble than it's been worth.

Change my mind.

How else would you represent a branch cut or even a jump at 0?

https://people.freebsd.org/~das/kahan86branch.pdf from the father of ieee-754 is illuminating.

Haha, was just going to link that. Here's an ELI5, though not that illuminating:

https://hackernoon.com/negative-zero-bbd5fd790af3

But, bottom line, Kahan (not only the father of IEEE 754, but also, with Golub, father of the SVD!) has thought about it a lot, and though he called the signed zero "a pain in the ass", he also said "There really wasn’t a way around that and you were stuck with it."

http://history.siam.org/pdfs2/Kahan_final.pdf

I don't really understand. Why is it important that there be two zeros so that

1/ (+0) = +∞ but 1/ (–0) = –∞

but not that there be two, say, 3s so that

1/ (3⁺ – 3) = +∞ but 1/ (3⁻ – 3) = –∞

But we already have two threes: +3 and -3.

It's not that it's important there be two, just every number already had 2 except for 0.

So for programming convenience we ignore correct math?

We cannot represent "correct math" on a computer, because the set of reals is uncountable, but in 64 bits we can only represent finitely many numbers, not infinitely many, let alone uncountably many.

And given that we have to implement some sort of approximation to the usual math on a closed subset of the reals (rationals, even), why not extend it with some "numbers" (negative zero, plus/minus infinity, NaNs) that, yes, enable programming convenience?

There is a difference between 2.4987665678 as 2.5 and undefined as ±infinity especially because 1.0/+0.0 is +infinity and 1/0 is just an exception in Java. Shouldn't it be the same result?

+/- Infinity seems to be correct according to IEEE754.

IEEE754 section 7.3:

The divideByZero exception shall be signaled if and only if an exact infinite result is defined for an operation on finite operands. The default result of divideByZero shall be an ∞ correctly signed according to the operation: ― For division, when the divisor is zero and the dividend is a finite non-zero number, the sign of the infinity is the exclusive OR of the operands’ signs (see 6.3). ― For logB(0) when logBFormat is a floating-point format, the sign of the infinity is minus (−∞).

Which languages did you try? I found that dividing 1.0 by 0.0 gives Infinity in Java, C, Julia, JavaScript, Ruby, Clojure, Haskell and Rust. I get division errors in Python and Perl.

Curiously, Go gives me a compiler error if I divide constant literals, but assigning 0.0 to a variable and dividing by it does work. On top of that, assigning -0.0 to a float variable leads to it having the value +0.0, which I would call a borderline compiler bug. Both are probably a consequence of Go constant literals not being IEEE-754 floats but some arbitrary precision number types, but it's very unexpected behavior.

> Which languages did you try?

Python and C#.

Dividing 1.0 by 0.0 gives ∞ in C# as well when I try it.

You're right. I must've divided 0 by 0 and -0. That's the only way C# gives me NaN. I thought I'd specifically avoided doing that.

Python does throw an exception but C# does not.

> In most languages I've used you get a division by zero error or NaN

Or it raises an exception, which once disabled a navy warship for hours:

> Now decommissioned, the USS Yorktown was among the first warhips extensively computerized to reduce crew (by 10% to 374) and costs (by $2.8 million per year).

> On 21 Sept. 1997, the Yorktown was maneuvering off the coast of Cape Charles, VA, when a crewman accidentally ENTERed a blank field into a data base. The blank was treated as a zero and caused a Divide-by-Zero Exception which the data-base program could not handle. It aborted to the operating system, Microsoft Windows NT 4.0, which crashed, bringing down all the ship’s LAN consoles and miniature remote terminals.

> The Yorktown was paralyzed for 2 3/4 hours, unable to control steering, engines or weapons, until the operating system had been re-booted. Fortunately the Yorktown was not in combat nor in crowded shipping lanes.

> If IEEE 754’s default had been in force, the division by zero would have insinuated into the data-base an ∞ and/or NaN, which would have been detected afterwards without a crash.

http://people.eecs.berkeley.edu/~wkahan/Boulder.pdf

https://www.wired.com/1998/07/sunk-by-windows-nt/

EDIT: It was 2 3/4 hours, not 23 hours. I copied/pasted carelessly from the PDF.

Eh, there's like six separate issues that led to this.

1. Interface accepted blank value for a form when a numeric value is required.

2. Application and database permitted a null or coerced a zero when the value is required and cannot be zero. You've got to sanitize your input.

3. Application did not check for or gracefully handle something as common as a division by zero exception. Instead it proceeded to a buffer overrun and crashed.

4. Application crashing apparently caused an OS crash? Yes, okay, it's NT 4.0 and a buffer overrun, but that still should not happen. Protected mode is a thing.

5. There is no redundancy in a system that manages the steering, weapons, and engines of a warship.

6. A warship was unable to restore the single CNC system to working order for 23 hours.

Furthermore... there's no evidence that the software would have behaved more sensibly or more controllably if it had a value of infinity instead of an error. It shouldn't have had a zero in the first place.

It's IEEE-754.

And there are algorithms that rely on this, like this[1] branchless axis-aligned bounding box intersection test.

It exploits the division by zero sign logic of IEEE-754, so that the min/max operations used also handles the edge cases where the ray is parallel to an axis.

[1]: https://tavianator.com/2011/ray_box.html

This is what you get according to IEE 754.

You'd get NaN from 0.0/0.0 or division by zero if you did 1/0 as integer division.

While parent isn’t correct in their assumption, this was also my first thought after reading the article and I appreciate the ensuing discussion.

I hope others will take the entire thread into consideration before downvoting.