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: const eval should be exact independent of (mathematically equivalent) expression form (-G=3 option only) #43908

Closed
griesemer opened this issue Jan 25, 2021 · 6 comments
Assignees
Labels
Milestone

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jan 25, 2021

Factored out from #43891 :

package main

import "fmt"

const ulp1 = imag(1i + 2i / 3 - 5i / 3)
const ulp2 = imag(1i + complex(0, 2) / 3 - 5i / 3)

func main() {
	fmt.Printf("%g %g\n", ulp1, ulp2)
}

should print the same value (0) for both ulp1 and ulp2, but currently reports:

0 1.4916681462400413e-154

This happens because go/constant.ToFloat doesn't convert to a rational number when it could, and then we lose mathematical precision.

Note this only happens with when using the -G=3 option (new type checker).

@gopherbot
Copy link

@gopherbot gopherbot commented Jan 25, 2021

Change https://golang.org/cl/286552 mentions this issue: [dev.typeparams] go/constant: in ToFloat, convert to rational numbers, not floats

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Jan 25, 2021

Change https://golang.org/cl/286572 mentions this issue: [dev.typeparams] go/constant: choose internal float representations more consistently

Loading

gopherbot pushed a commit that referenced this issue Jan 25, 2021
…, not floats

Floating-point constants are represented as rational numbers when
possible (i.e., when numerators and denominators are not too large).
If we convert to floats when not necessary, we risk losing precision.

This is the minimal fix for the specific issue, but it's too aggressive:
If the numbers are too large, we still want to convert to floats.
Will address in a separate CL that also does a few related cleanups.

Fixes #43908.

Change-Id: Id575e34fa18361a347c43701cfb4dd7221997f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/286552
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 26, 2021

FYI, gccgo prints the same value twice, but it doesn't print 0. It prints

1.727233711018889e-77 1.727233711018889e-77

Loading

@griesemer
Copy link
Contributor Author

@griesemer griesemer commented Jan 26, 2021

The test case is such that it should pass as long as both values are identical (which they are expected to be).

The compiler now uses exact computations for "small-ish" rational numbers; and only switches to floats when using rational numbers would be too expensive.

Presumably the difference between (the old) values 1.4916681462400413e-154 and 1.727233711018889e-77 stems from cmd/compile using 512 bits of mantissa, while gccgo only uses 256 bits (to be confirmed).

Loading

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 26, 2021

It is certainly true that gccgo currently uses a floating point precision of 256 bits.

Loading

@griesemer griesemer changed the title cmd/compile: const eval should be exact independent of (mathematically equivalent) expression form cmd/compile: const eval should be exact independent of (mathematically equivalent) expression form (-G=3 option only) Jan 26, 2021
@griesemer
Copy link
Contributor Author

@griesemer griesemer commented Jan 26, 2021

This has been fixed in the dev.typeparams branch and already works correctly in the master and dev.regabi branch. Closing.

Loading

@griesemer griesemer closed this Jan 26, 2021
gopherbot pushed a commit that referenced this issue Jan 26, 2021
…ore consistently

go/constant represents a Float constant either as a rational number
(if numerator and denominator are small enough), or, as a "catch-all",
as a arbitrary-precision floating-point number.

This CL cleans up some of these transitions by factoring out more
of the decision logic and documents the rationale between the state
transitions better.

This CL also simplifies some unrelated code that was overly complex.

Updates #43908.

Change-Id: Iccdd2d6b7fb7ed13d68ed5e6d992d1bc56a065bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/286572
Trust: Robert Griesemer <gri@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
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants