[cfp-interest 3603] JTC1/SC22/WG14/CFP 2025/09/17 Meeting notes

Sat Sep 20 10:33:57 PDT 2025

2025/09/17: 8:00 AM PDT/3:00 PM UTC
[Please submit proposed changes to these minutes to Jerome or to the group.
Revision changes appear at the bottom.]

*Attendees*

    Jim Thomas, Rajan Bhakta, Jerome Coonen, Damian McGuckin, David Hough,
Tue Ly,  Joshua Cranmer

*Updated agenda plus new items*

https://wiki.edg.com/pub/CFP/WebHome/CFP%20meeting%20agenda-20250917-update.pdf
–
These minutes should be read alongside the agenda, with its many reference
links.

*Previous meeting notes*

    https://wiki.edg.com/pub/CFP/WebHome/n3697.pdf

*Study group logistics*

    Next meeting: 15 October 2025, 8:00 AM PDT/3:00 PM UTC

    NOTE: agenda catch-up meeting: 29 October 2025, same time slot

    ISO Zoom teleconference

    Please notify the group if these time slots do not work.

*C documents*

    The latest C2Y draft is N3550 May 2025
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3550.pdf

    C23 has been published ISO/IEC 9899, available for purchase.
https://www.iso.org/standard/82075.html

*IEEE 754 liaison*

    David: Just sent off two rants to the 754 revision committee about
process and content, with suggestions for improvement. Will send to CFP.

*C++ liaison*

     Joshua: No meetings for a while, so no updates.

*WG14 update*

    Rajan: Following along with the two emails linked in the agenda:

        WG14 entertained and approved several papers submitted before the
deadline.
        Handling of imaginary I (eye) fell off the agenda, to be picked up
next meeting.

        Later in this meeting, Jim & Rajan pick up the topic of the range
and precision of evaluation during translation time.

        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.

        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.

*TS-4 and TS-5 revisions*

    None.

*News*

    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.

     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".

    Ly: Google uses the "_bf16" suffix just for the log functions but that
lacks consistency. Looking for suggestions here.

*Carryover action items from last meeting *

    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.

        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.

*Action items from last meeting *
    Jim: Submit pragma proposal.
        Done

    Jim: Submit preferred quantum exponent proposal.
        Done

    Jerome & Jim: Re. the "exp" fix proposal, note the italic face, get a
doc number, and submit.
        Done

    Jim: Write note for Rajan to bring up for WG14 re. removing imaginary I.
        Done, but resolution is deferred until the next WG14 meeting in
February 2026.

    Rajan: Call both TOWARDS and missing quotes issues to JeanHeyd's
attention.
        Rajan: Has sent the note but is waiting for JeanHeyd to close the
loop. Closed.

    Damian: In the Annex F syntax discussion, revert to prior wording of
stored function results. Clarify a bit of the introductory discussion, too.
        Done

    Damian: Re. "integer n" proposal, revisit the algebraic versus integer
type uses of "n", and adjust the proposal accordingly.
        Done

*Discussion of issues*

    Floating expression evaluated in the translation environment

        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.

        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.

    Removing imaginary I
        Jim: This Issue has been pushed to the February 2026 WG14 agenda.
        Rajan: Proposes sending a note to Alex beforehand, preferably with
CC to WG14, to raise awareness. Action.

    TOWARDS and missing quotes issues
        Rajan: Note has been sent to JeanHeyd and we now awaiting response.
Closed.

    Editorial application to Annex H
        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.

    Output bounds for math functions
        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.
        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.
        Jerome: Takes Action to draft a proposal.

    Overflow, non-default rounding, errno
        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.
        Jim & Jerome: Take Action to pursue these other areas of the draft,
in order to bring consistency across all discussion of numerical errors.

    Annex F - syntax for function special cases
        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.

    Annex F - integer ‘n’
        Damian: The only change of note is one change to have "integer n"
consistently singular.
        Jim: There is also the matter of consistency in usage "odd/not-odd"
vs. "odd/even".
        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.

    Annex F – Special case domains, signaling NaNs
        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,
            1 < x <= inf
clearly indicates that x may be +inf, while "1 < x" is less specific.
        Jim: This is Annex F, so the presence of inf is taken for granted.
        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.
        Damian: Including NaNs is another challenge. A locution like
            0 <= |x| <= inf or x is a NaN
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.
        Damian: When talking about NaNs, always use the definite article "a
NaN" . Case of "for" vs. "when".
        Damian: Hardest cases involve NaNs. Damian will push ahead toward a
usage to applied consistently across the current medley of usages in C2Y.

*Other issues*
    None.

*Adjournment*

    10:05 AM PDT

-----------------------------------------------

*Action items to be carried over*

    None

*New action items*

    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.

    Jim & Rajan: Craft note to Alex, CC to WG14, re. n3584, removing
imaginary I.

    Jerome: Draft a proposal re. the language of functions returning the
principal value.

    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.

*Discussion issues to be carried over*

    Special cases of cpow

    Preferred quantum exponent for nextafterdN

    Rounding Direction Mode or Rounding Direction or Rounding Mode

    F10.1#14

    F.10.9.1 - nextafter(x, y)

    canonicalize() in Annex F - F.10.9.7

    hypot(x, y) - C2Y F.10.5.4

    hypot(x, NAN) in Annex F

    Magnitude or Absolute Value or |x| or ....

    Preferred Style in Annex F - fromfp/fromfpx or nearbyint/rint

    "invalid" => domain error?

    csinh special case

*Signoff*
    Respectfully submitted.

-Jerome Coonen
 650.996.4738
 jcoonen at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20250920/8f9222f7/attachment-0001.htm>