4 ms·

> ...then use NaN = 0/0. Many languages throw an error when you divide by zero. As far as I can tell, if x != x didn't work you would have to resort to bizarr

> ...then use NaN = 0/0. Many languages throw an error when you divide by zero. As far as I can tell, if x != x didn't work you would have to resort to bizarre contortions like `x == float("NaN")` for such tests in Python (the problems: there are no NaN or Infinity constants and division by 0 throws). Also, since you expect == to do bit equality on floats, you will be distinguishing between the huge number of representation of NaN, so NaN = 0/0 isn't valid even if there is a NaN constant (and which one would it be?).

jules 12y ago
Still not a valid complaint. You want to test for NaN because some computation might result in NaN. Ergo, there is some expression in your language to produce NaN. Use that expression to define NaN. Response to edit: There can be several answers to this question. If you're gonna be stuck with the IEEE floats, obviously the right thing to do is an isNaN predicate, but arguably there shouldn't be more than 1 NaN in the first place.
derefr 12y ago
X/0.0 is safe, and will always return NaN, no matter the language -- as long as 0.0 is a representation of an IEEE754 floating-point value, and as long as the expression "X/0.0" is interpreted as coercing X into a floating-point value in order to do fpdiv(X, 0.0) -- then safely returning Infinity here (or NaN in the case of 0/0.0) is required of the FPU in order for it to be considered IEEE754-compliant. On the other hand, X/0 (integer division-by-zero, where X is not a floating-point value either) usually does cause an exception. In fact, in bare-metal ASM without a trap-handler interrupt set up, it halts the processor entirely.
- mansr 12y ago
  > On the other hand, X/0 (integer division-by-zero, where X is not a floating-point value either) usually does cause an exception. That's true for x86, but not for most other architectures.

jules 12y ago

Still not a valid complaint. You want to test for NaN because some computation might result in NaN. Ergo, there is some expression in your language to produce NaN. Use that expression to define NaN. Response to edit: There can be several answers to this question. If you're gonna be stuck with the IEEE floats, obviously the right thing to do is an isNaN predicate, but arguably there shouldn't be more than 1 NaN in the first place.

derefr 12y ago

X/0.0 is safe, and will always return NaN, no matter the language -- as long as 0.0 is a representation of an IEEE754 floating-point value, and as long as the expression "X/0.0" is interpreted as coercing X into a floating-point value in order to do fpdiv(X, 0.0) -- then safely returning Infinity here (or NaN in the case of 0/0.0) is required of the FPU in order for it to be considered IEEE754-compliant. On the other hand, X/0 (integer division-by-zero, where X is not a floating-point value either) usually does cause an exception. In fact, in bare-metal ASM without a trap-handler interrupt set up, it halts the processor entirely.

mansr 12y ago
> On the other hand, X/0 (integer division-by-zero, where X is not a floating-point value either) usually does cause an exception. That's true for x86, but not for most other architectures.