<span style=" font-size:10pt;font-family:sans-serif">Hi Jim,</span><br><br><span style=" font-size:10pt;font-family:sans-serif">Maybe I misunderstood,
but I thought near the end of the meeting I asked if we took the remainder
as was in the paper (I had no issues with those positions), we could jump
to the WG14 papers section due to the timing. I thought we agreed, so I
put the last questions status as is into the minutes.</span><br><br><span style=" font-size:10pt;font-family:sans-serif">Regards,<br><br>Rajan Bhakta<br>z/OS XL C/C++ Compiler Technical Architect<br>ISO C Standards Representative for Canada, PL22.11 Chair (USA)<br>C Compiler Development<br>Contact: rbhakta@us.ibm.com, Rajan Bhakta/Houston/IBM</span><br><br><br><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">Jim
Thomas <jaswthomas@sbcglobal.net></span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">Rajan
Bhakta <rbhakta@us.ibm.com></span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">cfp-interest@oakapple.net</span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">10/18/2019
01:11 PM</span><br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">[EXTERNAL]
Re: [Cfp-interest 1421] WG14 IEEE 754-C binding meeting minutes 2019/10/16</span><br><hr noshade><br><br><br><span style=" font-size:12pt">Regarding the response to Question 24,
we didn’t get that far at the meeting, but I was (am) for the change,
in principle:</span><br><br><span style=" font-size:12pt">For, in principle. The type-suffix style
naming for INFINITY and NAN, and carried on with SNAN, came from the use
of that style for the similar <math.h> macro HUGE_VAL.</span><br><span style=" font-size:12pt"> We could put INFINITY, NAN, and
SNAN with the usual prefixes in <float.h> and obsolesce the suffixed
ones in <math.h>.</span><br><span style=" font-size:12pt">- Jim Thomas</span><br><br><span style=" font-size:12pt">On Oct 16, 2019, at 6:18 PM, Rajan Bhakta
<</span><a href="mailto:rbhakta@us.ibm.com"><span style=" font-size:12pt;color:blue"><u>rbhakta@us.ibm.com</u></span></a><span style=" font-size:12pt">>
wrote:</span><br><br><span style=" font-size:10pt;font-family:sans-serif"> <b>Attendees</b>:
Rajan, Jim, Fred, Mike, Ian, David H,</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><b><br> New agenda items:</b><br> None.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><b><br> Carry over action items:</b><br> Fred: Rewrite the proposed CFP1360 paper using the CFP recommendations.
- Done.<br> <b><br> Last meeting action items:</b><br> CFP: Put the tgmath redefinition as a proposal to the standard
once we have a base document with TS Part 3 in it. - Carry over (no base
document with part 3 yet)<br> Jim: Respond to Fred's question in CFP1377 about where the
SNANF information is stated. - Done.<br> CFP: Look at naming issue and propose responses to the questions
in the paper. - Done.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><b><br> New action items:</b><br> CFP: Follow up on CFP1419 via email.<br> Jim: Create a WG14 paper for the next Spring 2020 WG14 meeting
along the lines of CFP1411.<br> <b><br> Next Meeting(s):</b><br> Wednesday, November 20th, 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.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><b><br> Discussion:</b><br> 754 revision:<br> Looking for new 754 chair.<br> In maintenance mode right now. Nothing to do until
someone wants to be chair.<br> Jim: A lot of ideas for new features for the next
754 revision. Can have a group per idea to push the individual ideas.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><br> C++ Liaison:<br> Nothing.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><br> C2X integration (</span><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2433.pdf"><span style=" font-size:10pt;color:blue;font-family:sans-serif"><u>http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2433.pdf</u></span></a><span style=" font-size:10pt;font-family:sans-serif">):<br> Draft with TS 1, 2, and 4a<br> Part 3<br> Part 4b - Looking as an updated TS.<br> Part 5a,b,c,d<br> Jim: Haven't yet checked to make sure all comments
for part 4a integration were addressed, but don't see problems there.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><b><br> Action item details:</b><br> Fred: Rewrite the proposed CFP1360 paper using the CFP recommendations.
See thread starting with [Cfp-interest 1388] Math functions & range
errors (see CFP 1419).<br> Fred: Too late for WG14 meeting.<br> Still an ambiguity with "small".<br> Jim: Still has the question of zero possible being
too close to zero.<br> Fred: exp is an example, and I can add in "non-zero"
x being too close to zero.<br> Jim: Are there cases that don't say magnitude being
too small?<br> Fred: More of a general thing of saying too
small.<br> Jim: This mirrors the too large.<br> Jim: Still some issues with the "may occur for
finite x" changes.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><br> CFP: Put the tgmath redefinition as a proposal to the standard
once we have a base document with TS Part 3 in it.<br> Postpone until we have a base document.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><br> Jim: Respond to Fred's question in CFP1377 about where the
SNANF information is stated (see CFP 1411).<br> Ian: Should we redefine constant expression instead?<br> Rajan: That would have impacts across C so
I wouldn't want to do it.<br> Mike: It would be a bigger change than just
fixing NaNs.<br> Mike: Can have a new kind of constant expression as
well if we want instead of this.<br> *AI*: Jim: Create a WG14 paper for the next Spring
2020 WG14 meeting along the lines of CFP1411.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><br> CFP: Look at naming issue and propose responses to the questions
in the paper (</span><span style=" font-size:12pt;color:blue"><u><br></u></span><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2426.pdf"><span style=" font-size:10pt;color:blue;font-family:sans-serif"><u>http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2426.pdf</u></span></a><span style=" font-size:10pt;font-family:sans-serif">,
</span><a href="http://wiki.edg.com/pub/CFP/WebHome/responses_to_naming_questions.pdf"><span style=" font-size:10pt;color:blue;font-family:sans-serif"><u>http://wiki.edg.com/pub/CFP/WebHome/responses_to_naming_questions.pdf</u></span></a><span style=" font-size:10pt;font-family:sans-serif">,
Joseph Myers email SC22WG14.17170).<br> WG1417170: Agree with points 1, 2, 3 (diagnostic outside
scope of CFP but we agree with it), 5. 4 is outside our scope.<br> Question 1: Ian, Rajan like removing the _Float32/64
since it's easier for users and implementers.<br> Jim: Lose the portability aspect of _Float32x.
_Float128 is still useful too for portability.<br> Suggest we say "No" but if there
is a request for change, we can propose what is in the responses_to_naming_questions.pdf
paper to remove redundant types and only leave true extensions.<br> Question 2: "No". Agree with Jim's paper.<br> Question 3: "No". Agree with Jim's paper
and Joseph's reflector response.<br> Question 4: "No". Agree with Jim's paper.<br> Question 5: "No". Agree with Jim's paper.<br> Question 6: "Neutral". Agree with Jim's
paper.<br> Question 7: "Neutral". Agree with Jim's
paper.<br> Question 8: "No". Agree with Jim's paper.<br> Question 9: "No". Agree with Jim's paper
and Joseph's reflector response.<br> Question 10: "No". Agree with Jim's paper.<br> Question 11: "No". Agree with Jim's paper.<br> Question 12: "No". Agree with Jim's paper.
Note "cr" is not reserved as a prefix nor is crsqrt an ambiguity.<br> David: No information on implementers right
now on this. Usually in private libraries rather than language extensions.
Implementations (Sun, Oracle) are common for these functions, but naming
may not be. Lots of papers with it too.<br> Jim: Having reserved names will help make them
be externalized. Also 754 requires correctly rounded functions.<br> David: Having a simple prefix will help externalize
those functions and make them portable. This allows programmers to choose
between performance/accuracy tradeoffs in an accurate way.<br> Question 13: "No". Agree with Jim's paper.<br> Question 14: "No". Agree with Jim's paper.<br> Question 15: "No". Agree with Jim's paper.<br> Question 16: "No". Agree with Jim's paper.<br> *Question 17: "No". Though if it is a real
demonstrated conflict, we are OK with it, and are OK with the changes here
or other ones.<br> Fred: Can add in an underbar for ones that
may be an issue (f_add) for example.<br> Rajan: Joseph at least has implemented this
so suggest "No."<br> Question 18: "No". Agree with Jim's paper.<br> Question 19: "No". Agree with Jim's paper.<br> Question 20: "No". Agree with Jim's paper.<br> *Question 21: "No". Already implemented
as is (Joseph for example).<br> Question 22: "No". Agree with Jim's paper.<br> Question 23: "No". Agree with Jim's paper.<br> Question 24: "No". Agree with Jim's paper.<br> Question 25: "No". Agree with Jim's paper.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><b><br> Other issues:</b><br> Joseph Myers (SC22WG14.17150) N2361 inconsistency with implementation
techniques<br> Defer.<br> <br> Followup on what does “normalized” mean in C? See CFP 1399<br> Defer.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><br> Specifying more special cases for math functions, e.g., periodicity
for half-revolution trig functions. Perhaps as recommended practice.<br> Defer.</span><span style=" font-size:12pt"><br></span><span style=" font-size:10pt;font-family:sans-serif"><br> For WG14 meeting 21-25 October, 2019 – Ithaca, New York,
US [N 2327]<br> N2384 Thomas, C2X proposal - F.8 update<br> N2400 Thomas, C2X proposal - why no wide string strfrom
functions<br> N2406 Tydeman, SNAN: initialization and unary +<br> N2407 Thomas, Proposal for C2X - TS 18661-5abc supplementary
attributes<br> N2416 Thomas, Proposal for C2X - floating-point negation
and conversion<br> N2421 Thomas, TS 18661-5abc for C2X - slides<br> N2424 Thomas, Proposal for C2X proposal – Why logp1?<br> No new comments. </span><span style=" font-size:12pt"><br>_______________________________________________<br>Cfp-interest mailing list</span><span style=" font-size:12pt;color:blue"><u><br></u></span><a href="mailto:Cfp-interest@oakapple.net"><span style=" font-size:12pt;color:blue"><u>Cfp-interest@oakapple.net</u></span></a><span style=" font-size:12pt"><br></span><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><span style=" font-size:12pt">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</span></a><br><br><br><BR>