5 ms·

> For example, if you divide 1.0 by +0.0 and -0.0, you get completely different answers: +Infinity and -Infinity. This must be a Java-ism. In most languages I

> For example, if you divide 1.0 by +0.0 and -0.0, you get completely different answers: +Infinity and -Infinity. This must be a Java-ism. In most languages I've used you get a division by zero error or NaN.

titzer 5y ago
It's IEEE-754.
- magicalhippo 5y ago
  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 https://tavianator.com/2011/ray_box.html
ketzu 5y ago
+/- 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 (−∞).
Agentlien 5y ago
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.
titzer 5y ago
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.
- darig 5y ago
  -mind
- nimish 5y ago
  How else would you represent a branch cut or even a jump at 0? https://people.freebsd.org/~das/kahan86branch.pdf https://people.freebsd.org/~das/kahan86branch.pdf from the father of ieee-754 is illuminating.
  - croes 5y ago
    So for programming convenience we ignore correct math?
    - FabHK 5y ago
      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?
      - croes 5y ago
        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?
  - FabHK 5y ago
    Haha, was just going to link that. Here's an ELI5, though not that illuminating: https://hackernoon.com/negative-zero-bbd5fd790af3 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 http://history.siam.org/pdfs2/Kahan_final.pdf
kmm 5y ago
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.
- da_chicken 5y ago
  > Which languages did you try? Python and C#.
  - Kranar 5y ago
    Python does throw an exception but C# does not.
  - kmm 5y ago
    Dividing 1.0 by 0.0 gives ∞ in C# as well when I try it.
    - da_chicken 5y ago
      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.
wodenokoto 5y ago
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.
FabHK 5y ago
> 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 http://people.eecs.berkeley.edu/~wkahan/Boulder.pdf https://www.wired.com/1998/07/sunk-by-windows-nt/ 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.
- da_chicken 5y ago
  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.

titzer 5y ago

It's IEEE-754.

magicalhippo 5y ago
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 https://tavianator.com/2011/ray_box.html

ketzu 5y ago

+/- 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 (−∞).

Agentlien 5y ago

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.

titzer 5y ago

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.

darig 5y ago
-mind
nimish 5y ago
How else would you represent a branch cut or even a jump at 0? https://people.freebsd.org/~das/kahan86branch.pdf https://people.freebsd.org/~das/kahan86branch.pdf from the father of ieee-754 is illuminating.
- croes 5y ago
  So for programming convenience we ignore correct math?
  - FabHK 5y ago
    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?
    - croes 5y ago
      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?
- FabHK 5y ago
  Haha, was just going to link that. Here's an ELI5, though not that illuminating: https://hackernoon.com/negative-zero-bbd5fd790af3 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 http://history.siam.org/pdfs2/Kahan_final.pdf

kmm 5y ago

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.

da_chicken 5y ago
> Which languages did you try? Python and C#.
- Kranar 5y ago
  Python does throw an exception but C# does not.
- kmm 5y ago
  Dividing 1.0 by 0.0 gives ∞ in C# as well when I try it.
  - da_chicken 5y ago
    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.

wodenokoto 5y ago

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.

FabHK 5y ago

> 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 http://people.eecs.berkeley.edu/~wkahan/Boulder.pdf https://www.wired.com/1998/07/sunk-by-windows-nt/ 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.

da_chicken 5y ago
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.