Date: Fri, 17 Sep 2021 23:05:01 +0000
Jorg Brown wrote:
>> That's problematic, depending on the overload-resolution rules for the new floating-point types.
>> [... example with intN_t types ...]
In the early days of P1467 there was a vigorous debate about whether the std::floatN_t types could be typedefs of standard types or not. People pointed out the problems that the interactions between the intN_t types and overloading, and that argument won the day. The std::floatN_t types must be different types than float, double, or long double, similar to how the _FloatN types are different type than float, double, or long double in C. It will be possible to have overloads of both float and std::float32_t. The exact details of overload resolution in P1467 are still being worked out, but overload sets on floating-point types will not run into the same problems that overload sets on integral types currently do.
>> for my purposes I'd want something that corresponded to std::float16, not necessarily _Float16.
std::float16_t in C++ and _Float16 in C are required to have the same representation and same sets of values. If your implementation defines the FLT16_* macros in <float.h>, then you can use them for std::float16_t. Or you could get the information via std::numeric_limits<std::float16_t>. P1467 does not require that C++ implementations define the FLT16_* macros. Those macros will eventually make their way to C++ when the C++ standard library rebases on top of C23.
From: Ext <ext-bounces_at_[hidden]> On Behalf Of Jorg Brown via Ext
Sent: Friday, September 17, 2021 2:11 PM
To: Joseph Myers <joseph_at_[hidden]>
Cc: Jorg Brown <jorg.brown_at_[hidden]>; SG6 numerics <sci_at_[hidden]>; Matthias Kretz <m.kretz_at_[hidden]>; Evolution Working Group mailing list <ext_at_[hidden]>; Jorg Brown via Liaison <liaison_at_[hidden]>
Subject: Re: [isocpp-ext] [wg14/wg21 liaison] Report from the recent C/C++ liaison meeting (SG22); includes new floating point types(!)
On Fri, Sep 17, 2021 at 11:18 AM Joseph Myers <joseph_at_[hidden]<mailto:joseph_at_[hidden]>> wrote:
On Fri, 17 Sep 2021, Jorg Brown via Liaison wrote:
> Something that would make me incredibly happy is if c++23 said that I could
> overload on std::float16, std::float32, std::float64, std::float80, and
> std::float128, and that the basic functions (+-*/, abs, frexp, ldexp) all
> work on those types, regardless of what the CPU natively supports.
> Alternatively, if there were macros I could check that would tell me if
> each of these had support - but it would still have to be guaranteed that
> "float", "long", and "long double" could be passed to my overload, without
> compile error.
In C:
* The types, where they exist, are always distinct, so _Float64, _Float32x
and double are always different types, even if they have the same format.
In C++ terms, that should mean you can overload on the types that exist
without needing to be concerned about the possibility of two of them being
the same.
That's problematic, depending on the overload-resolution rules for the new floating-point types. Consider this overload set and a sample use:
void Overload(const int8_t&);
void Overload(const int16_t&);
void Overload(const int32_t&);
void Overload(const int64_t&);
auto fn() {
int i = 0;
Overload(i);
long l = 0;
Overload(l);
long long ll = 0;
Overload(ll);
}
This causes an ambiguous overload error, because "long" is a distinct type from both "int" and "long long". See https://godbolt.org/z/YqYsvY94v<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgodbolt.org%2Fz%2FYqYsvY94v&data=04%7C01%7Cdolsen%40nvidia.com%7C1035b1656fa74b7dc9e608d97a1fca90%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637675099971073211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VdMgLqCnKpEahNS4u1cAw4XGlcw48J7CVh4wzrruFJw%3D&reserved=0>
* Any of the <float.h> macros can be used to check whether a type exists;
you can use "#ifdef FLT16_MANT_DIG", after including <float.h> to see if
_Float16 is supported, for example. (Note the special case in N2601 about
non-arithmetic interchange format support: FLTN_DIG and FLTN_DECIMAL_DIG
are defined there for if binaryN is supported by the encoding-conversion
functions, even if the _FloatN type isn't supported.)
Hmmm, good point... though of course for my purposes I'd want something that corresponded to std::float16, not necessarily _Float16.
> Looking at the actual details of
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1312.pdf<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn1312.pdf&data=04%7C01%7Cdolsen%40nvidia.com%7C1035b1656fa74b7dc9e608d97a1fca90%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637675099971083216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NTZTJTGKx3NCFdd8H1k%2FZa8faKnmRl77XiT4uQNINkU%3D&reserved=0> , I find one
> thing new and intriguing: "Type-generic macros". Specifically, it says
> that if you include <tgmath.h>, you can write "pow(2, 3.0)" and get the
> double version of pow, and you can write "pow(2, 3.0DD)" and get the
> _Decimal64 version. This is of course common practice in C++, but how does
> C do this without overloads?
C11 and later provide _Generic to allow users to write that sort of macro
themselves (before, it could be done using implementation extensions;
tgmath.h was added in C99).
Thanks, wow I'm out of date about some parts of C. :-(
> Notably, the most glaring need for this is printf. If they are going to
> introduce a pow that does the right thing, how about a type-generic
In C, the strfrom functions (e.g. strfromf128) are provided for the new
types, instead of having any corresponding printf format length modifiers.
Likewise, strtof128 exists instead of any scanf support.
Re: "strfromf128", is that documented anywhere? N1312 doesn't mention it and Google is surprisingly unhelpful... I presume it's just https://man7.org/linux/man-pages/man3/strfromd.3.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman3%2Fstrfromd.3.html&data=04%7C01%7Cdolsen%40nvidia.com%7C1035b1656fa74b7dc9e608d97a1fca90%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637675099971093200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=b7Hyskfdi%2B8o2xLvIcWKVqrETGR99%2FDBUAxV7wQvzeI%3D&reserved=0> but with added types?
-- Jorg
>> That's problematic, depending on the overload-resolution rules for the new floating-point types.
>> [... example with intN_t types ...]
In the early days of P1467 there was a vigorous debate about whether the std::floatN_t types could be typedefs of standard types or not. People pointed out the problems that the interactions between the intN_t types and overloading, and that argument won the day. The std::floatN_t types must be different types than float, double, or long double, similar to how the _FloatN types are different type than float, double, or long double in C. It will be possible to have overloads of both float and std::float32_t. The exact details of overload resolution in P1467 are still being worked out, but overload sets on floating-point types will not run into the same problems that overload sets on integral types currently do.
>> for my purposes I'd want something that corresponded to std::float16, not necessarily _Float16.
std::float16_t in C++ and _Float16 in C are required to have the same representation and same sets of values. If your implementation defines the FLT16_* macros in <float.h>, then you can use them for std::float16_t. Or you could get the information via std::numeric_limits<std::float16_t>. P1467 does not require that C++ implementations define the FLT16_* macros. Those macros will eventually make their way to C++ when the C++ standard library rebases on top of C23.
From: Ext <ext-bounces_at_[hidden]> On Behalf Of Jorg Brown via Ext
Sent: Friday, September 17, 2021 2:11 PM
To: Joseph Myers <joseph_at_[hidden]>
Cc: Jorg Brown <jorg.brown_at_[hidden]>; SG6 numerics <sci_at_[hidden]>; Matthias Kretz <m.kretz_at_[hidden]>; Evolution Working Group mailing list <ext_at_[hidden]>; Jorg Brown via Liaison <liaison_at_[hidden]>
Subject: Re: [isocpp-ext] [wg14/wg21 liaison] Report from the recent C/C++ liaison meeting (SG22); includes new floating point types(!)
On Fri, Sep 17, 2021 at 11:18 AM Joseph Myers <joseph_at_[hidden]<mailto:joseph_at_[hidden]>> wrote:
On Fri, 17 Sep 2021, Jorg Brown via Liaison wrote:
> Something that would make me incredibly happy is if c++23 said that I could
> overload on std::float16, std::float32, std::float64, std::float80, and
> std::float128, and that the basic functions (+-*/, abs, frexp, ldexp) all
> work on those types, regardless of what the CPU natively supports.
> Alternatively, if there were macros I could check that would tell me if
> each of these had support - but it would still have to be guaranteed that
> "float", "long", and "long double" could be passed to my overload, without
> compile error.
In C:
* The types, where they exist, are always distinct, so _Float64, _Float32x
and double are always different types, even if they have the same format.
In C++ terms, that should mean you can overload on the types that exist
without needing to be concerned about the possibility of two of them being
the same.
That's problematic, depending on the overload-resolution rules for the new floating-point types. Consider this overload set and a sample use:
void Overload(const int8_t&);
void Overload(const int16_t&);
void Overload(const int32_t&);
void Overload(const int64_t&);
auto fn() {
int i = 0;
Overload(i);
long l = 0;
Overload(l);
long long ll = 0;
Overload(ll);
}
This causes an ambiguous overload error, because "long" is a distinct type from both "int" and "long long". See https://godbolt.org/z/YqYsvY94v<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgodbolt.org%2Fz%2FYqYsvY94v&data=04%7C01%7Cdolsen%40nvidia.com%7C1035b1656fa74b7dc9e608d97a1fca90%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637675099971073211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VdMgLqCnKpEahNS4u1cAw4XGlcw48J7CVh4wzrruFJw%3D&reserved=0>
* Any of the <float.h> macros can be used to check whether a type exists;
you can use "#ifdef FLT16_MANT_DIG", after including <float.h> to see if
_Float16 is supported, for example. (Note the special case in N2601 about
non-arithmetic interchange format support: FLTN_DIG and FLTN_DECIMAL_DIG
are defined there for if binaryN is supported by the encoding-conversion
functions, even if the _FloatN type isn't supported.)
Hmmm, good point... though of course for my purposes I'd want something that corresponded to std::float16, not necessarily _Float16.
> Looking at the actual details of
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1312.pdf<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn1312.pdf&data=04%7C01%7Cdolsen%40nvidia.com%7C1035b1656fa74b7dc9e608d97a1fca90%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637675099971083216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NTZTJTGKx3NCFdd8H1k%2FZa8faKnmRl77XiT4uQNINkU%3D&reserved=0> , I find one
> thing new and intriguing: "Type-generic macros". Specifically, it says
> that if you include <tgmath.h>, you can write "pow(2, 3.0)" and get the
> double version of pow, and you can write "pow(2, 3.0DD)" and get the
> _Decimal64 version. This is of course common practice in C++, but how does
> C do this without overloads?
C11 and later provide _Generic to allow users to write that sort of macro
themselves (before, it could be done using implementation extensions;
tgmath.h was added in C99).
Thanks, wow I'm out of date about some parts of C. :-(
> Notably, the most glaring need for this is printf. If they are going to
> introduce a pow that does the right thing, how about a type-generic
In C, the strfrom functions (e.g. strfromf128) are provided for the new
types, instead of having any corresponding printf format length modifiers.
Likewise, strtof128 exists instead of any scanf support.
Re: "strfromf128", is that documented anywhere? N1312 doesn't mention it and Google is surprisingly unhelpful... I presume it's just https://man7.org/linux/man-pages/man3/strfromd.3.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman3%2Fstrfromd.3.html&data=04%7C01%7Cdolsen%40nvidia.com%7C1035b1656fa74b7dc9e608d97a1fca90%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637675099971093200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=b7Hyskfdi%2B8o2xLvIcWKVqrETGR99%2FDBUAxV7wQvzeI%3D&reserved=0> but with added types?
-- Jorg
Received on 2021-09-17 18:05:17