2 ms·

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 m

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?
- stephencanon 12y ago
  > Tell me, which is clearer: x != x, or x == NaN. Neither. isnan(x) is by far the clearest. Why are you worried about this? > Please, do give a concrete example, if they are so abundant. Looking at the OS X math library sources, since I happened to have them in front of me, the implementation of the following functions use an exact equality test with zero (this list is not complete; I simply grepped for “== 0.”): acos, asin, atan, atan2, cbrt, ceil, all of the complex.h functions, atanh, exp, sinh, erf, exp2, floor, fma, fmod, hypot, lgamma, log10, log2, logb, logf, nearbyint, nextafter, pow, round, asinh, tanh, sin, cos, tan, tgamma. Looking at LAPACK, the following functions use one or more exact comparisons with zero (listing double-precision real functions only, and again this is an incomplete list): dbdsdc dbdsqr ddisna dgbcon dgbequ dgbequb dgbsvx dgebal dgecon dgeequ dgeequb dgees dgeesx dgeev dgeevx dgegv dgejsv dgels dgelsd dgelss dgelsx dgelsy dgesvj dgesvx dggbal dgges dggesx dggev dggevx dgsvj0 dgsvj1 dgtcon dgtsv dgttrf dhgeqz dhsein dlaed4 dlaed6 dlaein dlaev2 dlag2 dlagtf dlagtm dlagts dlagv2 dlahqr dlaic1 dlals0 dlalsd dlanv2 dlapy2 dlapy3 dlaqr0 dlaqr1 dlaqr2 dlaqr3 dlaqr4 dlaqr5 dlaqtr dlar1v dlarf dlarfg dlarfp dlarft dlarfx dlargv dlarrc dlartg dlarzt dlas2 dlascl dlasd4 dlasq1 dlasq2 dlasq3 dlasq4 dlasq6 dlasv2 dlasyf dlatzm dpbcon dpocon dppcon dpstf2 dpstrf dptcon dsfrk dspcon dsptrf dsptri dstedc dsteqr dsycon dsytf2 dsytri dtbcon dtbtrs dtfsm dtgevc dtgexc dtgsen dtgsna dtpcon dtptri dtptrs dtrcon dtrevc dtrexc dtrsen dtrsna dtrtri dtrtrs. Any one of these, or millions of other functions, will provide your concrete example. Can we finally give up the pretense that such usage isn’t justified and widespread, or are you going to insist that you know more than the implementors of these functions?
  - jules 12y ago
    > Why are you worried about this? Hold on. I am not the one who came with this argument that NaN == NaN should be false because that gives us a way to test for NaN, you are. > Can we finally give up the pretense that such usage isn’t justified and widespread Not yet. I've looked at a couple of your examples, and so far all of them either test whether an absolute value is zero, or whether a value that was previously assigned the exact value zero is zero. So they do not actually support your case. And yet again, this is beside the point; your original claim was about NaN, not 0.

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?

stephencanon 12y ago
> Tell me, which is clearer: x != x, or x == NaN. Neither. isnan(x) is by far the clearest. Why are you worried about this? > Please, do give a concrete example, if they are so abundant. Looking at the OS X math library sources, since I happened to have them in front of me, the implementation of the following functions use an exact equality test with zero (this list is not complete; I simply grepped for “== 0.”): acos, asin, atan, atan2, cbrt, ceil, all of the complex.h functions, atanh, exp, sinh, erf, exp2, floor, fma, fmod, hypot, lgamma, log10, log2, logb, logf, nearbyint, nextafter, pow, round, asinh, tanh, sin, cos, tan, tgamma. Looking at LAPACK, the following functions use one or more exact comparisons with zero (listing double-precision real functions only, and again this is an incomplete list): dbdsdc dbdsqr ddisna dgbcon dgbequ dgbequb dgbsvx dgebal dgecon dgeequ dgeequb dgees dgeesx dgeev dgeevx dgegv dgejsv dgels dgelsd dgelss dgelsx dgelsy dgesvj dgesvx dggbal dgges dggesx dggev dggevx dgsvj0 dgsvj1 dgtcon dgtsv dgttrf dhgeqz dhsein dlaed4 dlaed6 dlaein dlaev2 dlag2 dlagtf dlagtm dlagts dlagv2 dlahqr dlaic1 dlals0 dlalsd dlanv2 dlapy2 dlapy3 dlaqr0 dlaqr1 dlaqr2 dlaqr3 dlaqr4 dlaqr5 dlaqtr dlar1v dlarf dlarfg dlarfp dlarft dlarfx dlargv dlarrc dlartg dlarzt dlas2 dlascl dlasd4 dlasq1 dlasq2 dlasq3 dlasq4 dlasq6 dlasv2 dlasyf dlatzm dpbcon dpocon dppcon dpstf2 dpstrf dptcon dsfrk dspcon dsptrf dsptri dstedc dsteqr dsycon dsytf2 dsytri dtbcon dtbtrs dtfsm dtgevc dtgexc dtgsen dtgsna dtpcon dtptri dtptrs dtrcon dtrevc dtrexc dtrsen dtrsna dtrtri dtrtrs. Any one of these, or millions of other functions, will provide your concrete example. Can we finally give up the pretense that such usage isn’t justified and widespread, or are you going to insist that you know more than the implementors of these functions?
- jules 12y ago
  > Why are you worried about this? Hold on. I am not the one who came with this argument that NaN == NaN should be false because that gives us a way to test for NaN, you are. > Can we finally give up the pretense that such usage isn’t justified and widespread Not yet. I've looked at a couple of your examples, and so far all of them either test whether an absolute value is zero, or whether a value that was previously assigned the exact value zero is zero. So they do not actually support your case. And yet again, this is beside the point; your original claim was about NaN, not 0.