-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: asymmetric constant arithmetic leads to hilbert test failure #13472
Comments
This is working as intended, even if unexpected. An analysis follows below. Simplifying the constant operations to the 2 values in question, we get the two expressions:
which are identical mathematically, but produce the observed error if computed with limited precisions:
The results are:
In other words, x/3.0 is not the same as x*(1/3.0):
The difference is:
Doing the constant evaluation as done by the compiler explicitly confirms the result:
Looking at the bits:
shows an error:
|
Since floating-point literals are always rational and the only constant expression operators on floating-points (+, -, *, and /) are closed over the rationals, instead of representing floating point constants as just There would still be cases where values are inexactly represented, but at least expressions like |
We could but it doesn't solve the general problem, and it's yet another number representation. What we have is fine for now. go/constants now transitions transparently from rationals to floats if need be (which is almost never the case). It would be simpler to just plug in that code instead of writing new one. That would give precise answers in probably all realistic cases. |
hilbert.go (attached below) computes the product H*H' of a 4x4 Hilbert matrix H and its inverse H' using constant arithmetic only. The product should be the identity matrix I. The Hilbert matrix is famously ill-conditioned leading quickly to unrecoverable floating-point errors even given the large (but limited) mantissa size used for constant arithmetic by the compiler.
That said, the matrices are symmetric and thus H*H' should lead to a sequence of totally symmetric computations (but for opposite signs). However, this test fails with a non-symmetric error, indicating that the two computations for elements (3, 4) and (4, 3) are not symmetric.
Investigate if this is a compiler or big.Float issue.
The text was updated successfully, but these errors were encountered: