4 ms·

> (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 h

by 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?
  - 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?

by jules 12y ago

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?
- 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?