<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><div><font size="2" > <strong>Attendees</strong>: Rajan, Jim, David H., Fred, Mike</font></div>
<div> </div>
<div><font size="2" ><strong> New agenda items:</strong><br> None.</font></div>
<div> </div>
<div><font size="2" ><strong> Carry over action items:</strong><br> Rajan: Forward the IEEE article to WG14 once David H sends it out to us. - Done (sent on July 17th)<br> Jim: Draft a slide deck and a proposal based on CFP1331. - Keep open.<br> <br><strong> Last meeting action items:</strong><br> Jim: Add wording to the CFP1331 proposal make it clear this is for particular evaluation methods, and submit the document to W14. - Done.<br> Jim: Add a statement as to why there is a second name for log1p as a footnote as a new proposal. - Done.<br> Fred: Submit CFP 1340 to WG14. - Done.<br> Jim: Reword CFP 1337 as per action item discussion in the 2019/07/17 meeting. - Done.<br> Jim: Send CFP 1349 to the WG14 reflector as the CFP position. - Done.<br> Fred: Write a paper to make the range error for small nonzero x consistent for expm1, logp1, log10p1's other base functions. - Done.<br> Jim: Add in the normalized discussion from Fred (CFP 1341, CFP 1342) to the agenda for next meeting. - Done.<br> <br><strong> New action items:</strong><br> Jim: Reword CFP1337 to avoid stating standard types with non-power-of-2 bases with hexadecimal still being exact. Submit as an N document.<br> Jim: Respond with needing both NAN and NAN( forms, and what the payload flexibility should be.<br> Fred: Rewrite the proposed CFP1360 paper using the CFP recommendations.<br> Jim: Discuss the namespace issue next meeting.<br> Jim: For the FLT_EVAL_METHOD example, add _Float16 in since it can show that evaluation to type is not always true.</font></div>
<div><br><font size="2" ><strong> Next Meeting(s):</strong><br> Wednesday, September 18th, 2019, 11:00 EST, 8:00 PST, 4PM UTC<br> Same teleconference number.<br> Please notify the group if this time slot does not work.</font></div>
<div><font size="2" > David H may be on call for Jury duty.<br> Fred can't make it (in Africa!)</font></div>
<div> </div>
<div><font size="2" ><strong> Discussion:</strong><br> 754 revision:<br> No public comment yet requiring a response.<br> New editor for the next revision but no chair. New starter kit for editor will be sent out to people like Jim.<br> For IEC, they need to make the first move. David H. will check with the IEEE contact on how that starts.</font></div>
<div> </div>
<div><font size="2" > C++ Liaison:</font></div>
<div><font size="2" > Nothing.<br> </font></div>
<div><font size="2" > C2X integration:<br> Draft with TS 1, 2, and 4a<br> Part 3<br> The above parts will likely come out as an N doc soon from Jens.<br> Part 4b - Looking as an updated TS.<br> Part 5a,b,c,d</font></div>
<div> </div>
<div><font size="2" ><strong> Action item details:</strong><br> Jim: Draft a slide deck based on CFP1331 (http://wiki.edg.com/pub/CFP/WebHome/C2x_proposal_-_TS_18661-5abc-20190709.pdf)<br> Not done.</font></div>
<div> </div>
<div><font size="2" > Jim: Add wording to the CFP1331 proposal make it clear this is for particular evaluation methods, and submit the document to W14 (http://wiki.edg.com/pub/CFP/WebHome/n2407.pdf)<br> Looks good.</font></div>
<div> </div>
<div><font size="2" > Jim: Add a statement as to why there is a second name for log1p as a footnote as a new proposal (http://wiki.edg.com/pub/CFP/WebHome/C2x_proposal_-_why_logp1-20190719.pdf)<br> Looks good.</font></div>
<div> </div>
<div><font size="2" > Fred: Submit CFP 1340 to WG14 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2406.htm)<br> Looks good.</font></div>
<div> </div>
<div><font size="2" > Jim: Reword CFP 1337 as per action item discussion in the 2019/07/17 meeting (See CFP 1371)<br> Fred: Since standard floating types could be base 10 for example, hexadecimal floating constants would still round.<br> *AI*: Jim to reword CFP1337 to avoid stating standard types with non-power-of-2 bases with hexadecimal still being exact. Submit as an N document.</font></div>
<div> </div>
<div><font size="2" > Jim: Send CFP 1349 to the WG14 reflector as the CFP position. See SC22WG14.16914 and SC22WG14.16919 (See also CFP 1373, 1374)<br> Rajan: z/OS XL C and C++ both use the NAN( form so it cannot be obsolesced.<br> *AI*: Jim: Respond with needing both NAN and NAN( forms, and what the payload flexibility should be.</font></div>
<div> </div>
<div><font size="2" > Fred: Write a paper to make the range error for small nonzero x consistent for expm1, logp1, log10p1's other base functions (See CFP 1357, 1360)<br> Jim: As a CFP recommendation, we could say add finite.<br> For the second issue of negative numbers, we could say things like abs(x) or say magnitude. We should avoid ambiguity.<br> Fred: Both large and small are ambiguous.<br> Jim: Whenever we mean magnitude, we say magnitude.<br> Mike: Are you saying when it cannot be encoded?<br> Fred: No, this is an argument, a domain, which is encoded.<br> David: "magnitude of positive finite x is too large" should be used if that's what we mean. May be a large change.<br> This is the CFP recommendation as well ("magnitude of positive finite x").<br> *AI*: Fred: Rewrite the proposed CFP1360 paper using the CFP recommendations.<br> <br> Jim: Add in the normalized discussion from Fred (CFP 1341, CFP 1342) to the agenda for next meeting.<br> What does “normalized” mean in C? (See CFP 1380)<br> David: Instead of 'contained', should you use 'represent'?<br> Jim: 'Contains' is what is there now.<br> Fred: Specifically getting rid of unnormalized.<br> Jim: Yes, that is a representation.<br> Fred: That gets rid of a lot of DFP numbers (f1 = 0 but not sub-norms)<br> Jim: No, but they can all be normalized.<br> Fred: Epsilons go back to being ambiguous. Ex. double-double.<br> Jim: No, that is outside the model, but allowed.<br> Fred: That is not what you said in the classification/characterization macros.<br> Jim: Let me think about that. NORM_MAX would be the maximum model value.<br> <br> Other issues:<br> Parameter tables for TS 3 formats <a href="http://wiki.edg.com/pub/CFP/WebHome/parameter_tables_for_Annex_N-20190820.pdf" >http://wiki.edg.com/pub/CFP/WebHome/parameter_tables_for_Annex_N-20190820.pdf</a><br> Looks good.</font></div>
<div> </div>
<div><font size="2" > Example for FLT_EVAL_METHOD<br><a href="http://wiki.edg.com/pub/CFP/WebHome/Example_for_FLT_EVAL_METHOD-20190815.pdf" >http://wiki.edg.com/pub/CFP/WebHome/Example_for_FLT_EVAL_METHOD-20190815.pdf</a><br> Rajan: Not worth change in practice.<br> Is there a case where the blanket prohibition of mixing standard types and interchange types where this matters?<br> *AI*: Jim: For the FLT_EVAL_METHOD example, add _Float16 in since it can show that evaluation to type is not always true.</font></div>
<div> </div>
<div><font size="2" > Namespace intrusion<br> Jens has sent a paper about the introduction of new names due to the integration of the TS's into the standard.<br> He says user's can't avoid them since no prefix. Proposing having reserved prefixes. Ex. Functions returning floats would have an flt_ prefix like flt_sinpi, and FLT_ for macros.<br> Proposal is to only do this for the new additions (not changing existing C18 functions).<br> Points out a real problem.<br> Since we modeled our names on what is already there in C this caused this issue.<br> Jens position is we should address the issue, not WG14 in general.<br> Rajan: We can see if WG14 wants to do this. I.e. If (A) WG14 wants to do something about the names added in and (B) directs CFP to do it, we can work on it. Otherwise we shouldn't do it.<br> Fred/David: Agree.<br> Fred: The WANT macro's could solve this issue.<br> Jim: No, still an issue due to the library side.<br> Fred: They are weak externals. If the user defines it, it wins, otherwise the math library does.<br> Rajan: Joseph hasn't said anything about this being a problem for his users and us unilaterally changing it may harm GCC's users.<br> Jim: Some things seemed good like prefixing SNAN. Also suffix vs prefix.<br> *AI*: Discuss the namespace issue next meeting.</font></div>
<div> </div>
<div><font size="2" > Specifying more special cases for math functions, e.g., periodicity for half-revolution trig functions. Perhaps as recommended practice.<br> <br> SNANF (See CFP 1366, 1372):<br> Fred: FLT_EVAL_METHOD 1 or 2 can give surprising results<br> Jim: It is only for certain operations. It should not affect this.<br> <br><strong> Other:</strong><br> </font></div>
<div><font size="2" ><strong> Activities:</strong><br> Review activities in progress<br> </font></div></div></div><BR>