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

[jacobolus]

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.