cmd/compile, runtime: complex (-1+0i)/0.0 results in +inf

[martisch]

at least go1.4, go 1.6, go tip

found this writing fmt tests for float formatting.
But i do not think this time its a formatting error:

https://play.golang.org/p/UonwOD_TT3

package main
func main() {
    v := -1+0i
    print(real(v)/0.0) // float 0 division
    print(" vs ")
    print(real(v/0.0)) // complex 0 division
    print("\n")
}

Output:

-Inf vs +Inf

would have expected -Inf for the complex case too.

[martisch]

CC @griesemer

[martisch]

if this is considered a bug it can be fixed in runtime/complex.go
in complex128div function in this if branch:

case real(d) == 0 && imag(d) == 0:
        if real(n) == 0 && imag(n) == 0 {
            return complex(nan(), nan())
        } else 

returning

return complex(neginf(), neginf())

when needed.

There might be some other edge cases here that need there own case distinctions.
And other parts of the library were inf cases for complex values are not correct.

If this is considered/confirmed a bug i like to submit a patch for this.

[griesemer]

Definitively a bug: imag(v) is 0, so there should be no difference between (-1+0i)/0.0 and -1/0.0 (executed at runtime). The result should be -Inf.

[griesemer]

PS: The spec doesn't really specify what should happen in these cases, but since the implementation doesn't panic in these cases (div by 0) and produces +/-Inf values, it should be consistent.

[martisch]

Since as you say the spec does not specify any of this i was unsure if this was considered a bug.
But i also would find it weird if a 0 imag part complex would behave different than a float. Also other cases correctly produce -inf so it would make the whole complex arithmetic a bit inconsistent.

Will craft a patch and look around if this issue happens elsewhere.

[ianlancetaylor]

For the record, gccgo prints -Inf vs -Inf.

[martisch]

@ianlancetaylor
thanks. i have a look at gccgo how other cases such as (-1+1i)/0 are handled there too.

[randall77]

I'm not sure this is a bug. Unlike reals, there are many directions you can go to get to infinity, not just two. Having -1/0 go to -Inf and all other numerators/0 go to +Inf seems non-symmetrical.

What should the return values be in these cases? http://play.golang.org/p/POOTEwRIxp

[griesemer]

@randall77 Point taken for all the other complex values. But for a value z where imag(z) == 0, we have at least a consistency issue in the compiler here - it does seem odd that we wouldn't get the same result as for the identical value of real type. As mentioned before, the spec doesn't really specify the result.

[martisch]

Complex arithmetic with 0 and -inf/+inf has definitely some weird behavior overall even with imag parts 0:
((1.0+0i)/zero)*((1.0+0i)/zero)
is (NaN+Infi)

i would just suggest to make those (imag(z)==0) consistent with float behavior.

[cldorian]

The answer is correct. Look at the Wikipedia entry: https://en.wikipedia.org/wiki/Infinity#Complex_analysis

[griesemer]

@cldorian Interesting. Thanks for the link. I've definitively forgotten my complex analysis...

So, for any complex number, z/0 would be +Inf (+Inf + 0i to be precise), except when z = 0 itself, in which case it's (probably) NaN + NaNi?