Repository navigation
CWG2752 Excess-precision floating-point literals #1584
Description
In C23, floating-point literals (called "constants" there) can be represented with excess precision, meaning a float literal is treated as a double or long double value (without affecting the type system, though).
In C++, there is no such permission.
Both C++ and C permit floating-point computations (including operands) to use excess precision. A footnote hints that a conversion will drop the excess precision (e.g. (float)(314.f/100.f) yields a value with float precision) (like C does), but there is no normative wording to make that happen.
What is the design intent for handling excess-precision floating-point computations in C++?
See CWG2752 for details.
Activity
jfbastien commentedon Sep 24, 2023
SG6 input is desired, please assign to EWG afterwards.
mattkretz commentedon Nov 12, 2023
2023-11-07 SG6 Minutes
Chair: Matthias Kretz
Minute Taker: Philip Craig
Summary
The issue is asking
Nobody in SG6 felt qualified to answer this question from an "original design
intent" perspective. So the question was interpreted as stating design intent
as required by numerics users. There was no consensus for a desired behavior
and it appears that a more thorough exploration in a paper would be necessary
to aid the discussion.
Polls
comparison (without "too much" intermediate rounding)
POLL: C++ should not deviate from C in how floating-point behaves (excess
precision, fp contraction, literals)
# of Participants: 7
Outcome: No consensus for change
Comments: We could really use a paper to make a more informed decision. The
paper would need to explore the consequences of all the different options.
Polls considered, but not taken without a better understanding of the
consequences:
POLL: The C++ standard should allow floating-point contraction into FMAs by
default.
(We disagreed on whether the current wording in [expr.pre] allows fp
contraction. Therefore, there was no clear "status-quo" position.)
POLL: There needs to be a standard-conforming way to control floating-point
contraction.
mattkretz commentedon Nov 19, 2024
#2136 (P3488) is the paper to schedule for this issue.
jfbastien commentedon Nov 20, 2024
Seen in EWG on Wednesday:
Poll: CWG2752 / P3488: Floating-Point Excess Precision,
FLT_EVAL_METHODmust always be0.Result: not consensus
Poll: CWG2752 / P3488: Floating-Point Excess Precision,
FLT_EVAL_METHODcan have any value allowed by C (this poll requires fixing some Core wording).Result: not consensus