[Cfp-interest 1711] Re: C++ floating-point work

[Jim Thomas]

David,

We can follow up on this at the CFP meeting today. Some comments below …

- Jim Thomas

> On Jul 21, 2020, at 5:24 PM, David Olsen <dolsen at nvidia.com> wrote:
> 
> Thank you for the feedback.
>  
> >> Would it be possible to write portable dual-language code that uses the C extended floating types (that support the IEEE extended formats)? 
>  
> No.  The C++ proposal doesn’t have anything corresponding to the C extended floating types.  The C++ implementation could support them as C++ extended floating-point types, but there won’t be a portable way to name them in C++.
>  
> How do you expect the IEEE extended formats to be used in real code?  Will enough programmers want to use them that we should standardize them now?

I think extended formats are a good idea, but should say that the 754 community is not of one mind on this. Extended formats are intended for intermediate computation where input and output are in the corresponding basic (interchange) format. Using extra range and precision is arguably the easiest way to avoid intermediate overflow and underflow and mitigate round off error. The alternative of proving that computation in the data format is safe (if in fact it is) is often not practical. Of course, wider interchange formats could be, and often are, used for this purpose, but reasonable implementations will choose the extended formats to be the most efficient ones available with the requisite extra range and precision, making extended formats a good choice for efficient portable code (assuming they’re supported).

The specification for extended floating types provides nomenclature for an implementation wanting to add the 80-bit extended format as an extension.

Extended formats are a feature of IEEE 754. CFP is standardizing extended types as part of its support for IEEE 754.

>  
> >> Saying “For the purpose of conversion, infinity and NaN are treated just like any other numbers” is vague. Are signaling and quiet NaNs separate values? Are all quiet (all signaling) NaNs the same value? Do any significant implementations have unsigned infinity or unsigned zero?
>  
> The statements are intentionally somewhat vague.  I think we will get better results if we leave details of the floating-point formats to the implementations, to do what they think is best for their customers, or to the IEEE standard writers, who are the experts at this. 

IEEE 754 might not be inclined to address an issue that involves non-IEEE formats. For ordering IEEE formats, TS3 uses Specification Level 3 (see 3.2 in IEEE 754).

> I have faith that implementations will (eventually) settle on what is best.  If WG21 were to try to specify too many details about the floating-point types (as opposed to how they interact within the C++ language), we would get things wrong and lock in bad behavior.
>  
> >> Are binary and decimal types ordered if the values of one are a subset of the other? Note that different quantizations of an IEEE decimal value become indistinguishable when converted to IEEE binary.
>  
> As currently worded, it is possible for a decimal type to have a higher conversion rank than a binary type if the binary type’s values are a subset of the decimal type’s values.  (This was discussed on this list a while back, and I don’t recall seeing a clear answer if this will happen in practice.  Can _Decimal128 exactly represent all the values of _Float16?

Yes

> )  I am rethinking this.  I am considering adding wording that says types are unordered if they have different radixes.

What about hexadecimal and binary?
>  
> >> For usual arithmetic conversions, where types have the same values, C TS3 prefers interchange floating types over standard floating types and standard floating types over (C) extended floating types. C++ prefers standard floating types over (C++) extended floating types. 
>  
> Thank you for pointing out this difference.  I hadn’t noticed it.  If I understand correctly, if current proposals are adopted and if _Float64 and double have the same representation:
> C: _Float64 + double -> _Float64
> C++: _Float64 + double -> double

Right.
>  
> Why does C prefer interchange format types over standard types in arithmetic conversions? 

C semantics for standard types are more loosely specified, vs interchange types. TS3 for binary types requires support for Annex F for standard types, so the standard types are essentially equivalent to the corresponding interchange types. If this were to change, so that binary interchange types could coexist with non-IEEE standard types, then the TS3 rules would assure IEEE semantics for operations mixing the two. The C++ proposal doesn’t preclude non-IEEE standard types.

> Does it make a difference?  Is there any way to tell what the result type is in C without using a _Generic construct?

The answer use to be yes. The functions that round to narrower type do not have parameter types for alll combinations of floating types. E.g., no f32add(double, double). Whether a tgmath macro had defined behavior depended on the type determination for the arguments. We recently changed the tgmath rules in TS3 so that the standard and corresponding interchange types can be used interchangeably as arguments. I don’t know if it makes a difference now for C + TS3. 

>  
> >> C doesn’t specify decimal complex types. C++ does. (Just noting.)
>  
> Support for decimal complex types just fell out of the other changes.  It wasn’t an intentional decision.  If I get feedback that decimal complex types are difficult to implement and won’t be used by anyone, then I can add wording to not require support for them, probably by saying that std::complex<T> needs to exist for all binary floating-point types.
>  
>  
> From: Jim Thomas <jaswthomas at sbcglobal.net> 
> Sent: Sunday, July 19, 2020 5:28 PM
> To: David Olsen <dolsen at nvidia.com>
> Cc: CFP <cfp-interest at ucbtest.org>
> Subject: Re: [Cfp-interest 1638] C++ floating-point work
>  
>  
> David, 
>  
> A few comments …
>  
> A new numbered update to N2405 might be available by early Aug.
>  
> Would it be possible to write portable dual-language code that uses the C extended floating types (that support the IEEE extended formats)? 
>  
> Saying “For the purpose of conversion, infinity and NaN are treated just like any other numbers” is vague. Are signaling and quiet NaNs separate values? Are all quiet (all signaling) NaNs the same value? Do any significant implementations have unsigned infinity or unsigned zero?
>  
> Are binary and decimal types ordered if the values of one are a subset of the other? Note that different quantizations of an IEEE decimal value become indistinguishable when converted to IEEE binary.
>  
> For usual arithmetic conversions, where types have the same values, C TS3 prefers interchange floating types over standard floating types and standard floating types over (C) extended floating types. C++ prefers standard floating types over (C++) extended floating types. 
>  
> C doesn’t specify decimal complex types. C++ does. (Just noting.)
>  
> - Jim Thomas
>  
> On Jun 15, 2020, at 11:04 AM, David Olsen <dolsen at nvidia.com <mailto:dolsen at nvidia.com>> wrote:
>  
> I am one of the authors of the C++ proposal P1467 “Extended floating-point types”, which has similar goals to the _FloatN work that CFP is doing, in that it adds additional optional floating-point types to the standard.  The next revision of the proposal is available, https://isocpp.org/files/papers/P1467R4.html <https://isocpp.org/files/papers/P1467R4.html> (and also attached to this message).  I welcome any feedback that CFP might have, especially about the “C Compatibility” section,https://isocpp.org/files/papers/P1467R4.html#c-compat <https://isocpp.org/files/papers/P1467R4.html#c-compat> .  Am I representing the C proposal correctly?  Are there other incompatibilities between the C and C++ proposals that I am not seeing?  The C++ Committee would like to do a better job than we have in the recent past of keeping C and C++ from diverging unnecessarily, so we are soliciting feedback from the C community while C++ proposals are still under development when there is overlap between C and C++.
>  
> --
> David Olsen
> NVIDIA HPC Compiler Team, WG21 member
> Portland, Oregon
>  
> <p1467r4.html>_______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net <mailto:Cfp-interest at oakapple.net>
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest <http://mailman.oakapple.net/mailman/listinfo/cfp-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20200722/bd29d094/attachment-0001.htm>