Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
spec: arithmetic on complex numbers is underspecified #29846
I can't find much about the precise behavior of floating point and complex arithmetic (
Would it be possible to better specify the exact behavior of complex numbers, or point to the relevant spec? It appears that IEEE-754 doesn't say anything about complex numbers.
Background: I am working on a compiler for the Go language called TinyGo. I would like to implement complex arithmetic but I'm not sure how it is supposed to be implemented.
Yes, our complex numbers are pretty underspecified.
Complex arithmetic has lots of corner cases. There are multiple versions of infinity (inf+0i, 0+inf*i, etc.) and nans. As far as I know we don't normalize any of these corner cases.
Also the rounding story for complex numbers is unclear. You have to compute floating-point expressions like
For example, based on the compiler source code, it appears that this is how addition is implemented, assuming
return complex(real(a) + real(b), imag(a) + imag(b))
Multiplication appears to be done this way (ignoring widening/narrowing to do the multiplication in
r := real(a) * real(b) - imag(a) * imag(b) i := real(a) * imag(b) + imag(a) * real(b) return complex(r, i)
The spec could list this as pseudo-code, for example. That would make an implementation trivial. Of course, the spec should then also specify whether the widening done here is required or not - because I would want to avoid it in my implementation if it is not absolutely necessary.
When I take a look at the C11 spec regarding complex numbers, the given code is quite big. It takes special care of NaN and Infinity, which the Go compiler appears to completely ignore. So perhaps this is even a bug in the Go compiler, I don't know what the intended behavior is. It certainly shows that the Go language could use some more words regarding how complex numbers ought to work (and if the spec doesn't care about NaN/Inf, that's fine to me, but it should be specified IMHO).