[Cfp-interest] WG14 IEEE 754-C binding meeting minutes 2017/02/28

[Rajan Bhakta]

2017/02/28, 12:00 EST:
  Attendees: Rajan, Jim, David C., Mike, Marius, Fred, David H.

  New agenda items:
    None.

  Last meeting action items:
    All: Review the posted proposals (on CFP wiki with date 2016/09/01) by 
next meeting as it is the last one before the Markham mailing. - Done.
    Jim: DRS2: DDR7: Look to see if there is a simpler way of showing the 
change. - Done (2017/02/20 email).
    Rajan: DRS2: DDR9: Add code examples for implementers to test out and 
send it out via email. - Done.
    Jim: DRS2: DDR2: Write a paper with this text 
(DECIMAL_DIG_obsolescence.pdf) for WG14. - Done.
    Jim: Make SC22WG14.14586 a proposal for C2X. - Done.
    Jim: Respond to Joseph's comments on SC22WG14.14586, SC22WG14.14587 
via WG14 reflector. - Done.

  New action items:
    Rajan: Submit DRS2:DDR9 example as a paper for a supplement to the STC 
in the DR and change all the %A to %a (ensuring it conforms to the 
specification for %a).
    Jim: Create a DR against part 2 to specify the capitalization effects 
of %a.
    Jim: DRs2:DDR2: DECIMAL_DIG: Have DECIMAL_DIG to be the largest 
supported floating type as a new replacement Suggested TC for DRs2:DDR2.
    Jim: Add in the encoding *_DIG macros (as per 
http://wiki.edg.com/pub/CFP/WebHome/characteristics_for_non-arith_formats.pdf
) and obsolescing DECIMAL_DIG as a proposal to WG14 as a new enhancement.
    Jim: Include Type-generic macros for functions that round result to 
narrower type as part of the third set of DR's.
    Fred: Propose adding in #pragma STDC FENV_ROUND DEFAULT as a means to 
set the static rounding mode to the default rounding mode.

  Next Meeting:
    Tuesday March 21st, 2017, 12:00 EDT, 9:00 PST
    Same teleconference number.

  Discussion:
    IEEE 754 revision:
      Next meeting will be the last one for any substantive changes.
      min/max: Not reflective of NaNs. Can have them as most important or 
least important. Recommendations so won't break anyone.
      We will need to name it too somehow.

    C++ liaison:
      Ian not present.
 
    What should be proposed for the C standard (C2X):
      Part 3 is one proposal. Extended, interchange, and support for 
interchange formats. Can split it up if needed.
        Keep it as one proposal, but mention it can be split up if needed.
      Part 4 is two proposals: transcendental functions and reduction 
functions.
        Keep it as two proposals.
        Jim: Is 754's thinking changing with regards to the reduction 
functions?
          David H: Been talked about due to vectorization but leaving it 
as is since it is too big an item to handle right now.
          Jim: Should we lower the priority or not push for this due to 
the expected future changes?
          David H: How stringent things are about exceptions is likely to 
change. The basic functionality should be the same and shouldn't contract 
but may be enhanced.
      Part 5 is 4 proposals: Expression evaluation, optimization, 
reproducibility, alternate exception handling
        Leave it as is.
        Jim: The alternate exception handling has a natural split on ones 
that change control flow.
          The ones that don't change control flow are fairly 
straightforward, so may be easier to pass since less invention.
      We do have a reputation of being flexible so it should not be a 
problem about doing parts and not others.
      We have draft documents for everything and prior art.
      2017/02/02 email for proposal for C2X for FE_TONEARESTFROMZERO 
rounding direction (
http://wiki.edg.com/pub/CFP/WebHome/C2x_proposal_-_FE_TONEARESTFROMZERO.pdf
)
        Go ahead with the proposal.
 
    DRs:
      Discuss suggestion in Jim’s Feb 20 email “simplify DRs2:DDR7”
        Jim: Should be non-substantive change in part 2, but not sure. 
This means the part 3 tgmath will rely on the usual arithmetic 
conversions.
        Treat this as a new paper for a new simpler suggested TC for DDR7 
so the committee has a choice on which TC to take.
 
      Follow-up on DRs2:DDR9 a-style formatting not IEC 60559 conformant. 
        See code examples in Rajan’s Jan 24 email “Examples to add for 
Defect report set 2, Draft defect report 9”.
        Fred: Change return 55 to return 0.
        *Rajan: Submit this as a paper for a supplement to the TC in the 
DR.
 
      Discuss Jim’s Jan 24 email “RE: Examples to add for Defect report 
set 2, Draft defect report 9” about effect of %a vs %A for decimal.
        *Jim: Should we create a DR against part 2 to specify the 
capitalization effects?
          Yes.
        Rajan: Check the specification now to make sure the example 
conforms to what is currently specified.
 
      Discuss DRs2:DDR2. See Jim’s Feb 1 email “AI: DECIMAL_DIG 
obsolescence” and Joseph Myers’s Feb 20 email “Re: (SC22WG14.14602) N2108 
and 18661-3 definition of DECIMAL_DIG”. See also Ian’s Jan 20 email “Re: 
AI: proposal to obsolesce DECIMAL_DIG”.
        Due to the encoding functions, we need a size to allow buffers for 
non-arithmetic types.
        Even with 
http://wiki.edg.com/pub/CFP/WebHome/characteristics_for_non-arith_formats.pdf 
we need to make DECIMAL_DIG equivalent to LDBL_DECIMAL_DIG or maybe just 
make it the largest supported floating type (Ian's suggestion).
        *Jim: DECIMAL_DIG: Have DECIMAL_DIG to be the largest supported 
floating type as a new replacement Suggested TC for DRs2:DDR2.
        *Jim: Add in the encoding *_DIG macros (as per 
http://wiki.edg.com/pub/CFP/WebHome/characteristics_for_non-arith_formats.pdf
) and obsolescing DECIMAL_DIG as a proposal to WG14 as a new enhancement.
 
      Discuss DRs3:DDR2 Type-generic macros for functions that round 
result to narrower type.
        See posted DDRs3-20170121.pdf.
        *Jim: Include Type-generic macros for functions that round result 
to narrower type as part of the third set of DR's.
 
      Discuss suggestion in Fred’s Feb 22 email “Part 1: FENV_ROUND 
DEFAULT”.
        Sounds good for non IEEE floating point types.
        *Fred: Propose adding in #pragma STDC FENV_ROUND DEFAULT as a 
means to set the static rounding mode to the default rounding mode.

    Other:
      None.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20170228/70592c3c/attachment.html