4 ms·

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

> 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
    You're right I shouldn't have used that tone. On the other hand, my points still stand. Taking quotes out of context to create false contradictions does not make for a very kosher discussion either. However, unlike with floating point multiplication two negatives don't make a positive, so I hereby apologize for my tone.

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
  You're right I shouldn't have used that tone. On the other hand, my points still stand. Taking quotes out of context to create false contradictions does not make for a very kosher discussion either. However, unlike with floating point multiplication two negatives don't make a positive, so I hereby apologize for my tone.