You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
POLL: Constant expressions (not constant folding) may not use greater
precision and range than the type. => Reproducibility in constant expressions.
If you need more precision and range use std::float128_t in constant
expressions.
POLL: Literals are always rounded to their types. (Never can a higher
precision and range value be used in subsequent operations. 1.1f + x where x is a double cannot be evaluated as 1.1 + x.)
SF
F
N
A
SA
3
3
0
0
0
# of Participants: 6 Outcome: Strong consensus.
POLL: We should consider not allowing excess precision in runtime
evaluation at all (except if we introduce an "attribute" that controls this, as
documented in 60559). Every binary operation on floating-point is rounded once
to the precision and range of its type (decltype(expr)).
SF
F
N
A
SA
2
3
0
1
0
# of Participants: 6 Outcome: Consensus in favor.
POLL: Excess precision in runtime evaluation should be a permissible
optimization for implementations. The implementation choice of what
intermediate type was used is reflected by FLT_EVAL_METHOD (potentially as a
different trait or with the extended values as defined in C23 Annex H).
SF
F
N
A
SA
1
2
1
2
0
# of Participants: 6 Outcome: No consensus.
POLL: Comparison operators should always round their operands to the
precision and range of their types in case excess precision is used. In
addition to operators we expect the <cmath> comparison functions to have the
same behavior (std::isless(a, b) etc...)
SF
F
N
A
SA
3
0
2
0
1
# of Participants: 6 Outcome: No consensus.
SA: Not worth differing from C in this. x87 does comparison on long double
types.
Activity
mattkretz commentedon Nov 1, 2024
This paper addresses #1584
mattkretz commentedon Nov 19, 2024
P3488R0: Floating-Point Excess Precision
2024-11-19 SG6 Minutes
Chair: Matthias Kretz
Champion: Matthias Kretz
Polls
POLL: Constant expressions (not constant folding) may not use greater
precision and range than the type. => Reproducibility in constant expressions.
If you need more precision and range use std::float128_t in constant
expressions.
# of Participants: 6
Outcome: Strong consensus.
POLL: Constant folding behavior follows runtime evaluation behavior.
# of Participants: 6
Outcome: Strong consensus.
POLL: Literals are always rounded to their types. (Never can a higher
precision and range value be used in subsequent operations.
1.1f + xwherexis adoublecannot be evaluated as1.1 + x.)# of Participants: 6
Outcome: Strong consensus.
POLL: We should consider not allowing excess precision in runtime
evaluation at all (except if we introduce an "attribute" that controls this, as
documented in 60559). Every binary operation on floating-point is rounded once
to the precision and range of its type (
decltype(expr)).# of Participants: 6
Outcome: Consensus in favor.
POLL: Excess precision in runtime evaluation should be a permissible
optimization for implementations. The implementation choice of what
intermediate type was used is reflected by FLT_EVAL_METHOD (potentially as a
different trait or with the extended values as defined in C23 Annex H).
# of Participants: 6
Outcome: No consensus.
POLL: Comparison operators should always round their operands to the
precision and range of their types in case excess precision is used. In
addition to operators we expect the
<cmath>comparison functions to have thesame behavior (
std::isless(a, b)etc...)# of Participants: 6
Outcome: No consensus.
SA: Not worth differing from C in this. x87 does comparison on long double
types.
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
3 remaining items
wg21bot commentedon Dec 18, 2024
P3488R1 Floating-Point Excess Precision (Matthias Kretz)
[-]P3488 Floating-Point Excess Precision[/-][+]P3488 R1 Floating-Point Excess Precision[/+]JeffGarland commentedon Mar 11, 2026
clearly this won't be c++26