5 ms·

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

> 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.
- stephencanon 12y ago
  > 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. They are detecting precisely x == (+/-)0, whereas you earlier said "you should always use some other condition like |x-y| < epsilon, and NOT x == y”. They are all perfect examples of my case; the fact that some of them happen to be written as abs(x) == 0 doesn’t effect that (in the case of LAPACK, this is defensive programming because many LAPACK routines predate widespread adoption of IEEE-754; the compiler simply optimizes away the absolute value on a modern system). My original claim was that neither NaN == NaN nor NaN != NaN is completely satisfactory, but the designers of the 8087 concluded that the latter provided an easier and more portable way to test for nan on systems that had no name for a NaN constant. I’m not the one who “came with this argument”, either; it’s directly from the writings of William Kahan, who was a consultant on the design of the 8087 and was the primary architect of original 1985 IEEE-754 standard.
  - jules 12y ago
    > whereas you earlier said "you should always use some other condition like |x-y| < epsilon, and NOT x == y” Good job on that strawman by picking only half the sentence and out of context. > I’m not the one who “came with this argument” I don't care who originally came up with it, you are the one who brought this into the discussion, and then you pull a 180 "Why are you worried about this?". Anyway, the mistakes made in IEEE floating point are nothing that programming language designers can't fix. Hopefully future languages will make the sensible decision to let == compare floats exactly, and stick the IEEE == deep inside some library somewhere as ieeeFloatingPointComparisonThatIsVirtuallyNeverUsed(x,y).
    - haberman 12y ago
      It is really unfortunate the tone you have chosen for this thread. You raise interesting questions, but your argumentative and uncharitable tone overshadows your content and sours the reader on your perspective. Your certainty about what you perceive as unambiguous faults in the IEEE standard is not justified given that your experience on the matter is much less than the person you are so rudely criticizing.

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.

stephencanon 12y ago
> 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. They are detecting precisely x == (+/-)0, whereas you earlier said "you should always use some other condition like |x-y| < epsilon, and NOT x == y”. They are all perfect examples of my case; the fact that some of them happen to be written as abs(x) == 0 doesn’t effect that (in the case of LAPACK, this is defensive programming because many LAPACK routines predate widespread adoption of IEEE-754; the compiler simply optimizes away the absolute value on a modern system). My original claim was that neither NaN == NaN nor NaN != NaN is completely satisfactory, but the designers of the 8087 concluded that the latter provided an easier and more portable way to test for nan on systems that had no name for a NaN constant. I’m not the one who “came with this argument”, either; it’s directly from the writings of William Kahan, who was a consultant on the design of the 8087 and was the primary architect of original 1985 IEEE-754 standard.
- jules 12y ago
  > whereas you earlier said "you should always use some other condition like |x-y| < epsilon, and NOT x == y” Good job on that strawman by picking only half the sentence and out of context. > I’m not the one who “came with this argument” I don't care who originally came up with it, you are the one who brought this into the discussion, and then you pull a 180 "Why are you worried about this?". Anyway, the mistakes made in IEEE floating point are nothing that programming language designers can't fix. Hopefully future languages will make the sensible decision to let == compare floats exactly, and stick the IEEE == deep inside some library somewhere as ieeeFloatingPointComparisonThatIsVirtuallyNeverUsed(x,y).
  - haberman 12y ago
    It is really unfortunate the tone you have chosen for this thread. You raise interesting questions, but your argumentative and uncharitable tone overshadows your content and sours the reader on your perspective. Your certainty about what you perceive as unambiguous faults in the IEEE standard is not justified given that your experience on the matter is much less than the person you are so rudely criticizing.