Skip to content

cmd/compile: const eval should be exact independent of (mathematically equivalent) expression form (-G=3 option only) #43908

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.

Sign up for GitHub

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

Jump to bottom
Closed
griesemer opened this issue Jan 25, 2021 · 6 comments
Closed

cmd/compile: const eval should be exact independent of (mathematically equivalent) expression form (-G=3 option only) #43908

griesemer opened this issue Jan 25, 2021 · 6 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.17

Comments

@griesemer
Copy link
Contributor

griesemer commented Jan 25, 2021 •
edited
Loading

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).
@griesemer griesemer self-assigned this Jan 25, 2021
@griesemer griesemer added the NeedsFix The path to resolution is known, but the work has not been done. label Jan 25, 2021
@griesemer griesemer added this to the Go1.17 milestone Jan 25, 2021
@griesemer griesemer mentioned this issue Jan 25, 2021
Closed
@gopherbot
Copy link
Contributor

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

@gopherbot
Copy link
Contributor

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

gopherbot pushed a commit that referenced this issue Jan 25, 2021
@griesemer
[dev.typeparams] go/constant: in ToFloat, convert to rational numbers…
3663a43 
…, 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
Member

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

1.727233711018889e-77 1.727233711018889e-77

@griesemer
Copy link
Contributor Author

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

@ianlancetaylor
Copy link
Member

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

@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

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

gopherbot pushed a commit that referenced this issue Jan 26, 2021
@griesemer
[dev.typeparams] go/constant: choose internal float representations m…
d39685e 
…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>
@golang golang locked and limited conversation to collaborators Jan 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.17
Development

No branches or pull requests
3 participants
@ianlancetaylor @griesemer @gopherbot