[basic.fundamental] It is unclear what values a floating-point type may represent

[eisenwave]

Reference (section label): [basic.fundamental]

See cplusplus/draft#8554 for prior discussion

Issue description

While library wording such as in [numeric.limits.members] mentions various possible values for floating-point types, the specific requirements for what a floating-point type may represent are not obvious. In particular:

• Can there be an unsigned zero, infinity, or NaN value?
• Conversely, can there be a signed zero, infinity, or NaN value?
• Can there be a negative zero and an unsigned infinity, or is the "signedness requirement" all-or-none?
• Can an extended floating-point type be so imprecise that it is incapable of representing any number? That is, could an infinity-t type in the style of nullptr_t be considered a floating-point type?

The intended model (matching C23) is for some numbers to be representable, while non-finite values are individually signed or unsigned.

Suggested resolution

Immediately prior to [basic.fundamental] paragraph 13, insert a new paragraph:

A floating-point type shall at least represent a subset of rational numbers.
Depending on the implementation-defined value representation for the type, it may additionally represent the non-finite values

• infinity,
• a set of quiet "Not a Number" values,
• a set of signaling "Not a Number" values, and
• additional implementation-defined values.

For any of the above (including zero), a floating-point type may either represent a single unsigned value or two distinct values with negative and positive sign.

[Note: A floating-point type which adheres to ISO/IEC 60559 is capable of representing a negative and positive variant of all but the last bullet ([numeric.limits.members]). --end note]

[Halalaluyafail3]

Can an extended floating-point type be so imprecise that it is incapable of representing any number? That is, could an infinity-t type in the style of nullptr_t be considered a floating-point type?

I think this can be assumed to be invalid, it would break value initialization and the definition of numeric_limits. Specifically, std::numeric_limits<infinity-t>::max() has to be a finite value.

A floating-point type shall at least represent a nonempty subset of rational numbers which includes zero.

I think this should mention more than just zero. For example what does std::numeric_limits<T>::epsilon() mean for a type that can only represent zero?

Depending on the implementation-defined value representation for the type, it may additionally represent the non-finite values

• infinity,
• a set of quiet "Not a Number" values, and
• a set of signaling "Not a Number" values.

The way this is worded seems to imply that this is an exhaustive list, which C23 doesn't state as far as I understand.

Also, I think it's worth mentioning that the C23 support for unsigned infinities is pretty weird or not well thought out. isinf is only specified to recognize positive or negative infinities, so presumably isinf(INFINITY) must be zero if unsigned infinities are supported. Unsigned infinities also aren't specified to affect the range of representable values, so presumably out of bounds casts (to the floating point type) are UB instead of needing to result in unsigned infinity.

[eisenwave]

Can an extended floating-point type be so imprecise that it is incapable of representing any number? That is, could an infinity-t type in the style of nullptr_t be considered a floating-point type?

I think this can be assumed to be invalid, it would break value initialization and the definition of numeric_limits. Specifically, std::numeric_limits<infinity-t>::max() has to be a finite value.

A floating-point type shall at least represent a nonempty subset of rational numbers which includes zero.

I think this should mention more than just zero. For example what does std::numeric_limits::epsilon() mean for a type that can only represent zero?

Hmm yeah, I've reverted it to the intentional vagueness that it had in the editorial PR. It would be hard to describe the exact requirements, so we can just let numeric_limits figure that out.

Depending on the implementation-defined value representation for the type, it may additionally represent the non-finite values

• infinity,
• a set of quiet "Not a Number" values, and
• a set of signaling "Not a Number" values.

The way this is worded seems to imply that this is an exhaustive list, which C23 doesn't state as far as I understand.

Concretely, https://cstd.eisie.net/c23.html#5.2.5.3.3.p8 says:

Floating types shall be able to represent signed zeros or an unsigned zero and all normalized floating-point numbers. In addition, floating types may be able to contain other kinds of floating-point numbers, such as subnormal floating-point numbers and unnormalized floating-point numbers, and values that are not floating-point numbers, such as NaNs and (signed and unsigned) infinities.

This wording is just kinda bad and not worth copying. I don't get how any one floating-point type is able to represent "all normalized floating-point numbers", when that is an unbounded set. While the C23 wording isn't exhaustive, if we accepted that there can be even more non-finite values beyond NaNs, I'm sure it would leave holes in the wording in both languages, all over the place.

For example, we have constructors that are preconditioned on "non-negative non-NaN values". If there were non-finite values that are not NaNs but fall into yet another bucket, that wouldn't make sense. Honestly I think it's poor choice of words that the C23 wording sounds non-exhaustive.

Also, I think it's worth mentioning that the C23 support for unsigned infinities is pretty weird or not well thought out. isinf is only specified to recognize positive or negative infinities, so presumably isinf(INFINITY) must be zero if unsigned infinities are supported. Unsigned infinities also aren't specified to affect the range of representable values, so presumably out of bounds casts (to the floating point type) are UB instead of needing to result in unsigned infinity.

Well, ours isn't well thought-out either, assuming we have any, which isn't clear. We have a whole bunch of wording that talks about negative and positive infinities without considering the option of unsigned infinities. However, I don't think we ever intended to disallow unsigned infinities, did we? I guess that's for CWG to figure out.

[Halalaluyafail3]

This wording is just kinda bad and not worth copying. I don't get how any one floating-point type is able to represent "all normalized floating-point numbers", when that is an unbounded set. While the C23 wording isn't exhaustive, if we accepted that there can be even more non-finite values beyond NaNs, I'm sure it would leave holes in the wording in both languages, all over the place.

For example, we have constructors that are preconditioned on "non-negative non-NaN values". If there were non-finite values that are not NaNs but fall into yet another bucket, that wouldn't make sense. Honestly I think it's poor choice of words that the C23 wording sounds non-exhaustive.

All normalized floating-point numbers, for the formula described in section 3 and the constraints described in section 2. Though it seems like your website doesn't correctly display the formula in section 3.

Also even though it does create many problems to have many non-finite values beyond nan and infinity, I do think that it was the intention to allow them.

[eisenwave]

Also even though it does create many problems to have many non-finite values beyond nan and infinity, I do think that it was the intention to allow them.

Can you name an example of where the C standard actually handles these non-inf, non-NaN, non-finite values, instead of just having a hole in the wording?

Does there exist any implementation that has such values?

If the answer is no, I don't see how it could be anything but an editorial slip-up.

[eisenwave]

Hmm actually, https://cstd.eisie.net/c23.html#7.12.p12 mentions that there are additional implementation-defined classifications, and fpclassify can identify those, which we inherit into C++, I suppose.

Well ... this is all getting a bit complicated. I'm not even sure whether CWG can solve the issue of what our degree of support for floating-point numbers is; this is starting to get into SG6 territory.

For now, I'd say that it would leave a massive hole both in core and library wording if we considered the possibility of float being able to represent an unlimited amount of different implementation-defined non-finite categories, so this was never actually supported by C++.

Update

I did a bit of digging, and all I could find is that some implementations have extra functions like fpclass that allow more granular classification such as FP_NANQ and FP_NANS, but I wasn't able to find any mention of entirely separate categories from NaN.

The intent for fpclassify may have been that it can do more granular classification if the implementation wants so, and the paragraph about characteristics is simply non-exhaustive by editorial mistake.

[eisenwave]

I've gotten some more information, and have updated the proposed resolution now.

I've asked both the WG14 FP group chair (Jim Thomas) and strangers on the internet (https://stackoverflow.com/a/79829280/5740428), and the existence of additional implementation-defined categories of values is intentional. In fact, fpclassify on NetBSD/vax may return FP_ROP (reserved operand) (https://man.netbsd.org/NetBSD-10.1/fpclassify.3), which is an entirely distinct classification from NaN and infinities.

Neither ours nor C's wording handles these mythical implementation-defined values very well, but I guess we have those because we inherit fpclassify and other facilities from C, with identical behavior.

[jensmaurer]

I think would prefer to have a short paper, vetted by SG6 and EWG, for this issue and #814 and #817. Such a paper can then highlight the importance (or not) of VAX floating-point support etc.

Floating-point is essentially unspecified in C++, and any departure from that seems directional rather than CWG material.