4 ms·

> use NaN = 0/0. You may not be able to do that it traps are enabled for the invalid exception. (The NaN may be coming in from a data file | over the wire | f

> use NaN = 0/0. You may not be able to do that it traps are enabled for the invalid exception. (The NaN may be coming in from a data file | over the wire | from another process prepared under an entirely separate floating-point environment that didn’t have traps enabled). > Can you give an example where == is appropriate, but where you want NaN == NaN to be false? I’ll give you one where == is appropriate but where you want -0 == +0: if (x == 0) return someFormulaValidAtZero(x); else return somethingEasierToComputeWithAnImplicitFactorOfx(x)/x; this is actually a fairly common idiom. Here’s my standard question for the “NaN should equal NaN" crowd, to which I’ve never seen a satisfactory response: If NaN == NaN, how should NaN compare against zero? I think we all agree that NaN != 0. If NaN < 0 or NaN > 0, you’re giving up x > y ==> -x < -y, which to my mind is a bigger loss than trichotomy. If NaN ?? 0, then trichotomy goes out the window, and presumably NaN ?? (any number), at which point NaN is unordered with respect to every number, but somehow equal to itself, which is also pretty darn weird. You give something up any way you tackle this. You may reasonably argue that one of these options is less bad than another, but you can’t pretend that there’s a canonical right approach (though nearly every algebraist I’ve ever met believes that you should be able to until they really dig into it; analysts are much more realistic). w.r.t. rounding modes, I partially agree. Had I been on the committee in 1985, I would have argued against formalizing round up and round down (round to zero is quite useful for some signal-processing applications). It’s a mistake to look at them and say “they aren’t interval arithmetic so they’re useless”, however. They were never intended to be interval arithmetic; rather they were intended to be building-blocks for interval arithmetic systems. (My problems with them are that (a) they’re global rather than operation-by-operation—this was corrected in the 2008 IEEE-754 document and (b) round-up and round-down are no more useful building blocks than round-to-zero (which we already have) and round-away-from-zero, which would free up space for another useful rounding mode (either round-ties-away “schoolbook rounding”) or round-to-odd, which is extremely useful for library implementors).

jules 12y ago
> (The NaN may be coming in from a data file | over the wire | from another process prepared under an entirely separate floating-point environment that didn’t have traps enabled). ........................................if NaN is incoming from a data file, then tadaaaa there's your way to make a NaN to compare to. I can't believe we're still playing that game. > I’ll give you one where == is appropriate but where you want -0 == +0: And how would that example work for x very close to 0? Even in that example, you'd want |x|<eps. But anyway, I'm not even sure that having 2 zeros is a great idea either. > If NaN == NaN, how should NaN compare against zero? It shouldn't. < is an operation that works on the abstraction that floats are kinda-sorta real numbers, and NaN isn't so NaN < x should be an error.
- stephencanon 12y ago
  Yes, it is always “possible” to make a NaN to compare to. Which is more convenient for programmers: x != x or x == someObscureMeansOfGettingNAN( )? Which is more portable and verifiable? I can’t believe you’re actually arguing for the latter. > And how would that example work for x very close to 0? Just fine; 0./0. is what this example needs to avoid, tiny/tiny is perfectly OK. That’s the whole point. You don’t want |x| < eps, you really do want x == 0. This happens all the time; if you’re not aware of such uses and you feel strongly about these issues, you may want to spend some more time studying the way these tools are used in low-level numerics. > NaN < x should be an error. That may be an option for some high-level languages. It’s very much not an option for C/FORTRAN-type languages, and not an option at the level of IEEE-754 specification. It can either be true or false or a trap (and the latter would be wholly inconsistent with the rest of IEEE-754). You don’t get to make up some exception or error or “not-a-boolean” or Maybe. It sounds like you want a more abstract floating-point spec for higher-level languages; that’s fine. I think it’s a great idea, actually. IEEE-754 necessary needs to support very low-level implementations, however. (That said, if NaN < x is an error, that will really cause issues when someone tries to use it as a key in an ordered container).
  - jules 12y ago
    > Yes, it is always “possible” to make a NaN to compare to. Which is more convenient for programmers: x != x or x == someObscureMeansOfGettingNAN( )? Which is more portable and verifiable? I can’t believe you’re actually arguing for the latter. Tell me, which is clearer: x != x, or x == NaN. Obviously, the latter is much clearer. We don't live in the 1960's any more, we have libraries now. No need for getting NaN to be obscure. > Just fine; 0./0. is what this example needs to avoid, tiny/tiny is perfectly OK. That’s the whole point. You don’t want |x| < eps, you really do want x == 0. This happens all the time; if you’re not aware of such uses and you feel strongly about these issues, you may want to spend some more time studying the way these tools are used in low-level numerics. Please, do give a concrete example, if they are so abundant. Otherwise you will keep saying "yea, but for some examples, that's not an issue". Anyway, this is wholly besides the point. You still refused to answer the question I actually asked: NaN not 0. > (That said, if NaN < x is an error, that will really cause issues when someone tries to use it as a key in an ordered container). As it should. The current behavior may cause silent errors and corruption, instead of blowing up and notifying you. Which would you prefer?

jules 12y ago

> (The NaN may be coming in from a data file | over the wire | from another process prepared under an entirely separate floating-point environment that didn’t have traps enabled). ........................................if NaN is incoming from a data file, then tadaaaa there's your way to make a NaN to compare to. I can't believe we're still playing that game. > I’ll give you one where == is appropriate but where you want -0 == +0: And how would that example work for x very close to 0? Even in that example, you'd want |x|<eps. But anyway, I'm not even sure that having 2 zeros is a great idea either. > If NaN == NaN, how should NaN compare against zero? It shouldn't. < is an operation that works on the abstraction that floats are kinda-sorta real numbers, and NaN isn't so NaN < x should be an error.

stephencanon 12y ago
Yes, it is always “possible” to make a NaN to compare to. Which is more convenient for programmers: x != x or x == someObscureMeansOfGettingNAN( )? Which is more portable and verifiable? I can’t believe you’re actually arguing for the latter. > And how would that example work for x very close to 0? Just fine; 0./0. is what this example needs to avoid, tiny/tiny is perfectly OK. That’s the whole point. You don’t want |x| < eps, you really do want x == 0. This happens all the time; if you’re not aware of such uses and you feel strongly about these issues, you may want to spend some more time studying the way these tools are used in low-level numerics. > NaN < x should be an error. That may be an option for some high-level languages. It’s very much not an option for C/FORTRAN-type languages, and not an option at the level of IEEE-754 specification. It can either be true or false or a trap (and the latter would be wholly inconsistent with the rest of IEEE-754). You don’t get to make up some exception or error or “not-a-boolean” or Maybe. It sounds like you want a more abstract floating-point spec for higher-level languages; that’s fine. I think it’s a great idea, actually. IEEE-754 necessary needs to support very low-level implementations, however. (That said, if NaN < x is an error, that will really cause issues when someone tries to use it as a key in an ordered container).
- jules 12y ago
  > Yes, it is always “possible” to make a NaN to compare to. Which is more convenient for programmers: x != x or x == someObscureMeansOfGettingNAN( )? Which is more portable and verifiable? I can’t believe you’re actually arguing for the latter. Tell me, which is clearer: x != x, or x == NaN. Obviously, the latter is much clearer. We don't live in the 1960's any more, we have libraries now. No need for getting NaN to be obscure. > Just fine; 0./0. is what this example needs to avoid, tiny/tiny is perfectly OK. That’s the whole point. You don’t want |x| < eps, you really do want x == 0. This happens all the time; if you’re not aware of such uses and you feel strongly about these issues, you may want to spend some more time studying the way these tools are used in low-level numerics. Please, do give a concrete example, if they are so abundant. Otherwise you will keep saying "yea, but for some examples, that's not an issue". Anyway, this is wholly besides the point. You still refused to answer the question I actually asked: NaN not 0. > (That said, if NaN < x is an error, that will really cause issues when someone tries to use it as a key in an ordered container). As it should. The current behavior may cause silent errors and corruption, instead of blowing up and notifying you. Which would you prefer?