3 ms·
Naively, max(a, b) would be implemented as return a >= b ? a : b; But if x is -0.0, you're back to the same problem that -0.0 >= +0.0 actually turns out t
by kmm 5y ago
Naively, max(a, b) would be implemented as
return a >= b ? a : b;
But if x is -0.0, you're back to the same problem that -0.0 >= +0.0 actually turns out to be true and not false, hence the return value will be -0.0.
Looking at the actual implementation[0], doubleToRawLongBits is used again here to take care of this edge case. So it would work, but a lot slower than the version given in the article.
0: https://github.com/openjdk/jdk/blob/36e2ddad4d2ef3ce27475af6244d0246a8315c0c/src/java.base/share/classes/java/lang/Math.java#L1681 https://github.com/openjdk/jdk/blob/36e2ddad4d2ef3ce27475af6...
- andi999 5y agoCouldn't you also implement max as return a>b? a:b; (changing greater equal to just greater). Would the problem then still persist?
- kmm 5y agoPositive and negative zero cannot be distinguished by normal equality checks, meaning +0.0 == -0.0. Therefore, for consistency's sake +0.0 > -0.0 ought to be false, which would yield a return value of -0.0 for max(+0.0, -(+0.0))
- gvx 5y agoThat wouldn't solve it: max(0.0, -0.0) would be false ? 0.0 : -0.0 The problem is that 0.0 == -0.0. As long as you don't take care of signed zero, you cannot guarantee that abs(x) has no negative sign.