[Cfp-interest 1320] WG14 IEEE 754-C binding meeting minutes 2019/05/21

Tue May 21 10:13:37 PDT 2019

2019/05/21: 10:00 CST:
  Attendees: Rajan, Jim, Mike, Blaine, David H, 

  New agenda items:
    None.

  Carry over action items:
    All: Review the rationale for part 5 a, b, c proposal. - Carry over.
    Fred: Create papers for the SNAN initialization and unary + operation 
as CFP papers (CFP 1249, 1253, 1247, 1250) for future submission to WG14. 
- Carry over.
 
  Last meeting action items:
    Ian: Forward message from Hubert about FLT_EVAL_METHOD, etc. - Done.
    Jim: Post the IEEE 2019 draft for the CFP group on the wiki. - Done 
(see 4/25 note).
    Jim: Ensure that the quantum exponents table defines dN sufficiently 
in C2X. - Carry over (review next draft).
    Jim: Get an N number for CFP1277 and submit it. - Done.
    Jim: Get an N number for CFP1282 as a proposal and submit it. - Done 
(CFP review).
 
  New action items:
    Jim: Investigate creating our own CFP compendium.
    Fred: Give a new version of the SNAN initialization paper (as per 
CFP1316).
    Jim: Point out to Jens that we're using two spellings for analog in 
the current C2X draft.
    Jim: Look into the commas needed in the 
why_no_wide_string_strfrom_functions document, then get a document number 
and submit it.
    Jim: Keep Rounding of negated constants on the agenda to discuss for 
next meeting.
    Jim: Keep fesetexcept on the agenda to discuss for next meeting when 
Fred is present.
 
  Next Meeting(s):
    Wednesday, June 26th, 2019, 11:00 EST, 8:00 PST, 4PM UTC
    Same teleconference number.
    Please notify the group if this time slot does not work (note the new 
day).

  Discussion:
    754 revision:
      See CFP 1317.
      Draft 50 is the technical content that will go forward.
 
    C++ Liaison:
      None.

    WG14 meeting (April 29th-May 3rd):
      CR process going forward, with Blaine Garst.
        See CFP 1318 (Blaine’s email forwarded by Jim).
        Jim: The review cycle is not too short. It is good. Also us taking 
over the the compendium is reasonable. A lot of what we had is in C2X, so 
any changes to parts 1-4a will go through the C2X process. Our compendium 
will be very small now. I liked the meeting history in the original 
compendium. I will keep that.
        Jim: Currently CR's come with some suggested change, rather than 
questions.
        Blaine: We're not clear yet as a committee. I don't think the 
compendium should carry normative content forward. The editors can make 
the changes directly. Still need to work out the process.
        Jim: I currently put changes into my editors draft as soon as we 
have a CR/DR. Nothing goes out until it is closed.
        Mike: Often have to go back and make changes to text people want 
in immediately.
        Blaine: Having the committee agree to the words makes this much 
easier.
        *AI*: Jim: Investigate creating our own CFP compendium.

      See CFP 1309.
        N2323 will have a new N document (N2379) that doesn't talk about 
operations which was what was voted in as direction.
        N2326: Jim: I think there is a blurring of value and 
representation. Instead of normalized it should be normal number. It has a 
value of some normalized form in the model. I think this needs some more 
thought.
 
    C2X integration:
      Part 1 – Integration completed.
      Part 2 – Integration mostly done.
      Part 3 – Expecting N2342 is sufficient for the WG14 editors.
      Part 4a – We need to work on something to give to the WG14 editors 
for integration into C2X.
      Part 5a,b,c,d – Considering new proposals for a,b,c

  Action item details:
    Fred: Create papers for the SNAN initialization and unary + operation 
as CFP papers (CFP 1249, 1253, 1247, 1250) for future submission to WG14.
      See Tydeman’s CFP 1290. Jim’s CFP 1316.
      *AI*: Fred: Give a new version of the SNAN initialization paper (as 
per CFP1316).

    All: Review the rationale for part 5 a, b, c proposal.
      http://wiki.edg.com/pub/CFP/WebHome/n2120.pdf, 
http://wiki.edg.com/pub/CFP/WebHome/n2121.pdf, 
http://wiki.edg.com/pub/CFP/WebHome/n2122.pdf

    Ian: Forward message from Hubert about FLT_EVAL_METHOD, etc. See Ian’s 
CFP 1287.
      Jim: Seems C++ takes C FLT_EVAL_METHOD.

    Jim: Ensure that the quantum exponents table defines dN sufficiently 
in C2X.
      Jim: Jens wanted to use or refer to the macros in tgmath, and I 
wanted to avoid referring to tgmath. This will be an item for the next 
meeting.

    Jim: Get an N number for CFP1277 and submit it.
      http://wiki.edg.com/pub/CFP/WebHome/n2384.pdf

    Jim: Get an N number for CFP1282 as a proposal and submit it (possibly 
after CFP review?).
      http://wiki.edg.com/pub/CFP/WebHome/C2x_proposal_- 
_why_no_wide_string_strfrom_functions.pdf
      Mike: Slight editorial comment: Should avoid spellings that have one 
side identical to the other.
      *AI*: Point out to Jens that we're using two spellings for analog in 
the current C2X draft.
      Mike: Should be a comma after the etc. at the end too.
      *AI*: Jim: Look into the commas needed in the 
why_no_wide_string_strfrom_functions document.

  Other issues
    Rounding of negated floating-point constants under FENV_ROUND pragma.
      See Jim’s CFP 1314 and Mike’s 5/14 reply.
      Jim: Same issue if you add more digits to the constant.
      Mike: Not really.
      Jim: In C the negation is an operator, not part of the constant.
      Matters for +inf or -inf rounding, which is different from what 
strtod or scarf would do.
      Mike: They would have to know but programmers do have a choice with 
this.
      Jim: Could be done with parenthesis around the constant too.
      Mike: It is an issue for unary + as well.
      Jim: It shouldn't be. This is only for unary -.
      Jim: C doesn't have any way of representing negative values as a 
constant.
      *AI*: Jim: Keep Rounding of negated constants on the agenda to 
discuss for next meeting.

    fesetexcept and optional inexact
      See CFP email thread “fesetexcept() and optional inexact”
      *AI*: Jim: Keep fesetexcept on the agenda to discuss for next 
meeting when Fred is present.

    Fred’s WG 14 papers:
      See WG14 email thread “N2380: printf of NaN()”
      Jim: The sign of the NaN is also not portable across 
implementations.
      Mike: This sounds like the most non-problem I can think of.
        Existing portable code already has to deal with this along with 
all other implementation defined behavior.
      Jim: 60559 has payloads being implementation specific. No goal of 
making them portable, the opposite in fact.
      Mike/Rajan: This can be done portably now with output to a sprintf 
buffer and processing the NaN string.
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20190521/0264cbec/attachment-0001.html