Skip to content
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

Closed
griesemer opened this issue Feb 15, 2019 · 3 comments
Closed

cmd/compile: 0.01i != complex(0, 0.01) at compile time #30243

griesemer opened this issue Feb 15, 2019 · 3 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@griesemer
Copy link
Contributor

griesemer commented Feb 15, 2019

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.)

@griesemer 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
@griesemer griesemer added this to the Unplanned milestone Feb 15, 2019
@griesemer griesemer self-assigned this Feb 15, 2019
@cherrymui
Copy link
Member

FWIW, gccgo evaluates this to true.

@dpinela
Copy link
Contributor

dpinela commented Feb 17, 2019

imag(0.01i) - 0.01 evaluates to -2.032879e-022i, as well.

@gopherbot
Copy link

Change https://golang.org/cl/163000 mentions this issue: cmd/compile: don't mix internal float/complex constants of different precision

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>
@golang golang locked and limited conversation to collaborators Feb 19, 2020
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.
Projects
None yet
Development

No branches or pull requests

4 participants