24

Unlike fundamental types – float, double and long double – are the new floatN_t types in <stdfloat> introduced in C++23 going to be always IEEE standard binary floating point types?

The cppreference page for fixed width floating-point does mention the bits of precision and exponent, which matches with IEEE standards. But that page doesn't explicitly mentions about IEEE standards anywhere. IEEE compliant floating points means, they not only should have same bits of precision and exponent, but the standard also lists many operations which have to be supported in a standard compliant way. So do these types strictly follow that?

user2357112
  • 260,549
  • 28
  • 431
  • 505
Sourav Kannantha B
  • 2,860
  • 1
  • 11
  • 35
  • 1
    Doesn't seem that way to me, according to the source you provide: "fixed width floating-point types must be aliases to extended floating point types (not `float` / `double` / `long double`)" – Nox Jan 23 '23 at 09:43
  • 1
    @Nox If at all `floatN_t` were aliases to `float` / `double` / `long double`, then you can say that `floatN_t` are not IEEE because these fundamental types are not guarenteed to be IEEE (although in practice most are). – Sourav Kannantha B Jan 23 '23 at 09:46
  • 2
    Sourav Kannantha B, Even if IEEE standard binary floating point types and operations are specified, complete adherence to the IEEE is really _hard_. Be prepared for 99% compliance and not 100%. – chux - Reinstate Monica Jan 23 '23 at 18:17
  • 2
    Sourav Kannantha B, Also complete adherence to the IEEE does not mean no variability in outcomes among implementations. IEEE allows for some variations in corner cases. So the question: _why_ do you want IEEE compliance? What specific problem are you trying to solve? – chux - Reinstate Monica Jan 23 '23 at 18:39
  • 2
    @chux-ReinstateMonica This was just a 'out-of-curious' question. I am not using `stdfloat` now. But just wanted to know to what extent it was compliant. Similar bit-count was just a coincidence or not? – Sourav Kannantha B Jan 23 '23 at 18:49

2 Answers2

15

Yes. The relevant section from the latest Draft for the C++23 Standard (cited below) makes explicit mention of the ISO/IEC/IEEE 60559 floating-point standard for the float*_t types. That is identical to the IEEE-754 standard according to Wikipedia:

The international standard ISO/IEC/IEEE 60559:2011 (with content identical to IEEE 754-2008) has been approved for adoption through ISO/IEC JTC 1/SC 25 under the ISO/IEEE PSDO Agreement and published.

Here is the first part of the relevant section from the Draft C++23 Standard (the definitions for other 'precision' types are similar):

6.8.3 Optional extended floating-point types    [basic.extended.fp]
1    If the implementation supports an extended floating-point type ([basic.fundamental]) whose properties are specified by the ISO/IEC/IEEE 60559 floating-point interchange format binary16, then the typedef-name std​::​float16_­t is defined in the header <stdfloat> and names such a type, the macro __STDCPP_­FLOAT16_­T__ is defined ([cpp.predefined]), and the floating-point literal suffixes f16 and F16 are supported ([lex.fcon]).
…
(… And similarly for float32_t, float64_t, etc.)

Note: In terms of whether the cited paragraph demands that operations on such a type conform to the IEEE/ISO Standard, I would argue that it does. The "properties" of such variables includes their behaviour, and not just their representation format.

Adrian Mole
  • 49,934
  • 160
  • 51
  • 83
  • 1
    Does anything specify that the bits of floating-point values must be stored with the same endianness as those of integers, so that e.g. the sign bits of a `float64_t` and `int64_t` would be stored in the same place? – supercat Jan 23 '23 at 19:24
  • 1
    Additionally, is there anything that would forbid an implementation from having `float` and `double` types that behave nothing like the IEEE-754 types, but then having a `float64_t` type which is represented in a manner compatible with IEEE-754, and is converted to the native float type whenever it is operated upon? – supercat Jan 23 '23 at 19:26
  • 1
    @supercat To the very best of my knowledge, any dependence on endianness is outside the purview of both the C++ and IEEE standards; that's an entirely different issue. – Adrian Mole Jan 23 '23 at 21:50
  • 1
    @supercat On your second point: Categorically: "No!" (So long as the results of those operations are IEEE compliant.) – Adrian Mole Jan 23 '23 at 21:51
  • 1
    ... the new `std::float*_n` types are distinct and **separate** types (even if they are equivalent). What the Standard dictates for one is not the same as what is required of the other. – Adrian Mole Jan 23 '23 at 21:58
  • 1
    On your first point, I should add, *I think*. It is an interesting point, that warrants further investigation (i.e. what are the "usual arithmetic conversions" when applied to native types mixed with the new standard types). – Adrian Mole Jan 23 '23 at 22:08
  • 1
    Does it say anywhere that if such types are not supported, neither typedef nor macro shall be defined? – Deduplicator Jan 23 '23 at 22:39
  • 1
    @Deduplicator Probably not. But absence of evidence is not evidence of absence: You can't expect the C++ Standard to express all the situations that do *not* conform. – Adrian Mole Jan 23 '23 at 22:43
  • 1
    @AdrianMole You can expect it to express how a conforming implementation should signal (absence of) support for optional parts, like IEEE 60559. – Deduplicator Jan 23 '23 at 22:46
  • 1
    @Deduplicator No. It expresses (quite clearly) that, if such macros/typedefs are defined, then conformance to the Standard is expected. How can you expect any Standard to express that something *might* conform? – Adrian Mole Jan 23 '23 at 22:47
  • 1
    "If and only if type conforming to xyz is supported, typedef x and macro y shall be defined." – Deduplicator Jan 23 '23 at 22:52
  • 1
    With respect, @Deduplicator, this whole, "if and **only** if" argument is way beyond the topic of this particular question/answer. If the relevant macro **is** defined, then you can expect the compiler to conform; if it is *not* defined, then you cannot expect that. – Adrian Mole Jan 23 '23 at 22:56
7

Yes, they are.

[stdfloat.syn] states that

The header defines type aliases for the optional extended floating-point types that are specified in [basic.extended.fp].

In turn, [basic.extended.fp] references types which are specified by ISO/IEC/IEEE 60559 floating-point interchange format

ISO/IEC/IEEE 60559 is the newer version of 754

ChrisMM
  • 8,448
  • 13
  • 29
  • 48