Hacker News Reader

Comment by _getify | Hacker News Reader

The "WTF" label is not about correctness, it's about surprise/intuition. It doesn't really matter to me whether it's mathematically or IEEE correct. It's strange and inconsistent.

Yes, two numbers of different signs added together are supposed to be 0, but... a number is never supposed to change (sign or magnitude) when you add 0 to it, and here it does... so... it's a strange corner case that I think defies intuition.

Given the two precedences that are incompatible, I think far more people are likely to think "anything + 0 ======= anything" than they are to think "anything + -anything ========== +0". So that's why I marked it as a WTF.

View on HN

> number is never supposed to change (sign or magnitude) when you add 0 to it

In the “real numbers”, zero doesn’t have a sign at all, and -0 and 0 mean precisely the same thing. Floating point is an approximation which needs to make some choices about edge cases, for the sake of practical uses (for instance it is useful to distinguish negative underflow from positive underflow, so there is an extra -0 value included).

The behavior that 0 - 0 or -0 + 0 produces 0 as output is not an unreasonable choice (it is what I would expect, as someone with a decent amount of mathematical experience). I would not expect very many people to have the “intuition” that -0 + 0 or 0 - 0 should produce -0 as a result, assuming they had any intuition at all about what should happen in this edge case.

-0 is truly a mistake on the part of the IEEE committee. You can get it by dividing by -infinity, it's supposed to indicate "zero approached from the left in this case, but it's not consistent; sqrt(-0) will give you -0 in most implementations

1/–∞ == –0 seems like obviously the correct behavior in context of IEEE floats.

I think if someone is careful it should be possible to make an implementation of complex square root on top of IEEE floats such that √(–a² + 0i) == ai, whereas √(–a² – 0i) == –ai, representing the two sides of a branch cut.

Yes, √–0 should be 0. File a bug against whatever implementation returned –0 for that one.

IEEE 754 says √–0 is –0 though.

Ah really? What is the purpose of that?

Not sure. Via https://stackoverflow.com/questions/19236117/what-numerical-... I found https://people.freebsd.org/~das/kahan86branch.pdf, but that's a more complex read than I'm prepared for right now ;)

That paper is about implementing branch cuts in a complex-valued function (e.g. complex square root), and doesn’t discuss real square roots.

In the context of that paper it seems to me that √(–0 – 0i) should be 0 – 0i and √(–0 + 0i) should be 0 + 0i, but under no circumstances should the result be –0 ± 0i, which is on the wrong branch.

The obvious extension to real-valued square root would be √(–0) == +0.

In JS:

  -0 + 0;   // 0
  -0 + (-0);  // -0
  -0 - 0;  // -0

I claim that the `-0 + 0` case is the strange inconsistent one, so that's the reason for my WTF label.

----

Consider the counter-argument, that it's intuitive/correct because in math `X + (-X) = 0`:

  3 + (-3);   // 0
  -3 + (3);  // 0
  -0 + (0);   // 0
  0 + (-0);  // 0

It's true that this characteristic by itself is preserved, but where it falls apart:

  X + (-X) = 0    // -->
  X = 0 - (-X)   // -->
  X = 0 + X

That final statement should be true for all X, but as demonstrated above, it's not true for -0.

Reply on news.ycombinator.com