[Cfp-interest 3039] WG14 IEEE 754-C binding meeting minutes - 2024/03/13

Wed Mar 13 10:09:59 PDT 2024

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

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

  Previous meeting notes:
    See CFP2976 (http://mailman.oakapple.net/pipermail/cfp-interest/2024-January/002990.html).

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

  New action items:
    Rajan: Send the WG14 editorial comments from CFP to CFP.
    Rajan: For C2Y issue 5, reword H.3.6 and 5.2.5.3.2#28 to "If a signaling NaN macro (optionally preceded by the unary + or - operator) is used for initializing an object of the same type that has static or thread storage duration, the object is initialized with a signaling NaN value."
    Jim: Fix the suggested changes section in CFP3020's paper to point to N3219 (instead of the incorrect N3619 as it currently is) and send it out to WG14.
    Jim: Submit the paper resolving C2Y Issue 17 (CFP3022) to WG14.
    Jim/Jerome/Damian: Follow up on C26 issue 1.
    Fred: Add CFP3003 to the issues list.
    Jim: Draft up changes to incorporate CFP3006.
    Fred: Add CFP3007 to the C26 issues list.
    Damian: Get a list of editorial issues in Annex G and send them out for future submission to WG14.

  Action items to be carried over:
    None.

  C++ liaison:
    None.

  WG14 (added):
    See CFP3008 and follow ons.
    No editorial review group resolution meeting scheduled yet.
    Next WG14 meeting (virtual) is June 10-14th, 2024.
    ^Rajan: Send the WG14 editorial comments from CFP to CFP.

  C23 integration
    C23 drafts:
      C23 working draft n3219 - July 2, 2023 - For CFP review only. Do not distribute.

  Carry over action items
    None

  Action items from previous meeting (Done unless stated otherwise)
    Fred: C26: Issue 5: Are there any <math.h> macros with the same issue? Should words be added to an introduction section in <float.h>?
    See [Cfp-interest 2999] <math.h> macros and exceptions (and follow on CFP 3031)
      OK with using CFP 3031 as the direction for the resolution to the issue.
      Jim: For SNAN macro recommended practice (in F.2.2#6 on), don't see the issue.
      Fred: Will look at it.
      Rajan: The H.3#6 should have the optional unary operator be after the initializing an object to not make that optional mandatory (in a specific way of reading it).
      Jim: I'm OK with that.
      Jerome: Doesn't adding the -/+ cause raising a signal?
      Jim: No, this is not an expression. 754 has a set of operations that do not signal.
      Damian: Yes, that's true. Things like copysign.
      ^Rajan: For C2Y issue 5, reword H.3.6 and 5.2.5.3.2#28 to "If a signaling NaN macro (optionally preceded by the unary + or - operator) is used for initializing an object of the same type that has static or thread storage duration, the object is initialized with a signaling NaN value."

    Fred: C26: Issue 9: Look at original CFP messages to see if 3.10 (Correctly rounded definition) might cover it.
    See [Cfp-interest 3000] CFP issue #9
      Fred: Fine with it.
      Rajan: It is in 3.12 in N3219.

    Jim: C26: Issue 4: Draft a paper as per the resolution in the issues list.
    See [Cfp-interest 3020 and follow ons] Re: printf and rounding recommendation
      ^Jim: Fix the suggested changes section in CFP3020's paper to point to N3219 (instead of the incorrect N3619 as it currently is) and send it out to WG14.

    Jim: C26: Issue 17: Draft a paper as per the resolution in the issues list.
    See [Cfp-interest 3022] C2Y Issue 17
      ^Jim: Submit the paper resolving C2Y Issue 17 (CFP3022) to WG14.

    Jerome: C26: Issue 1: Get definitions of terms relating to the issue for 754 and C and regular math.
    See [Cfp-interest 3016] Re: about C26 Issue 1
      Jerome: Will need to remain an open issue until we get closure from the 754 people. We could make the changes I suggested in C, but better to wait for 754.
      Jim: The 754 term we need to be consistent with is the divide-by-zero exception. It doesn't classify the different types of errors. C needs the categories due to errno.
      Damian: I think singularity is exactly what you want.
      Fred: So log(0) is a singularity error?
      Jerome: Yes, on 754 systems.
      Fred: If you make this change for log gamma, you need to do it for all other cases like log(0).
      Jerome: Yes, I think you are right.
      Jim: Wider issue, see CFP-2996.
      Fred: Don't most mathematicians consider pow(0,0) to be 1?
      Damian: Yes.
      Jim: No. Because the limit does not exist.
      David: It's an exception since there is no right answer. The default is arbitrary. You should get an exception for pow(0,0). I had forgotten that.
      Joshua: All the pown, powr, and pow say they return 1 without exceptions in IEEE.
      Jerome: I think some people wanted NaN since it is dangerous to say anything since 0, 1, or infinity are all valid.
      Jim: Kahan said you had to have 1 as anything else would cause problems.
      Jim: Now I'm thinking of leaving "mathematical function" as not fully defined.
      Jerome: My sense of IEEE is that they don't like the calculus idea of infinity, but more the computation based numerics. If there is no language in the C standard to talk about the mathematical domain that lurks behind everything, then it would be hard to introduce it without a lot of work. And instead talk about the computer arithmetic domain.
      Jim: The mathematics is definitely behind it. Like the discussion of poles, and log referring to the mathematical log functions.
      ^Jim/Jerome/Damian: Follow up on C26 issue 1.

  TS-4 and TS-5 revisions
    See [CFP 3015]
    Jim: For TS-4, the use of "consider" is not accepted by ISO. The example for scaled_proddiff, we can say "The following computes a fragment of the Clebsch-Gordan calculation as a simplified example." instead.
    Jim: For augmented arithmetic, an example has moved to 7.2. This makes it a more ISO conforming way of referring to the example.

  C26 issues
    Issues list
      See https://wiki.edg.com/pub/CFP/WebHome/C26C.HTM
      See [CFP 2992, 2994, 3003, 3005 and follow ups]
      Jim: CFP3003 should be added to the issues list.
      ^Fred: Add CFP3003 to the issues list.

      Jim: For CFP3006, Vincent has better words for inputs.
      Rajan: This would change the "correctly rounded" with respect to inputs.
      Jim: Yes, correct. We'd have to do that too.
      ^Jim: Draft up changes to incorporate CFP3006.

      Jim: Similar for CFP3007. This issue there is he is saying infinity is a floating-point number, but it is not, at least how we have defined it.
      ^Fred: Add CFP3007 to the C26 issues list.

      Issue 1: In progress (Jerome's item).
      Issue 3: Jim: I have this as no need for change and closed.
      Issue 4: Jim: Have a draft proposal for this. Action item.
      Issue 9: Jim: We decided we could close this.
      Issue 17: Jim: Have a draft proposal for this. Action item.

      Jim: Propose we look at 11 and 14 next.

    Imaginary types
      See [N3206, CFP 2979, CFP 2997 and follow ups]

    Annex G complex functions
      See [CFP 3018, 3019, 3032, and follow ups]
      Damian: Noticed some inconsistencies in Annex G.
      Damian: CFP3037 has a summary of inconsistencies that are mostly editorial.
      ^Damian: Get a list of editorial issues in Annex G and send them out for future submission to WG14.

  Others?

  Other issues
    IEEE 754 meetings
      Damian, David, Jerome, Mike are attending.
      Fred: IEEE explicitly asked for James Thomas for language input.

    Accuracy of mathematical functions
      See [CFP 3002]
      Fred: Not very good at setting the flags.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240313/92537089/attachment-0001.htm>