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

[David Olsen]

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?

>> 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.  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?)  I am rethinking this.  I am considering adding wording that says types are unordered if they have different radixes.

>> 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

Why does C prefer interchange format types over standard types in arithmetic conversions?  Does it make a difference?  Is there any way to tell what the result type is in C without using a _Generic construct?

>> 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 (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 .  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20200722/3ed01eca/attachment-0001.htm>