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: 0.01i != complex(0, 0.01) at compile time #30243
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
griesemer
added
the
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
label
Feb 15, 2019
FWIW, gccgo evaluates this to true. |
|
Change https://golang.org/cl/163000 mentions this issue: |
nebulabox
pushed a commit
to nebulabox/go
that referenced
this issue
Feb 20, 2019
…precision There are several places where a new (internal) complex constant is allocated via new(Mpcplx) rather than newMpcmplx(). The problem with using new() is that the Mpcplx data structure's Real and Imag components don't get initialized with an Mpflt of the correct precision (they have precision 0, which may be adjusted later). In all cases but one, the components of those complex constants are set using a Set operation which "inherits" the correct precision from the value that is being set. But when creating a complex value for an imaginary literal, the imaginary component is set via SetString which assumes 64bits of precision by default. As a result, the internal representation of 0.01i and complex(0, 0.01) was not correct. Replaced all used of new(Mpcplx) with newMpcmplx() and added a new test. Fixes golang#30243. Change-Id: Ife7fd6ccd42bf887a55c6ce91727754657e6cb2d Reviewed-on: https://go-review.googlesource.com/c/163000 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
nebulabox
pushed a commit
to nebulabox/go
that referenced
this issue
Feb 20, 2019
…precision There are several places where a new (internal) complex constant is allocated via new(Mpcplx) rather than newMpcmplx(). The problem with using new() is that the Mpcplx data structure's Real and Imag components don't get initialized with an Mpflt of the correct precision (they have precision 0, which may be adjusted later). In all cases but one, the components of those complex constants are set using a Set operation which "inherits" the correct precision from the value that is being set. But when creating a complex value for an imaginary literal, the imaginary component is set via SetString which assumes 64bits of precision by default. As a result, the internal representation of 0.01i and complex(0, 0.01) was not correct. Replaced all used of new(Mpcplx) with newMpcmplx() and added a new test. Fixes golang#30243. Change-Id: Ife7fd6ccd42bf887a55c6ce91727754657e6cb2d Reviewed-on: https://go-review.googlesource.com/c/163000 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
https://play.golang.org/p/J7WmCozLr4T
Despite the inexact representation of 0.01, both 0.01i and complex(0, 0.01i) should do the same inexact computations. I would expect the compile time comparison to evaluate to true (complex() of compile-time constants returns a compile-time constant, too).
Instead there is a difference of -2.032879e-022i when subtracting the numbers.
Investigate.
(Assigning to me so I don't forget this, but anyone else is welcome to pick this up.)
The text was updated successfully, but these errors were encountered: