<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=us-ascii">
<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;
        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.EmailStyle20
        {mso-style-type:personal-compose;
        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" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">>> How specifically would this help?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It keeps things more consistent when porting between conforming implementations that have different formats for long double.  The code can rely on the result type being long double everywhere (unless porting to an unusual non-conforming
 compiler that has IEEE 64-bit but long double is smaller than 64 bits, in which case this will be the least of their concerns).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It also matches my conceptual ranking of the types.  _Float64 is conceptually the same size as double (because on conforming implementations they have to be the same format), and long double is always conceptually bigger than double (even
 if they happen to be the same format).  That means long double is conceptually bigger than _Float64, even if they happen to be the same format.  This is the reasoning that I used for C++ when writing P1467.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> There’s still the issue of long double arithmetic possibly being less robust than _Float64.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think consistency among conforming implementations should be valued more than improving the experience on non-conforming implementations.  We should of course try for both, but in this case I think they are in conflict.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Are you suggesting that there be a special rule that applies only to long double + _Float64 when they have the same formats?<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">Yes.  There would be a special rule that, when the sets of values are equivalent, the result type of long double + _Float64 would be long double.  I can’t think of a better way to specify it given how the arithmetic conversion rules are
 defined.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m not going to stress about this.  I can’t think of any way that code that will compile as both C and C++ can tell the difference.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">(My apologies for not replying in time for this morning’s teleconference.  If that means I missed my chance to advocate for this change, oh well.)<o:p></o:p></p>
<p class="MsoNormal"><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> Cfp-interest <cfp-interest-bounces@oakapple.net>
<b>On Behalf Of </b>Jim Thomas<br>
<b>Sent:</b> Sunday, October 24, 2021 2:26 PM<br>
<b>To:</b> CFP <cfp-interest@ucbtest.org><br>
<b>Subject:</b> [Cfp-interest 2243] Re: Usual arithmetic conversions for long double and _FLoat64<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Oct 17, 2021, at 9:20 PM, 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>
<p class="MsoNormal">On an implementation where<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">double</span>,<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long double</span>, and<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">_Float64</span><span class="apple-converted-space"> </span>all
 have the same format of IEEE 64-bit, what is the result type of an operation with operands of<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long double</span><span class="apple-converted-space"> </span>and<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">_Float64</span>? 
 My reading of the usual arithmetic conversions in section X.4.2 if<span class="apple-converted-space"> </span><a href="https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn2601.pdf&data=04%7C01%7Cdolsen%40nvidia.com%7Cc331e055f85c4b6059b508d99735a5ee%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637707079520388731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1yAzogjKkzKVMVB793tXoHLcabo2i9F1KOcdYb9E6NA%3D&reserved=0"><span style="color:#0563C1">N2601</span></a><span class="apple-converted-space"> </span>is
 that the result type is<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">_Float64</span>, because interchange floating types are preferred over standard floating types when the two types have the same sets of values.  Is my
 interpretation correct?<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Yes.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">I am working on modifying the C++ floating-point proposal P1467 so that the usual arithmetic conversion rules match those in N2601 and C23, as was requested in the joint SG22/CFP meeting.  I am having trouble with this one situation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">On implementations where<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long double</span><span class="apple-converted-space"> </span>is bigger than<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">double</span>,<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long
 double + _Float64 -> long double</span>.  I think the usual arithmetic conversion rules should be consistent so that<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long double + _Float64 -> long double</span><span class="apple-converted-space"> </span>all
 the time, even when<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long double</span><span class="apple-converted-space"> </span>has the same set of values as<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">_Float64</span>. 
 This will help users when porting code between implementations that have different representations for<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long double</span>. <o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">How specifically would this help? There’s still the issue of long double arithmetic possibly being less robust than _Float64.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Is it possible to tweak the usual arithmetic conversion rules in C23 to make this change?
<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Are you suggesting that there be a special rule that applies only to long double + _Float64 when they have the same formats?<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(I believe that<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long double + _Float64</span><span class="apple-converted-space"> </span>is the only combination of standard and interchange floating types
 where the result type can change between conforming implementations.  I guess<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long double + _Float128 -> long double</span><span class="apple-converted-space"> </span>if<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long
 double</span><span class="apple-converted-space"> </span>is bigger than<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">_Float128</span>, but I don’t think any such implementations exist.)<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If long double were double-double then long double and _Float128 would be unordered.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">If all possible C implementation are considered I think there are several exceptions. For example, long double could be narrower than _Float64. (This is not true with strict conformance to the C annex for IEEE floating types.)<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>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(I have no problem with<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">double + _Float64 -> _Float64</span>.  That makes sense, and I have changed the C++ proposal to do that.  It is only<span class="apple-converted-space"> </span><span style="font-family:"Courier New"">long
 double + _Float64</span><span class="apple-converted-space"> </span>that I have an issue with.)<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"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><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;color:#0563C1">Cfp-interest@oakapple.net</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.oakapple.net%2Fmailman%2Flistinfo%2Fcfp-interest&data=04%7C01%7Cdolsen%40nvidia.com%7Cc331e055f85c4b6059b508d99735a5ee%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637707079520398729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Szlmr0i2H0%2B6jXdVqrtOpRi7P96xGb7V9s9nEmR5tzA%3D&reserved=0"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#0563C1">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>