[_getify]

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.

[jacobolus]

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

[_getify]

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.

[dnautics]

-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

[jacobolus]

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.

[detaro]

IEEE 754 says √–0 is –0 though.

[jacobolus]

Ah really? What is the purpose of that?

[detaro]

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 ;)