3 ms·

Division by zero is perfectly well defined in floating point. x/0 = INF and INF0 = NaN. That means b(a/b) != a if b = 0. It's true that it's not defined for

Division by zero is perfectly well defined in floating point. x/0 = INF and INF*0 = NaN. That means b*(a/b) != a if b = 0. It's true that it's not defined for integer types, but that wouldn't make a = b*(a/b) true for them either. It's also common to define x/0 = infinity in the extended real numbers that floating point models.

lou1306 2y ago
The definitions in the floating point standard make much more sense when you look to 0/INF as "something so close to/far from 0 we cannot represent it", rather than the actual concepts of 0 and infinity.
danbruc 2y ago
The limit 1/x as x goes to zero diverges to plus or minus infinity depending on whether you approach from the right or the left. IEEE 754 uses a signed zero, so defining 1/+0 = +INF and 1/-0 = -INF makes sense. If you do not have a signed zero, arbitrarily picking either plus or minus infinity makes much less sense and picking their "average" zero seems more sensible. So x/0 is not actually +INF - even if you meant +0 and we forget about -0 - it is +INF or -INF depending on the sign of x and NaN if x is +0 or -0.
eesmith 2y ago
In floating point a = b * (a / b) is not always a true statement. >>> import random >>> random.random() 0.4667867537470992 >>> n = 0 >>> for i in range(1_000_000): ... a = random.random() ... b = random.random() ... if (a == b * (a / b)): ... n += 1 ... >>> n 886304 For example: >>> a, b = 0.7959754927336106, 0.7345016612407793 >>> a == b * (a / b) False >>> a 0.7959754927336106 >>> b * (a / b) 0.7959754927336105 This is off by one ulp ("unit in the last place"). And of course the division of two finite floating point numbers may be infinite: >>> a, b = 2, 1.5e-323 >>> a 2 >>> b 1.5e-323 >>> b * (a / b) inf >>> a/b inf As a minor technical point, x/0 can be -INF if sgn(x) < 0, and NaN if x is a NaN.
snickerbockers 2y ago
TFA was about mathematics, not computer programs. Mathematically, the limit as b approaches 0 of a/b is defined to be +/- INF depending whether a and b have matching signs. The limit represents the value that a/b asymptotically approaches as b approaches 0. a/b for b=0 is still undefined. For a good example of why this needs to be undefined, consider that limit as b approaches zero of a/b is both +INF and -INF depending on whether b is "approaching" from the side that matches a's sign or the opposite side. At the exact singularity where b=0 +INF and -INF are both equally valid answers, which is a contradiction. also in case you weren't aware, "NaN" stands for "not a number".
- AlotOfReading 2y ago
  You might have noticed that TFA was discussing a programming language, Pony, that uses floating point. The behavior of the reals isn't relevant. In the extended reals case I mentioned, it's a definition used when working on the positives. Didn't think I needed to state the obvious.
  - snickerbockers 2y ago
    Pony is what prompted TFA to consider whether or not 1/0 should be defined. It's not what the article is about. Obviously anybody who writes a compiler can define / to have a specified behavior for a zero divisor; TFA is about whether that's correct. There's nothing significant about IEEE 754 choosing to define an operation that's nominally undefined, as it does not have any bearing on whether or not that behavior is correct.

Division by zero is perfectly well defined in floating point. x/0 = INF and INF*0 = NaN. That means b*(a/b) != a if b = 0. It's true that it's not defined for

lou1306 2y ago

The definitions in the floating point standard make much more sense when you look to 0/INF as "something so close to/far from 0 we cannot represent it", rather than the actual concepts of 0 and infinity.

danbruc 2y ago

The limit 1/x as x goes to zero diverges to plus or minus infinity depending on whether you approach from the right or the left. IEEE 754 uses a signed zero, so defining 1/+0 = +INF and 1/-0 = -INF makes sense. If you do not have a signed zero, arbitrarily picking either plus or minus infinity makes much less sense and picking their "average" zero seems more sensible. So x/0 is not actually +INF - even if you meant +0 and we forget about -0 - it is +INF or -INF depending on the sign of x and NaN if x is +0 or -0.

eesmith 2y ago

In floating point a = b * (a / b) is not always a true statement. >>> import random >>> random.random() 0.4667867537470992 >>> n = 0 >>> for i in range(1_000_000): ... a = random.random() ... b = random.random() ... if (a == b * (a / b)): ... n += 1 ... >>> n 886304 For example: >>> a, b = 0.7959754927336106, 0.7345016612407793 >>> a == b * (a / b) False >>> a 0.7959754927336106 >>> b * (a / b) 0.7959754927336105 This is off by one ulp ("unit in the last place"). And of course the division of two finite floating point numbers may be infinite: >>> a, b = 2, 1.5e-323 >>> a 2 >>> b 1.5e-323 >>> b * (a / b) inf >>> a/b inf As a minor technical point, x/0 can be -INF if sgn(x) < 0, and NaN if x is a NaN.

snickerbockers 2y ago

TFA was about mathematics, not computer programs. Mathematically, the limit as b approaches 0 of a/b is defined to be +/- INF depending whether a and b have matching signs. The limit represents the value that a/b asymptotically approaches as b approaches 0. a/b for b=0 is still undefined. For a good example of why this needs to be undefined, consider that limit as b approaches zero of a/b is both +INF and -INF depending on whether b is "approaching" from the side that matches a's sign or the opposite side. At the exact singularity where b=0 +INF and -INF are both equally valid answers, which is a contradiction. also in case you weren't aware, "NaN" stands for "not a number".

AlotOfReading 2y ago
You might have noticed that TFA was discussing a programming language, Pony, that uses floating point. The behavior of the reals isn't relevant. In the extended reals case I mentioned, it's a definition used when working on the positives. Didn't think I needed to state the obvious.
- snickerbockers 2y ago
  Pony is what prompted TFA to consider whether or not 1/0 should be defined. It's not what the article is about. Obviously anybody who writes a compiler can define / to have a specified behavior for a zero divisor; TFA is about whether that's correct. There's nothing significant about IEEE 754 choosing to define an operation that's nominally undefined, as it does not have any bearing on whether or not that behavior is correct.