-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile, runtime: complex (-1+0i)/0.0 results in +inf #14644
Comments
CC @griesemer |
if this is considered a bug it can be fixed in runtime/complex.go
returning
when needed. There might be some other edge cases here that need there own case distinctions. If this is considered/confirmed a bug i like to submit a patch for this. |
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. |
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. |
Since as you say the spec does not specify any of this i was unsure if this was considered a bug. Will craft a patch and look around if this issue happens elsewhere. |
For the record, gccgo prints |
@ianlancetaylor |
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 |
@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. |
Complex arithmetic with 0 and -inf/+inf has definitely some weird behavior overall even with imag parts 0: i would just suggest to make those (imag(z)==0) consistent with float behavior. |
The answer is correct. Look at the Wikipedia entry: https://en.wikipedia.org/wiki/Infinity#Complex_analysis |
@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? |
Should complex +Inf be treated as an unsigned infinity in the Riemann sphere model of the extended complex plane then https://en.wikipedia.org/wiki/Riemann_sphere ? Because if +Inf is correct for (-1+0i)/0.0 by that view the other operations may not be consistent e.g. inf+inf and inf*inf. |
@robert -- If you review the source code for cmplx.IsInf and cmplx.IsNan, @martin -- I don't understand the questions you've posed. Perhaps you could On Fri, Mar 4, 2016 at 2:00 PM, Martin Möhrmann notifications@github.com
|
@robert -- Sorry, I misspoke. The "+Inf + 0i to be precise" is wrong. There On Fri, Mar 4, 2016 at 2:33 PM, Charlie Dorian cldorian@gmail.com wrote:
|
@cldorian
|
@cldorian |
@martin -- 1. I'm pretty sure the usual computer rules can be followed. So, If you look at the source for cmplx.IsInf(z), you'll see that if either
On Fri, Mar 4, 2016 at 2:44 PM, Martin Möhrmann notifications@github.com
|
@martin -- Yes. If z is (+inf+0) and w is (-inf+0), it is true that On Fri, Mar 4, 2016 at 4:16 PM, Charlie Dorian cldorian@gmail.com wrote:
|
Thanks for the explanations. Under this model the behavior seems fine to me now. However the question remains if it would be fruitful to change the behavior to -inf (which would still be correct) so that complex operations with imag(z)==0 behave the same as floats which would be less surprising (at least to me) and compatible e.g. with gccgo. |
I'm rather surprised by this bug, because we have a test (test/cmplxdivide.go) However, now that I take a closer look at the test, it's actually not correct. If I strengthen the test so that both the real and imag parts must match C's BUG I always thought our complex arithmetic matches C99's, but (According to comments in runtime/complex.go, I think the |
Do we believe that C gets this right? If so, I'm somewhat in favor of Or we should at least give it a try and see what goes "boom!" On Fri, Mar 4, 2016 at 10:20 PM, Minux Ma notifications@github.com wrote:
|
Let's ask those people. I doubt there are many. |
@minux Ma -- You're revisiting 2010, when the tests were initially For a more recent conservation about complex infinity, see G.5.1, paragraph 4: The * and / operators satisfy the following infinity properties for all On Fri, Mar 4, 2016 at 10:20 PM, Minux Ma notifications@github.com wrote:
|
I found this CL (https://codereview.appspot.com/1666048)
where Russ fixed the table for some of the results that
gcc got wrong (NaN/0).
And from https://golang.org/cl/1686044, it's explicit mentioned
that Go's complex division is intended to match C99's.
I also tried icc, and icc doesn't agree with gcc on most of
the corner cases (whereas gcc and clang agree with each
other, which is not unexpected, as they both use libgcc's
__divdc3).
For example, icc thinks that:
-1+0i / 0+0i = -nan, -nan.
|
We're in the Go 1.7 freeze now and limiting work to low-risk, high-reward changes. This bug has been in multiple past Go releases and is a bit of a corner case, so it's OK to have in one more and avoid any risk of breaking something else (like more common divisions). |
Talking to a complex analysis expert, the Riemann sphere (mentioned by @martisch above) is indeed a useful tool to deal with infinity, and all infinities are mapped to a single point at the top of the sphere (the "north pole"). Or in other words, +Inf and -Inf are indistinguishable using this model. Whether this is the correct approach in a computational (rather than mathematical) environment is a different question. We should talk to an expert in the field of complex numerics for an authoritative answer. |
I'd like to match the C/C++ standards here. If someone can make the case that Go disagrees with those, then we should fix it. But probably not for this round. |
Working on this and made a CL at http://golang.org/cl/37441 Needs documentation and benchmark before review can start. |
CL https://golang.org/cl/37441 mentions this issue. |
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
Output:
would have expected -Inf for the complex case too.
The text was updated successfully, but these errors were encountered: