[Cfp-interest] WG14 IEEE 754-C binding meeting minutes 2013/11/13

Rajan Bhakta rbhakta at us.ibm.com
Wed Nov 13 12:17:50 PST 2013



2013/11/13, 12:00 EST:
  Attendees: Jim, Rajan, Fred, Mike, David, Marius, Ian, Walter Banks

  Old action items:
    Jim: Part 2: Paragraph 12 should have (+, -, * or /) -> (+, -, * and /)
- Done
    Jim: Part 2: Page 8: Line 1: "are distinct types from float" -> "are
distinct from the types float" - Done
    Jim: Part 2: Page 32: The - sign seems to be in a different font and
seems high. Try and make it look better. - Done
    Jim: Part 2: Page 46: Change to split the table above into two 4 line
chunks and use the individual rules per chunk. - Done
    Jim: Part 2: Binding DFP applicable clauses in Annex F tighter to C11.
Ex. Saying something like "An implementation that defines
__STDC_IEC_559_DFP__ shall conform to the specifications in clauses ... in
this annex" - Done
    Jim: Look into using the Wiki as a backup for the documents in Word
format. - Most current version has been put up. Keep this item open.
    All: Review Part 3. Comments via email. - Done
    All: Let Jim know of any changes to part 2 as soon as possible. - Done

  Next Meeting:
    December 12th, 2013, 12:00 EST, 9:00 PDT - Thursday
    Same teleconference number.

  New action items:
    Jim: Backup the documents in Word format. - Most current version has
been put up. Keep this item open.
      Current files: http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp1.docx
      Current files: http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp2.docx
      Current files: http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp3.docx
      Current files: http://wiki.edg.com/twiki/pub/CFP/WebHome/cfp4.docx
      Note: Should also keep versions that are equivalent to PDF's.
    Jim: Part 2: Will go with _Decimal32/64/128 ordering and Jim will
follow up with Joseph to see if he agrees.
    Jim: Part 2: Draft wording changes (based on Josephs email) regarding
decimal vs generic radix 10 static rounding mode and we will review.
    All: Part 2: A document will have to be delivered before the December
meeting so please watch emails and respond quickly.
    Jim: Part 1/2/3/4: Add a note regarding the a/b/c/... clause suffix
meaning and reasoning for parts 2 on (since 1 is in ballot). Also check to
see if this can be added in Part 1 as well.
    Jim: Part 3: Try to use the math symbols for ceiling and floor instead
of the words ceiling and floor.
    Jim: Part 4: Look for opportunities for shortening function lists by
removing suffixes.
    Jim: Part 4: Send a note to the IEEE-754 group to get review of the
draft from them.
    Jim: Part 4: Remove the bold N in 5.3 function lists.
    Jim: Part 4: Add in issue: We don't require conformance to part 3, and
don't say _FloatNx (for example) must follow Part 3 so the functions are
defined but are not the same as intended if an implemenatation has _FloatNx
types but not Part 3 based.
    Jim: Part 4: Pi functions: Drop the second "half-revolutions"
    Jim: Part 4: atan2pi: Flag the description wording as an issue.
    Jim: Part 4: atan2pi: Add in atan2pi has a domain error for both
arguments being zero.
    Jim: Part 4: log21p: Add in issue: It could be read as log 21 p instead
of log2 1p.
    Jim: Part 4: rsqrt: Need to add a domain error.
    Jim: Part 4: compoundn: Add an issue: Why is it not an long long int?

  Part 1:
    Sent off for ballot.
    Final ballot stage.
    If approved, it will be an official published ISO technical
specification.
    Ian: Can be considered for C14 (next C standard revision).
    Can only change very minor editorial things (ex. bullet point style).
    Document is in SCC (Canada) already, but not necessarily up for ballot
yet.

  Part 2:
    In WG14 review period. A step before the PDTS ballot (the first
ballot).
    A draft was sent to Joseph Myers (very productive reviewer) and has
commented on it. Jim has replied on the WG14 reflector.
      Arguing for ordering of symbols related to decimal. Ex.
_Decimal64/32/128 is our current order and he wants _Decimal32/64/128.
        Mike: 32 is not used and don't know any reason to use it. Use
128/64/32 instead.
        Rajan: Parallels double/float/long double, or use small to large to
allow adding new ones on later.
        Mike: Any ordering is better than unordered.
        *AI* Will go with _Decimal32/64/128 ordering and Jim will follow up
with Joseph to see if he agrees.
      Constant rounding mode table: Asking for a similar table for decimal,
new clarifications
        Rajan: FLT_RADIX 10: Need to make sure we agree on making it clear
which one takes precedence or make it implementation defined.
          Ex. Can be last one wins or it can be baised towards the
respective type. i.e. If both present, DEC -> Decimal if present, non-DEC
does standard if present
        Jim: An implementation may want to keep them separate even if the
radix is 10. For implementation reasons they may make them the same.
        Marius: For implementation I would think making them the same would
be worse.
        Jim: If standard control affects decimal types they would want the
opposite to be true too. Decimal control affects standard types.
        *AI* Jim to draft changes regarding the discussion above and we
will review.
    *AI* A document will have to be delivered before the December meeting
so please watch emails and respond quickly.

  Part 3:
    Fred: Order of functions based by subclause number in C11 and subgroups
are alphabetical. If we add new functions that will change subclause
numbers.
    Jim: We add letters to subclauses to avoid changing the numbers for
later subclauses. Ex. 6.7.1.2#11 we add in 6.7.1.2#11a.
    Mike: We could add a note describing why we are adding the a/b/c
numbering.
    *AI* Jim to add the note for parts 2 on (since 1 is in ballot). Also
check to see if this can be added in Part 1 as well.
    Fred: Why doesn't part 3 have the IEC_60559_TYPES with _EXT?
    Jim: Part 1 shows the required things based on Annex F. The WANT macro
is just an addition of identifiers for an extension. The programmer asks
for these explicitly. The implementaiton must support these.
    The goal is to have a WG14 review after the Spring 2014 meeting.
    Mike: It is good to have Part 2 well underway before working on Part 3.
    Jim: Part 2 should be available for ISO ballot next month.
    Jim: One of the most complicated parts due to the type system changes
and changes to part 1 and 2.
    Mike: Some guidance on where to focus the review would be helpful.
    Fred: ceil and ceiling issue: In C99 they use the mathematical symbol
(L, backwards L etc.) vs the words.
    *AI* Jim to try to use the math symbols for ceiling and floor instead
of the words ceiling and floor.
    Wording issue on page 20: Jim has talked to the C11 editor and is still
looking into it.

  Part 4:
    Mike: Long lists of functions can cause oversights and missed
functions. Perhaps group them using root names instead of listing them all.
    Jim: Following part 2 and part 3, so this change would affect those as
well.
    *AI* Jim to look for opportunities for shortening function lists by
removing suffixes.
    Jim: This part was more straightforward as it was basically just adding
functions so less interactions with other parts.
    Will need help getting the special cases stated correctly.
    *AI* Jim to send a note to the 754 group to get review from them.

    Overview:
      Is duplicating the intro section in all parts good?
        No sentiment to remove it.
      *AI* Remove the bold N in 5.3 function lists.

    Rajan: *AI* Issue: We don't require conformance to part 3, and don't
say _FloatNx (for example) must follow Part 3 so the functions are defined
but are not the same as intended if an implemenatation has _FloatNx types
but not Part 3 based.

    Pi functions:
      Fred: pg 5 ln 17: NaN is not in the interval but it shouldn't be a
domain error.
      Jim: Took it from text for acos directly from the C11 standard.
      Fred: Not sure what the half-revolutions means. First and second
instance.
      Jim: Took it from the description of the trig functions.
      David: The second one is redundant.
      *AI* Jim to drop the second "half-revolutions"

    atan2pi:
      Fred: Can't figure out what the functions do from the description.
      Jim: Using the 754 descriptions.
      David: Can say it is y/x divided by Pi in the right hand plane
mathematically.
      Jim: Can refer to the mathematical arctan function.
      Jim: There is no corresponding statement for that for atan2.
      *AI* Jim to flag the description wording as an issue.

      Fred: C11 says a domain error can occur if both arguments are zero.
      *AI* Jim to add in atan2pi has a domain error for both arguments
being zero.

    exp2m1:
      Fred: exp2m1(a large negative number) is not a range error.
      Jim: Same as above. The words are from the C11 function.

    log21p:
      Jim: 754 has log2p1. We already have log1p with the same description.
      *AI* Issue here since it could be read as log 21 p instead of log2
1p.

    rsqrt:
      *AI* Need to add a domain error.

    compoundn:
      Fred: Why are we using long int?
      Jim: This was from the earlier discussion we had.
      Ian: More instructions are needed for PPC hence long int is more
efficient.
      *AI* Jim to mark this as an issue as to why is it not an long long
int.

    Annex F changes:
      Please review carefully.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at us.ibm.com, Rajan Bhakta/Houston/IBM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20131113/f202f157/attachment-0001.html 


More information about the Cfp-interest mailing list