Allow ties in floating literals #866
Conversation
github-actions
bot
added
the
proposal rfc
|
Needs a summary, but otherwise seems good and I think uncontroversial. |
| ... because the literal arithmetic would be performed exactly, resulting in the | ||
| same tie. A workaround such as | ||
|
|
||
| ``` | ||
| var v1: f32 = 5.0e22 + 1.0; | ||
| var v2: f32 = 5.0e22 - 1.0; | ||
| ``` | ||
|
|
||
| ... to request rounding upwards and downwards, respectively, would work. | ||
| However, these seem cumbersome and burden the Carbon developer with | ||
| floating-point minutiae about which they very likely do not care. |
There was a problem hiding this comment.
FWIW, I actually think math between floating point literals is even more important than just removing another way to write this... It seems likely to make it much more likely to encounter. It may not be reasonable to somehow change arithmetic to not produce evenly between values.
Anyways, not disagreeing, just suggesting its even better motivated.
There was a problem hiding this comment.
Yeah, I agree that working around such things will be awkward. On the other hand, we'd still need to refute the statistical argument from #143, that such exact ties are unlikely to come up by chance if your computation doesn't put heavy skew into the distribution of resultant mantissas. I don't think it's going to be all that hard to contrive a computation where that'd happen, but I think such easy-to-find examples are likely to amount to computing one of the simple base-10 values that hit this problem or a variant of one of those.
There was a problem hiding this comment.
(discussed, and fine to move forward as is for now)
github-actions
bot
added
proposal accepted
Allow ties in floating-point literals, and round them to even, per the default IEEE rounding mode rules.
The rule from #143 that we should reject such cases turns out to reject reasonable code, such as: