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

Comments

Projects
None yet
4 participants
@griesemer
Copy link
Contributor

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 this to the Unplanned milestone Feb 15, 2019

@griesemer griesemer self-assigned this Feb 15, 2019

@cherrymui

This comment has been minimized.

Copy link
Contributor

commented Feb 15, 2019

FWIW, gccgo evaluates this to true.

@dpinela

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2019

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

@gopherbot

This comment has been minimized.

Copy link

commented Feb 17, 2019

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

@gopherbot gopherbot closed this in 041d31b Feb 19, 2019

nebulabox added a commit to nebulabox/go that referenced this issue Feb 20, 2019

cmd/compile: don't mix internal float/complex constants of different …
…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 added a commit to nebulabox/go that referenced this issue Feb 20, 2019

cmd/compile: don't mix internal float/complex constants of different …
…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 join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.