<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Thank you for the feedback.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Would it be possible to write portable dual-language code that uses the C extended floating types (that support the IEEE extended formats)? <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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++.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> 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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> 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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> 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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<p class="MsoNormal">C: _Float64 + double -> _Float64<o:p></o:p></p>
<p class="MsoNormal">C++: _Float64 + double -> double<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> C doesn’t specify decimal complex types. C++ does. (Just noting.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Jim Thomas <jaswthomas@sbcglobal.net> <br>
<b>Sent:</b> Sunday, July 19, 2020 5:28 PM<br>
<b>To:</b> David Olsen <dolsen@nvidia.com><br>
<b>Cc:</b> CFP <cfp-interest@ucbtest.org><br>
<b>Subject:</b> Re: [Cfp-interest 1638] C++ floating-point work<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">David, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A few comments …<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A new numbered update to N2405 might be available by early Aug.
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Would it be possible to write portable dual-language code that uses the C extended floating types (that support the IEEE extended formats)? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">C doesn’t specify decimal complex types. C++ does. (Just noting.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- Jim Thomas<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 15, 2020, at 11:04 AM, David Olsen <<a href="mailto:dolsen@nvidia.com">dolsen@nvidia.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">I am one of the authors of the C++ proposal P1467 “Extended floating-point types”, which has similar goals to the _Float<i>N</i><span class="apple-converted-space"> </span>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,<span class="apple-converted-space"> </span><a href="https://isocpp.org/files/papers/P1467R4.html">https://isocpp.org/files/papers/P1467R4.html</a><span class="apple-converted-space"> </span>(and
also attached to this message). I welcome any feedback that CFP might have, especially about the “C Compatibility” section,<a href="https://isocpp.org/files/papers/P1467R4.html#c-compat">https://isocpp.org/files/papers/P1467R4.html#c-compat</a><span class="apple-converted-space"> </span>.
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++.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">--<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">David Olsen<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">NVIDIA HPC Compiler Team, WG21 member<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Portland, Oregon<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><p1467r4.html><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
Cfp-interest mailing list<br>
</span><a href="mailto:Cfp-interest@oakapple.net"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Cfp-interest@oakapple.net</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>