[Cfp-interest 2976] WG14 IEEE 754-C binding meeting minutes - 2024/01/10

[Rajan Bhakta]

  Attendees: Rajan, Jim, Fred, Damian, Jerome, Joshua (left early), David, Ian (came late)

  New agenda items (https://wiki.edg.com/pub/CFP/WebHome/CFP%20meeting%20agenda-20240110-update.pdf):
    None.

  Previous meeting notes:
    See CFP2954 (https://mailman.oakapple.net/pipermail/cfp-interest/2023-November/002968.html).

  Next Meeting(s):
    February 7, 2024, 4PM UTC
    ISO Zoom teleconference
    Please notify the group if this time slot does not work.

  New action items:
    Jim: Update CFP2973 to add a comma before the "or" in the updated note.
    Jim: Give list of changes compared to the last revision of the TS parts 4 and 5 for the WG14 meeting.
    Jim, Fred: Come up with a way of discussing these C26 issues (grouping, or something else) before next CFP meeting.

  Action items to be carried over:
    None.

  C++ liaison:
    None.

  C23/WG14:
    C2X working draft N3149 (for CFP only)
      https://wiki.edg.com/pub/CFP/WebHome/N3149.pdf

    Next WG14 meeting: January 22-26, 2024.

    Status of C23 integration:
      See CFP2968 (DIS passed)

    DIS review comments:
      N3191 2023/12/10 Seacord, DIS 9899 ballot comments
        Jim: We'll need to look at the next draft from the editor to ensure everything is still OK. Some technical comments that were not floating point relevant. Some ISO comments on formatting and style which may affect the TS's.

      [SC22WG14.24405] Comments on C23 DIS ballot comments (N3191)
        See [Cfp-interest 2973] DIS comment about correctly rounded result Jim Thomas
          Joshua: I had confusion as to what the "or" in the fix bind to.
          Rajan: In addition to Joshua's valid comment, this list form now may need to be updated in the future for other cases if added.
          David: Don't see how the input part works.
          Jim: Some parts have values that are operands to the operator that are correctly rounded.
          Joshua: Some implicit operations need to be correctly rounded. Ex. Conversion to a string. Binary to decimal needs to be correctly rounded.
          Jim: Yes, that's an example of where you want to apply it to an operation. I don't want to go through every use of "correctly rounded" and make it "correctly rounded result" since that would result in awkward sentences and be a huge editing job.
          Jim: The floating point standard defines "correct rounding" (a verb). Not an adjective like "correctly rounded".
          Jim: 7.31.4.1.3#6 shows an example of an input with correctly rounded being used. 7.33.8#4 has another example to an operation.
          Joshua: The comma before the "or" is sufficient for the binding issue.
          ^Jim: Update CFP2973 to add a comma before the "or" in the updated note.
        See [Cfp-interest 2974] DIS comment 046 Jim Thomas
          Jim: The Annex F refers to C23, not 60559.
          Fred: The IEC part should be ISO/IEC.
          Jim: Yes, that is another orthogonal issue that is handled separately.

  Carry-over action items results:
    Fred: C26B Issue 1, nowhere else in the C standard are pole errors listed as a "shall", just as "may". This could be a problem for the proposed change.
      Done. C26C.HTM is the updated file. Applies to the other items as well.

    Fred: C26B Issue 2, the problem may not be an issue as it seems to be clear what is the expected result.
      Done.

    Fred: C26B Issue 6, consider explicit definitions instead of implicit references.
      Done.

    Fred: C26B Issue 8, hyphenate floating-point.
      Done.

    Fred: C26B Issue 13, mention "long double" in the issue text. Ex. "Annex F and long double including double-double needs to be clarified."
      See [Cfp-interest 2955] C2y issues list updated Fred J. Tydeman
      Done.

  Action items results (from previous meeting):
    Fred: Fix Issue 2 in C26B "reported by" text to be in the correct column.
      Done. C26C.HTM is the updated file. Applies to the other items as well.

    Fred: Add CFP2904 as a reference for C26B issue 12.
      Done.

    Fred: Add CFP2905 as a reference for C26B issue 14.
      Done.

    Fred: Add CFP2913 and CFP2918 to the C26B list.
      Done.

    Fred: Add CFP2947 as a new issue to the C26B list.
      Done.

    Fred: Add CFP2888 and follow ons to the C26B list.
      See [Cfp-interest 2955] C2y issues list updated Fred J. Tydeman
      Done.

    Jim: Part 4: Add a footnote anchored on something that says "For an example of emulating augmented arithmetic, see <paper on augmented arithmetic emulation from CFP2949>" and add it to the bibliography in part 4.
      See [Cfp-interest 2957] footnote about emulation of augmented arithmetic functions Jim Thomas
      Done.

    Jim: Add a footnote to Part 4, Clause 6 when it describes dN for N != 32, 64, 128 to say N = 32, 64, 128 are covered due to them being 60559 types and covered in Annex F.
      See [Cfp-interest 2958] footnote to clarify WANT macro requirement for decimal types Jim Thomas
        [Cfp-interest 2961] Re: footnote to clarify WANT macro requirement for decimal
types Fred J. Tydeman
        [Cfp-interest 2964] Re: footnote to clarify WANT macro requirement for decimal
types Jim Thomas
      Done.

    Fred: Review the bibliography in part 4.
      Done.

    Fred: Review the bibliography in part 5.
      See [Cfp-interest 2962] Re: WG14 IEEE 754-C binding meeting minutes - 2023/11/08 Fred J.
Tydeman
        [Cfp-interest 2963] Re: WG14 IEEE 754-C binding meeting minutes - 2023/11/08 Jim
Thomas
      Done.

    Jim: Part 4: Add a subclause to 5 (perhaps 5.4) for reserving prefixes, possibly referring to C 7.33.
      See [Cfp-interest 2959] reserving indentifiers Jim Thomas
      Done.

    Rajan: Send a note to JeanHeyd and cc Aaron to give CFP's recommendation for fixing the typo in H.2.1: Use "binary digits (bits)" for the first table second row, and "decimal digits" for the second table, second row.
      Done.

  TS-4 and TS-5 revisions
    See [Cfp-interest 2956] reserved prefix for augmented arithmetic functions Jim Thomas
      [Cfp-interest 2960] Re: reserved prefix for augmented arithmetic functions Damian McGuckin
      [Cfp-interest 2965] TS-4 and TS-5 drafts 2023-11-13 Jim Thomas
      [SC22WG14.24404] References to IEC 60559 in TS 18661 revisions
    Looks good.
    ^Jim: Give list of changes compared to the last revision of the TS parts 4 and 5 for the WG14 meeting.

  C26 issues
    Issues list: https://wiki.edg.com/pub/CFP/WebHome/C26C.HTM
      ^Jim, Fred: Come up with a way of discussing these issues (grouping, or something else) before next CFP meeting.

    Imaginary types
      See N3206 2023/12/15 Gustedt, The future of imaginary types
        [SC22WG14.24429] N3206 imaginary types Joseph S. Myers
        [SC22WG14.24431] N3206 imaginary types Joseph S. Myers
        [SC22WG14.24432] N3206 imaginary types Martin Uecker
        [SC22WG14.24434] N3206 imaginary types Jens Gustedt
        [SC22WG14.24435] N3206 imaginary types Joseph S. Myers
        [SC22WG14.24436] N3206 imaginary types Jens Gustedt
      Jim: The complex specification is intended to be compatible with the concepts and features in 754 even though not specified there.
      Jim: Imaginary type goes back to the NCG (Numerical C Group). They considered having an i suffix for constants. It was less useful than being able to multiply by the "I" macro. The suffix only applies to constants while the macro could be used in expressions. No reason to object to, but does have a limited use and doesn't supersede multiplying by the macro "I".
      Jim: Joseph does reply to this showing how imaginary types do work with the C model so the premise is wrong in the paper.
      Jim: For implementation, at least a HP compiler had a full implementation of it.
      Fred: Infinity * I gives a NaN real part. That hasn't been raised.
      Jim: 2i * Inf + 3i is an issue in a paper that Jerome and I wrote. If "i" is imaginary... This paper was in the journal of C language translation. Requires 4 multiplication and 2 additions. Gives NaN + Inf*i. It should take 2 operations and give -6 + Inf*i. Imaginary types improve the semantics and performance.
      Damian: In the Chapel (sp?) language there are complex and imaginary types. Not sure if they follow the equivalent of Annex G.
      Jim: Another use said being a heavy user of Complex, they don't want the imaginary type. I think having complex is orthogonal to imaginary as no one is worse off having it.
      CFP position: Keep it as an optional annex. No position otherwise.

    Overloading
      Jim: Gets complicated for floating point.

  Other issues
    IEEE-754 2029
      David: The next meeting is going to be focused on policies and procedures for the next revision.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240110/40c6a9c6/attachment-0001.htm>