4 ms·
After reading about the case the author knew was not right (negative zero), I wonder why the relevant "equality" test wasn't more like if(isfinite(testValu
by jepler 9y ago
After reading about the case the author knew was not right (negative zero), I wonder why the relevant "equality" test wasn't more like
if(isfinite(testValue.f) && isfinite(refValue.f)
? testValue.i == refValue.i
: (fpclassify(testValue.f) == fpclassify(refValue.f)
&& signbit(testValue.f) == signbit(refValue.f)))
i.e., if the numbers are both finite [including denormals], they must have the same bit pattern; otherwise, they have to be the same kind (i.e., both infinite, or both nan) and have the same sign (my manpage for signbit says NaN has a sign, but that's news to me actually).
I doubt it's that I know more than Bruce Dawson about FP; is it about working in the distant past (2014, cough) without compiler support for C99 stuff like fpclassify and signbit?
- conistonwater 9y agoI don't like testing for NaN's using == and != either, but the only values that compare the same while having a different bit patterns are ±0 and all the NaN's, so as long as you get those right, the plain equality is fine. Also, I think your test has a corner case with 0x7ff8000000000000 and 0xfff8000000000000, because NaN's can have sign bits too, while the intention in the post is to treat any NaN as matching any NaN. So the test for equality could be something like "isnan(a) == isnan(b) && (isnan(a) || (a == b && signbit(a) == signbit(b)))" without any bitwise manipulation.
- brucedawson 9y agoI wouldn't want to write the test that way because it seems very complex. The other way I'd be tempted to write it would be to compare the bit patterns and treat mismatched bit patterns as a failure unless both numbers are NaN. To some extent it comes down to personal taste and how much knowledge of FP you want embedded in the test.