[Cfp-interest 3318] JTC1/SC22/WG14/CFP 2024/10/16 Meeting minutes -- Revised

Thu Oct 31 09:20:38 PDT 2024

[The minutes appear in agenda order, with carry-over and new agenda items
precipitating out at the end.]

2024/10/16: 8 AM PDT

*Attendees*

    Rajan, Jim, Jerome, Fred, Damian, David, Joshua

*New agenda items*

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

*Previous meeting notes*

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

*Next Meeting(s)*

    November 20, 2024, 4PM UTC (Note the change to 4PM due to U.S. change
to Standard Time)

    ISO Zoom teleconference

     Please notify the group if this time slot does not work.

*C documents*

    The working C2y draft is n3301 - 28 July 2024 - For CFP review only. Do
not distribute.

*IEEE 754 liaison*

   Jerome: Continued work on accumulated errata, with some suggestions
around reorganization to make the standard more readable. The definition of
"integer format" continues to be an issue.

*C++ liaison*

    None

*WG14 meeting*

    N3288 (Give consistent wording for SNAN initialization) RAJAN BHAKTA

        Rajan: Contention over "translation time" wording. Committee voted
for that choice -- alternative 1in N3364.

    WG14 CFP papers results part 2 RAJAN BHAKTA
        Rajan:  All others accepted without discussion. As a side note, the
"abstain" votes are a mix of people not fully informed and some who are not
interested.

*C23 integration*

    None.

*Carry-over action items from last meeting *

    suggestions for fadd/fsub/fma error reporting --Jerome

        Done, discussed below.

*Action items from last meeting*
    Jim: Update Complex suggestions (3262) for Annex G migration.
       Done n3285.

    Jim: Update frexp for double double (3154) per discussion, to leave
undefined result for non-model numbers, and submit the proposal to WG14.
       Done n3357.

    Fred: Send note to WG14 about constexper exceptional case issue.
       Done.

    Fred: Send nan() email to WG14 (3259).
       Done.

    David : Draft reply to WG14 re. midpoint and interpolation.
       Carry over.

    Jim: Submit to WG14 a proposal about lingering references to imaginary
       Done n3358.

    Fred: Draft a proposal for the "cannot" vs. "can not" change (3162).
       Done & submitted, discussed below.

    Fred: Revise the proposal for SIGFPE and I/O, in light of further
discussion N3378
       Done & submitted, discussed below.

    All: Please send comments to Damian by Monday 30 Sept on the first of 4
sets of proposals (3247), including comments on Jim's responses (3279).
       Done, discussed below.

    Jim: Write up a proposal for ilogb() and llogb() (3266).
       Done, discussed below.

*TS-4 and TS-5 revisions*

    Jim: Many comments from ISO editors (bolding, margins, bullets,
references, comments, "requirement verbs"). Jim caught some misspelled
feature names. Jim is working on (hopefully) final drafts, to be
resubmitted to ISO and posted  to CFP.

   Fred: It's not a standard, just a report, so why all of the scrutiny of
the form.

    Jim: Because that's the process.

*C2y issues*

  None.

*Discussion of issues*

    SIGFPE
         Fred: Summarized clarifying language.

        Rajan: The wording around the raise function is not in the style of
current usage.

        David: Provided a suggestion that Fred will implement.

    fadd/fsub and fma "error may occur" issues
        Jerome: Two topics -- details of the special cases & weakening of
the requirements to "may occur".

        Jim: The main body of the standard generally avoids references to
infinity, hence the use of "may occur" for errors involving infinity. But
fsqrt is long accepted as having domain errors, to remove the suggestion to
weaken that usage to "may occur". In fsub, reverse the wording to "...and
either both of the same sign or unsigned", which pushes the obscure
unsigned infinity case to the end.

    Treatment of error conditions
        Jerome & Jim: Discuss what it really means for an error to "occur",
a seemingly obvious usage that is closely tied to whether the error is
actually reported.

    Changes to 6.X and 7.X
        Damian & Jim & Jerome: "complex floating type" is just one issue
that is to be gathered into the editorial slice of this large project. See
the New Action Items for the more substantive issues of complex.h and cproj
as well.

    Deeper TOC for annexes
        Jim: The one line of TOC provides no guidance to the contents of
the annexes.

        Fred: Agree.

        Rajan: From a non-CFP point of view, some of the annexes have long
lists of sections no one wants to see in the TOC.

        Joshua: **HOT TIP** about using Acrobat's Bookmarks tab to produce
a synthetic TOC in the margin.

    Moving complex ops spec from Annex G to main body
        Jim: The addition expands the language of the body of the standard,
and explains how the complex operations work.

        Rajan: The operations may need to be expressed recursively, to
capture elaborate expressions.

        Jim, Rajan, Jerome: This is not about the grammar, just the
definitions of the base-level computations. This seemed to resolve Rajan's
issue.

    Reply to WG14 re. midpoint and interpolation
         Carried over.

    “cannot” vs “can not”
        Fred: Vincent caught a subtle problem with "can not". The fix has
been submitted.

    Range errors for ilogb and llogb
        Jim: Idea is to make the range error more explicit while
simultaneously removing the possibility of range error in selected
functions with a result of integer type. In order not to break existing
implementations, the language does allow range errors in principle for a
function with an integer return type.

        Rajan: The "obsolescent feature" nature of the range error is an
element the C standard would like to phase out.

    ERANGE question

        Jim, et al.: This issue arose as a rather innocent question about
values that round fortuitously to DBL_MAX (even though the infinitely
precise value might exceed DBL_MAX), but then devolved to subtleties of the
sense of precision in the double-double type. Time expired and the value is
to be carried over.

*Other issues:*

    None.

*Adjournment*

    10:07 AM PDT

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

*Action items to be carried over:*

   David : Draft reply to WG14 re. midpoint and interpolation.

*New action items:*

    Fred: Submit update to SIGFPE proposal N3378, with  the suggested new
wording re. the raise function.

    Jerome: Draft a proposal fadd, etc. (3314) following the discussion
above, and adhering to the practice of new text in green and removed text
in red strike-thru.

    Jerome: Draft proposal re. changes for "treatment of error con,
watching for interaction with Jim's change re. range error in 7.12.2#4. Add
a note to the editor that Jim's change below comes first, then this tweak
of the verb.

    Damian: Split doc into 3 documents: complex.h intro, cproj, and
editorial suggestions.

    Jim: Submit proposal re. range errors for ilogb and llogb (3300).

    Jim: Submit proposal re moving complex ops spec from Annex G to main
body (3285), with an eye to fixing the rogue underscore-u references that
Fred spotted.

*Discussion issues to be carried over:*

    ERANGE and values that round to DBL_MAX.

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/20241031/73a9b75b/attachment.htm>