Values of floating-point types

Contents

1. Introduction

The core language wording in the C++ standard does not specify what values a floating-point type may represent. There are a few questions that have no obvious answer:

• Do infinity and NaN exist from a core language perspective?
• Can there be an unsigned zero, infinity, or NaN value, or are all floating-point values signed?
• 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?
• Are negative zero and positive zero distinct values? That is, do they compare equal, and if so, is there an observable difference (beyond looking at the sign bit) between them?
• Is negative zero negative? That is, when a Preconditions element requires a "non-negative" value, is the behavior undefined when negative zero is provided?
• Similarly, are negative infinity and negative NaN negative?
• Is "negative NaN" distinct from "positive NaN", or are these effectively the same NaN values with different "payloads"?
• Are different NaN payloads distinct values? If so, does that imply std::has_unique_object_representations_v<std::float32_t> is true?
• 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?
• Does the core language need to distinguish between normal and subnormal numbers?
• Are there any other possible categories of values beyond finite values, infinity, and NaN?
• What does it mean for a type to adhere to ISO/IEC 60559, as mentioned in std::numeric_limits::is_iec559?
• Is 0.0 positive or negative zero, or is it implementation-defined/unspecified?
• Are arithmetic operations required to preserve the sign of zero?
• How does template argument equivalence work for floating-point types?

Bits of information may be found in various parts of the standard, such as in the concept of "adhering to ISO/IEC 60559", numeric_limits requirements, the inheritance of C features such as std::fpclassify, etc. However, some of these questions are so deeply unclear that a core issue alone wouldn't be sufficient to solve the problem.

The goal of this paper is to answer these questions, not by making any evolutionary changes to the language, but by investigating what the status quo is and turning that into wording.

2. Q&A

In the following subsections, the paper tries to find a good answer to the questions above. These answers are primarily based on the existing wording and on existing implementation practice.

2.1. Do infinity and NaN exist from a core language perspective?

Yes. [basic.fundamental] mentions infinity. While NaN is not mentioned explicitly, numeric_limits::quiet_NaN() implies it.

At the very least, floating-point types may represent

• zero, for zero-initialization to make sense,
• negative zero, since both C and C++ already mention this term many times, and
• infinity, qNaN, and sNan, [numeric.limits] to make sense and to have types that adhere to ISO/IEC 60559.

2.2. Can there be an unsigned zero, infinity, or NaN value, or are all floating-point values signed?

There can be fully unsigned floating-point numbers. The C standard explicitly mentions unsigned infinity and unsigned zero, and different NaN signs are typically not distinct values. The C++ standard presumably inherits the C model because all of the <cmath> functions are stated to work like C23's <math.h>. There is no C++ restriction on fpclassify.

Furthermore, [numeric.limits.members] states that numeric_limits::is_signed is meaningful for all specializations, so there is presumably no requirement that a floating-point type or any of its values are signed.

2.3. Conversely, can there be a signed zero, infinity, or NaN value?

Presumably. The C++ standard mentions negative zero and negative infinity in a number of places. NaN with negative sign bit and NaN with positive sign bit are usually not considered distinct values (e.g. ISO/IEC 60559), but the C++ standard has no wording that would prohibit that distinction.

2.4. Can there be a negative zero and an unsigned infinity, or is the "signedness requirement" all-or-none?

It's not all-or-none. There are floating-point types that adhere to ISO/IEC 60559, and these do not have a distinct negative and positive NaN, so it cannot be all-or-none.

2.5. Is negative zero negative? What about infinity and NaN?

No. The wording uses negative in the less than zero sense ([complex.numbers] polar, complex). The C23 standard defines a negative value to values which are less than zero, so negative zero and negative NaN (NaN with negative sign bit) are not negative.

Negative infinity is negative because it compares less than zero.

2.6. Is negative NaN distinct from positive NaN?

Presumably. While ISO/IEC 60559 does not consider NaNs with different sign bit to be distinct values, the C++ standard does not prohibit such a model.

2.7. Are different NaN payloads distinct values?

Sometimes. numeric_limits::quiet_NaN() and numeric_limits::signaling_NaN() are two NaNs distinguished only by payload. However, not every implementation treats these distinctly. For example, when compiling to WASM, none of the f32 or f64 instructions handle signaling NaNs.

2.8. Can an extended floating-point type have no finite values?

No. This would make zero-initialization unimplementable, and would make numeric_limits members such as epsilon() worded in a nonsensical way.

2.9. Does the core language need to distinguish between normal/subnormal numbers?

No. Subnormals either get flushed to zero, meaning that they are alternative representations of zero, numerically, or they are simply finite numbers like any other. The classification of normal and subnormal is an implementation detail of the floating-point format.

2.10. Are there values beyond finite values, infinity, and NaN?

The exotic and surprising part is that floating-point types may represent additional implementation-defined values beyond finite values, infinity, and NaN. This is backed by

• C23 §5.2.5.3.3 [Characteristics of floating types <float.h>] paragraph 8, and
• C23 §7.12 [Mathematics <math.h>] paragraph 12.

These paragraphs support the existence of such additional implementation-defined classifications. C++ inherits the behavior of fpclassify from <math.h>, so it must support the same classifications to be compatible.

While neither the C23 wording nor the C++ wording handles these extra implementation-defined classifications well, they nonetheless exist, and it seems like an unmotivated breaking change to drop support for them.

2.11. What does it mean for a type to adhere to ISO/IEC 60559?

It just means that the value representation is one of binary16, binary32, binary64, binary128, or some extended or decimal floating-point format specified in ISO/IEC 60559.

When it comes to operations, the C++ standard specifies no mapping between expressions (e.g. /) and the ISO/IEC 60559 operations (e.g. division). In fact, it seems to deliberately deviate from the ISO/IEC 60559 operations by declaring division by zero to be undefined behavior, even for floating-point types ([expr.mul]).

While it would be desirable to align the C++ operations with ISO/IEC 60559 operations, this would require significant wording effort. There exists no core wording that even attempts at doing so. Note that implementations don't always compute results correctly rounded (with the greatest available precision), while the ISO/IEC 60559 operations are usually correctly rounded. Therefore, aligning the C++ expressions with ISO/IEC 60559 may break most implementations.

2.12. Is 0.0 positive or negative zero?

Presumably positive. The C++ standard does not mandate a specific sign for floating-point-literals, but no implementation makes them negative, nor does it make practical sense to do so. We should mandate that literals have no negative sign.

2.13. Are arithmetic operations required to preserve the sign of zero?

Presumably no. While the ISO/IEC 60559 multiplication operation preserves the sign bit when multiplying with 1, the C++ standard does not clearly mandate such behavior.

Especially considering that not every type adheres to ISO/IEC 60559, we should require a specific handling of sign bits, explicitly. For example, the unary - operator should be required to flip the sign bit even for zero, otherwise -0.0 may not be a spelling of negative zero, as users rely on.

2.14. How does template argument equivalence work for floating-point types?

In practice, it is based on bitwise identical values. [temp.type] states that

Two values are template-argument-equivalent if they are of the same type and

• they are of integral type and their values are the same, or
• they are of floating-point type and their values are identical, or
• […]

The distinction between same and identical is not obvious. It was added during C++20 NB comment resolution by [P1907R1], after [P1714R1] (the paper which originally added support for floating-point template parameters) was rejected. The original paper used the terminology identical value representations, which makes the intent obvious, unlike the current wording.

GCC, Clang, and MSVC implement the design of the original paper by mangling the bit-casting to an integer and mangling it into the name.

_Z1fILf7fc00000EEvv:
        ret
_Z1fILf7fc00001EEvv:
        ret

The wording should be clarified to match the design of the original paper and to match what implementations actually do. Creating a distinct instantiation for every bit pattern is the most useful behavior anyway; it would be impossible to deliberately wrap a NaN payload of choice in std::constant_wrapper otherwise, for example.

3. Impact on the standard

The clarify the floating-point specification, a bit of additional wording is required.

This paper only picks the low-hanging fruits, so to speak. In the long run, specifying the handling of NaNs and infinities by C++ expressions, documenting ISO/IEC 60559 conformance, and other large changes may be desirable. However, those would require much greater changes.

4. Impact on implementations

All proposed wording changes document the current behavior of major implementations.

5. Wording

The changes are relative to [N5014].

[lex]

Change [lex.fcon] paragraph 3 as follows:

[basic]

Immediately preceding [basic.fundamental] paragraph 13, insert three new paragraphs:

Immediately preceding [basic.fundamental] paragraph 14, insert a new paragraph:

[expr]

At the end of [expr.pre], insert a new paragraph:

Change [conv.fpint] paragraph 2 as follows:

Change [expr.unary.op] paragraph 8 as follows:

Change [expr.spaceship] paragraph 4 as follows:

Change [expr.rel] paragraph 6 as follows:

Change [expr.eq] paragraph 8 as follows:

[temp]

Immediately preceding [temp.type] paragraph 2, insert a new paragraph:

Change [temp.type] paragraph 2 as follows:

[support]

Change [numeric.limits.members] as follows:

Change [numeric.limits.members] as follows:

Change [cmp.alg] paragraph 2 as follows:

[meta]

Change [meta.unary.prop] paragraph 10 as follows:

6. References