Date: Fri, 17 Sep 2021 09:40:52 +0200
On Thursday, 16 September 2021 23:42:56 CEST Jens Maurer wrote:
> On 16/09/2021 23.00, Matthias Kretz via Liaison wrote:
> > After reading Section 8 "Conversions" in N2601 (WG14),
Oh, I was actually reading the TS document (Part 3) ...
> > I believe
> > std::floatN_t and _FloatN need to be distinct types anyway. P1467R4 says
> > "The proposed usual arithmetic conversions when mixing different
> > floating-point types are>
> > essentially the same in both languages". But I read it differently:
> > float + _Float32 -> _Float32
> > float + std::float32 -> float.
>
> Not good.
>
> Remarkably, the result for "double" seems to be the other way round under
> N2601:
>
> double + _Float64 = double
>
> per section X.4.2 (page 10 line 17).
No, line 11 should take precedence. _Float64 is an interchange floating type,
so "the other operand is converted, without change of type domain, to a type
whose corresponding real type is that same interchange floating type".
I read N2601 to do the following (assuming float and _Float32 as well as
double and _Float64 have equivalent sets of values):
float + _Float32 -> _Float32
double + _Float64 -> _Float64
float + _Float64 -> _Float64
double + _Float32 -> double
if the sets of values of _Float64x and long double are equivalent:
long double + _Float64x -> long double
if the sets of values of _Float64x and double are equivalent:
double + _Float64x -> double
> > Would it be an option to keep _Float32 and std::float32 distinct types?
>
> That seems unhelpful. If those types have the same properties
> (i.e. represent IEEE interchange types), they should be the
> same from a type system perspective.
Do I read X.6 [2] correctly that all _Float* types must fully support NaN and
Inf? Whereas P1467 intends to leave NaN and Inf support implementation-
defined? Consequently, a feature like -ffinite-math-only would have to disable
Annex X support in the compiler / only apply to "standard floating types"?
C and C++ may be defining the same types in terms of binary representation.
But the C and C++ committees might have different semantics in mind. If I
understand the C specification correctly, we should probably have a dedicated
meeting about floating-point semantics where we invite the C FP group ...
> On 16/09/2021 23.00, Matthias Kretz via Liaison wrote:
> > After reading Section 8 "Conversions" in N2601 (WG14),
Oh, I was actually reading the TS document (Part 3) ...
> > I believe
> > std::floatN_t and _FloatN need to be distinct types anyway. P1467R4 says
> > "The proposed usual arithmetic conversions when mixing different
> > floating-point types are>
> > essentially the same in both languages". But I read it differently:
> > float + _Float32 -> _Float32
> > float + std::float32 -> float.
>
> Not good.
>
> Remarkably, the result for "double" seems to be the other way round under
> N2601:
>
> double + _Float64 = double
>
> per section X.4.2 (page 10 line 17).
No, line 11 should take precedence. _Float64 is an interchange floating type,
so "the other operand is converted, without change of type domain, to a type
whose corresponding real type is that same interchange floating type".
I read N2601 to do the following (assuming float and _Float32 as well as
double and _Float64 have equivalent sets of values):
float + _Float32 -> _Float32
double + _Float64 -> _Float64
float + _Float64 -> _Float64
double + _Float32 -> double
if the sets of values of _Float64x and long double are equivalent:
long double + _Float64x -> long double
if the sets of values of _Float64x and double are equivalent:
double + _Float64x -> double
> > Would it be an option to keep _Float32 and std::float32 distinct types?
>
> That seems unhelpful. If those types have the same properties
> (i.e. represent IEEE interchange types), they should be the
> same from a type system perspective.
Do I read X.6 [2] correctly that all _Float* types must fully support NaN and
Inf? Whereas P1467 intends to leave NaN and Inf support implementation-
defined? Consequently, a feature like -ffinite-math-only would have to disable
Annex X support in the compiler / only apply to "standard floating types"?
C and C++ may be defining the same types in terms of binary representation.
But the C and C++ committees might have different semantics in mind. If I
understand the C specification correctly, we should probably have a dedicated
meeting about floating-point semantics where we invite the C FP group ...
-- ──────────────────────────────┬──────────────────────────────────────────── Dr. Matthias Kretz │ SDE — Software Development for Experiments Senior Software Engineer, │ 📞 +49 6159 713084 SIMD Expert, │ 📧 m.kretz_at_[hidden] ISO C++ Committee Member │ 🔗 mattkretz.github.io ──────────────────────────────┴──────────────────────────────────────────── GSI Helmholtzzentrum für Schwerionenforschung GmbH Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528 Managing Directors / Geschäftsführung: Professor Dr. Paolo Giubellino, Dr. Ulrich Breuer, Jörg Blaurock Chairman of the GSI Supervisory Board / Vorsitzender des GSI-Aufsichtsrats: Ministerialdirigent Dr. Volkmar Dietz
Received on 2021-09-17 02:41:00