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
spec: typed floating point constant does not match compiler behaviour #4398
Labels
Milestone
Comments
I don't think the spec says typed constant, but it does talk about giving constants a type. Quoting from the section on constants: "A constant may be given a type explicitly by a constant declaration or conversion, or implicitly when used in a variable declaration or an assignment or as an operand in an expression." The section about conversions only mention that the constant must be able to be represented by the type converted to. I say that a caveat be added about the LSBs on floating point types here. |
const x = 4.0 / 3 const y float64 = x In this case, I believe iant's interpretation of the spec would require that compilation not continue, since any finite amount of binary floating point precision could not exactly represent that value. Judicious use of "closest representable approximation" for floats may simplify the wording. |
There are two separate issues: 1) What does it mean for a floating point constant x to be representable by a type T? 2) What does it mean for a floating point constant x to be typed (via a conversion) - specifically, what happens to the constant value. 2) is different from 1) because if T(x) is valid (x is representable by T) and thus x gets "typed" as T, the (compile-time precise) value of x doesn't necessarily need to change. For instance, float32(2.0/3.0), is a typed floating point constant (type is float32), but it could still have the precise value 2.0/3.0 (rather than the "truncated" value that fits into a 32bit float32). I agree that the spec needs to be clearer with respect to these terms. |
In the gc compilers, I treat the constant conversion float64(x) as meaning 'get me an exact float64 for x'. I hope this is in the spec but haven't checked. That explains the gc behavior you saw. It is true that we are a bit fuzzy about 'representable'. I interpret it to mean that rounding is okay but completely out of range values are not (i.e. 1e500 is not representable: it does not round to 1e308 nor does it round to +inf). |
This issue was closed by revision 7576179. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: