<div dir="ltr"><div>2025/09/17: 8:00 AM PDT/3:00 PM UTC</div><div class="gmail_quote gmail_quote_container"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>[Please submit proposed changes to these minutes to Jerome or to the group. Revision changes appear at the bottom.]</div><div><br></div><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><p class="MsoNormal"><b>Attendees</b></p><p class="MsoNormal"> Jim Thomas, Rajan Bhakta, Jerome Coonen, Damian McGuckin, David Hough, Tue Ly, Joshua Cranmer</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><b>Updated agenda plus new items</b></p><p class="MsoNormal"> <a href="https://wiki.edg.com/pub/CFP/WebHome/CFP%20meeting%20agenda-20250917-update.pdf" target="_blank">https://wiki.edg.com/pub/CFP/WebHome/CFP%20meeting%20agenda-20250917-update.pdf</a> – These minutes should be read alongside the agenda, with its many reference links.</p><p class="MsoNormal"><b><br></b></p><p class="MsoNormal"><b>Previous meeting notes</b></p><p class="MsoNormal"> <a href="https://wiki.edg.com/pub/CFP/WebHome/n3697.pdf" target="_blank">https://wiki.edg.com/pub/CFP/WebHome/n3697.pdf</a></p><p class="MsoNormal"><br></p><p class="MsoNormal"><b>Study group logistics</b></p><p class="MsoNormal"> Next meeting: 15 October 2025, 8:00 AM PDT/3:00 PM UTC</p><p class="MsoNormal"> NOTE: agenda catch-up meeting: 29 October 2025, same time slot</p><p class="MsoNormal"> ISO Zoom teleconference</p><p class="MsoNormal"> Please notify the group if these time slots do not work.</p><p class="MsoNormal"><br></p></div><div><p class="MsoNormal"></p><p class="MsoNormal"><b>C documents</b></p><p class="MsoNormal"> The latest C2Y draft is N3550 May 2025 <a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3550.pdf" target="_blank">https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3550.pdf</a></p><p class="MsoNormal"> C23 has been published ISO/IEC 9899, available for purchase. <a href="https://www.iso.org/standard/82075.html" target="_blank">https://www.iso.org/standard/82075.html</a></p><p class="MsoNormal"> </p><p class="MsoNormal"><b>IEEE 754 liaison</b></p><p class="MsoNormal"> David: Just sent off two rants to the 754 revision committee about process and content, with suggestions for improvement. Will send to CFP.</p><p class="MsoNormal"> </p><p class="MsoNormal"><b>C++ liaison</b></p><p class="MsoNormal"> Joshua: No meetings for a while, so no updates.</p><p class="MsoNormal"><br></p><p class="MsoNormal"><b>WG14 update</b></p><p class="MsoNormal"> Rajan: Following along with the two emails linked in the agenda:</p><p class="MsoNormal"> WG14 entertained and approved several papers submitted before the deadline.<br> Handling of imaginary I (eye) fell off the agenda, to be picked up next meeting.</p><p class="MsoNormal"> Later in this meeting, Jim & Rajan pick up the topic of the range and precision of evaluation during translation time.</p><p class="MsoNormal"> Treatment of error handling in functions in new mathematical headers such as reduc.h and augarith.h is taken up below under carryover action Items.</p><p class="MsoNormal"> The next two WG14 meetings are virtual, in February and March 2026. They will pick up any outstanding CFP proposals in February and then any further proposals in March.</p>
<p class="MsoNormal"> </p><p class="MsoNormal"><b>TS-4 and TS-5 revisions</b></p><p class="MsoNormal"> None.</p></div><div><p class="MsoNormal"><br></p><p class="MsoNormal"><b>News</b></p><p class="MsoNormal"> Jerome: The IEEE Milestone plaques for the Intel 8087 Math Coprocessor were dedicated Sunday 14 Sept in Haifa, Israel. It was William Kahan's suggested design for the arithmetic in the 8087 that inspired Standard 754. The 8087 in 1980 predated formal approval of 754 by five years but implemented all of its key features, and more. Jerome will send a bit more information when it's available.</p><p class="MsoNormal"> Jim: Paul Zimmerman sent two email messages. One discusses bfloat16 support, with a question about naming. Simply adding "bf16" as a suffix hits a snag with the log functions and their logb variants because of the "b".</p><p class="MsoNormal"> Ly: Google uses the "_bf16" suffix just for the log functions but that lacks consistency. Looking for suggestions here.</p><p class="MsoNormal"><br></p><p class="MsoNormal"><u></u></p><p class="MsoNormal"><b>Carryover action items from last meeting </b></p><p class="MsoNormal"> Rajan: Monitor the new WG14 issue tracker re. TS 18661-4, the domain and range error issue, to see the level of interest in making this small fix.</p><p class="MsoNormal"> Rajan: Resolved from WG14 side but not yet in the publications. How that resolution will be channelled to the public is TBD by WG14. Closed.</p><p class="MsoNormal"><br></p><p class="MsoNormal"><b>Action items from last meeting </b></p></div><div> Jim: Submit pragma proposal.</div><div> Done</div><div><br></div> Jim: Submit preferred quantum exponent proposal.</div><div> Done<br><br></div><div dir="ltr"> Jerome & Jim: Re. the "exp" fix proposal, note the italic face, get a doc number, and submit.</div><div> Done<br><br></div><div dir="ltr"> Jim: Write note for Rajan to bring up for WG14 re. removing imaginary I.</div><div dir="ltr"> Done, but resolution is deferred until the next WG14 meeting in February 2026.<br><br> Rajan: Call both TOWARDS and missing quotes issues to JeanHeyd's attention.</div><div> Rajan: Has sent the note but is waiting for JeanHeyd to close the loop. Closed.</div><div dir="ltr"><br> Damian: In the Annex F syntax discussion, revert to prior wording of stored function results. Clarify a bit of the introductory discussion, too.</div><div> Done<br><br></div><div dir="ltr"> Damian: Re. "integer n" proposal, revisit the algebraic versus integer type uses of "n", and adjust the proposal accordingly.</div><div dir="ltr"> Done<br><div><br></div><div><b>Discussion of issues</b></div></div><div dir="ltr"><div><p class="MsoNormal"> Floating expression evaluated in the translation environment</p><p class="MsoNormal"> Jim: 6.6.1#5 statement about "the range and precision" of constant evaluation at translation time uses "shall", making it a requirement. That means that a violation results in undefined behavior, which is anathema. WG14 wants to remove avenues to UB.</p><p class="MsoNormal"> Rajan: Why is there escape hatch language for translation vs. execution time computation? This should be dealt with as a general C matter, not just a CFP issue. Action taken with Jim to send email to WG14 seeking direction.</p><p class="MsoNormal"><br></p> Removing imaginary I</div><div> Jim: This Issue has been pushed to the February 2026 WG14 agenda.</div><div> Rajan: Proposes sending a note to Alex beforehand, preferably with CC to WG14, to raise awareness. Action.<br><br></div><div> TOWARDS and missing quotes issues</div><div> Rajan: Note has been sent to JeanHeyd and we now awaiting response. Closed.</div><div><br></div><div> Editorial application to Annex H</div><div> Jim: JeanHeyd refers to n3500, which fixes a wording problem. The same issue exists in Annex H, so he'll fix it there, too. With agreement on this path in the meeting, Closed.<br><br></div><div> Output bounds for math functions</div><div> Jim: We should find language consistent with 60559 for cases like the inverse trig functions that may return a principal value bounded mathematically by, say, [-pi/2, +pi/2]. A correctly (or nearly correctly) rounded result near the boundary might fall outside the mathematical interval. The idea is to focus on the result being the principal value, as opposed to lying in an interval whose bounds are subject to representation or rounding errors.</div><div> Joshua: Suggests a note about rounding taking the value out of the bounds, to present the conundrum to the reader without getting all the complexity into the specification.</div><div> Jerome: Takes Action to draft a proposal.</div><div><br></div><div> Overflow, non-default rounding, errno</div><div> Jim: Summarizes his long study/email of the second-order issues related the "error occurs" language improvements of n3405. Fred and Vincent have provided further discussion.</div><div> Jim & Jerome: Take Action to pursue these other areas of the draft, in order to bring consistency across all discussion of numerical errors.<br><br></div><div> Annex F - syntax for function special cases</div><div> Damian: Summarizes some of the challenges of the two locutions "...for x..." and "...when x...", which appear throughout the specification of function special cases. Damian will roll feedback into a new draft of the proposal to make these usages consistent in C2Y.</div><div><br></div><div> Annex F - integer ‘n’</div><div> Damian: The only change of note is one change to have "integer n" consistently singular.</div><div> Jim: There is also the matter of consistency in usage "odd/not-odd" vs. "odd/even".</div><div> Damian: Notes that pow() uses odd/not-odd terminology to describe domains in 4 special cases whereas odd/even terminology is far more common, being used in tanpi(), pown() and rootn(). While the use of odd/not-odd clearly shows the complementary nature of adjacent domains, the use of odd/even is more common. Damian will document more fully in the next revision of the discussion paper.</div><div><br></div><div> Annex F – Special case domains, signaling NaNs</div><div><div> Damian: Has cleaned up much wording, with input from the group. Two subtleties are the the inclusion of infinities and NaNs. The current proposal is to use two-sided bounds. For example, </div><div> 1 < x <= inf</div><div>clearly indicates that x may be +inf, while "1 < x" is less specific.</div><div> Jim: This is Annex F, so the presence of inf is taken for granted. </div><div> Joshua, Jerome, Damian: It's useful to be more explicit. Users consulting the standard as a reference may be unaware of the specific Annex F context when looking up a specific function. Section F.2.2 Infinities and NaNs is not necessarily foremost in every reader's mind.</div><div> Damian: Including NaNs is another challenge. A locution like</div><div> 0 <= |x| <= inf or x is a NaN</div><div>is unambiguous (after a close look) but is jarring to a user who might expect a phrase like "all x", to indicate any value, numerical or not, that a floating point variable could take. </div></div><div> Damian: When talking about NaNs, always use the definite article "a NaN" . Case of "for" vs. "when".</div><div> Damian: Hardest cases involve NaNs. Damian will push ahead toward a usage to applied consistently across the current medley of usages in C2Y.</div><div><br></div><div><b>Other issues</b></div></div><div dir="ltr"><div> None.</div><div><br></div></div><div dir="ltr"><div><b>Adjournment</b></div><div><p class="MsoNormal"> 10:05 AM PDT</p><p class="MsoNormal">-----------------------------------------------</p><p class="MsoNormal"><br></p><p class="MsoNormal"><b>Action items to be carried over</b></p><p class="MsoNormal"> None</p><p class="MsoNormal"><br></p><p class="MsoNormal"><b>New action items<u></u></b></p><p class="MsoNormal"> Jim & Rajan: Send email to WG14 seeking direction for how to deal with translation time evaluation of constant expressions that does not lead to possible undefined behavior.</p><p class="MsoNormal"><br></p><p class="MsoNormal"> Jim & Rajan: Craft note to Alex, CC to WG14, re. n3584, removing imaginary I.</p><p class="MsoNormal"><br></p><p class="MsoNormal"> Jerome: Draft a proposal re. the language of functions returning the principal value.</p><p class="MsoNormal"><br></p><p class="MsoNormal"> Jim & Jerome: Look further into the language around when errors "occur" in the sense of C2Y and how the setting of errno fits in. Draft a proposal, if appropriate.</p><p class="MsoNormal"><b><br></b></p><p class="MsoNormal"><b>Discussion issues to be carried over</b></p></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div><p class="MsoNormal"> Special cases of cpow</p><p class="MsoNormal"><br></p><p class="MsoNormal"> Preferred quantum exponent for nextafterdN</p><div><br></div><div> Rounding Direction Mode or Rounding Direction or Rounding Mode<br><br></div><div> F10.1#14<br><br></div><div> F.10.9.1 - nextafter(x, y)<br><br></div><div> canonicalize() in Annex F - F.10.9.7<br><br></div><div> hypot(x, y) - C2Y F.10.5.4<br><br></div><div> hypot(x, NAN) in Annex F<br><br></div><div> Magnitude or Absolute Value or |x| or ....<br><br></div><div> Preferred Style in Annex F - fromfp/fromfpx or nearbyint/rint</div><div><br></div><div> "invalid" => domain error?<br><br></div><div> csinh special case<br><p class="MsoNormal"></p></div><p class="MsoNormal"><br></p></div><div><b>Signoff</b></div><div> Respectfully submitted.</div><div><br></div><div dir="ltr">-Jerome Coonen<div> 650.996.4738</div><div> <a href="mailto:jcoonen@gmail.com" target="_blank">jcoonen@gmail.com</a></div></div></div></div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div>
</div></div>
</div></div>
</div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div></div>
</div>
</div></div>
</div></div>
</div>
</div></div>
</div>
</div></div>
</div></div>
</div>
</div></div>