[Cfp-interest] WG14 CFP Study group meeting minutes for the meeting on 2013/05/16

[Rajan Bhakta]

  Attendees: Ian, Jim, Fred, David, Mike, Marius, Rajan
 
  Last meeting action item: F.3 as a footnote - Done
    Email sent on April 12th, 2013
  Next meeting: June 13th, 2013, 12:00 EST, 9:00 AM PDT
    Continuing with the Oracle teleconference number
 
  Action items:
    *AI*: Formatting and reference changes made to part 1 have to be made 
to part 2
    *AI*: Jim to send an email to WG14 asking for the one term change of 
"generic" to "traditional". Can also list the terms we rejected.
    *AI*: Mike to respond to Jim's reset email
 
  Next C pre-meeting mailing is September 2nd, 2013
    We need to have any documents we want to be discussed at the C meeting 
in the mailing at that time
 
  Part 1:
    Made all changes from the comments submitted + some other other 
editorial ones that were found
    The final changed version has been posted on the Wiki (n1711)
    First ISO ballot (3 month) will be on that document
      We will need to respond to comments on that ballot
 
  Part 2:
    Comment by Willem regarding changes made to Annex F by all the parts 
being confusing
    Jim sent messages regarding minimal changes in part 2 and part 3 to 
Annex F so this does not seem to be too much of a problem
    *AI*: Formatting and reference changes made to part 1 have to be made 
to part 2
 
    Rajan's "quantum exponent return type" email comments:
      Fred: Why not use long long?
      Jim: _Decimal1024 would be larger than int64. We'd still have a 
built in limitation
      Jim: Prefers option 2, though it wouldn't work for extended types 
for large exp vs significands. We could make this a limitation on extended 
types
      Jim: Also not compatible to the decimal TR
      Rajan: Maybe allow the base cases (32, 64, 128) with int return 
types, and option 2 for larger types
      Mike: Or a new name for the option 2 types with the basic ones (32, 
64, 128) staying the same as the TR so the common case is fast and easy to 
implement and the new name for all types including extended ones. We may 
want to review other functions to see if they can return a decimal type if 
int is constraining it
      Choose Option 2 with the mod suggested by Mike.
        Naming: Look at precedence like ilogb for something like 
dquantexpdN
 
  Part 3:
    The term interchange type caused a lot of confusion in the committee
      Sentiment was not to have types for interchange encodings, 
especially with the similar names like _FloatN (with _Float16 as a special 
case)
    Mike: Data only types are not really fitting from the C point of view
    Ian: I disagree with having _Float16 as a mandatory type. Very few 
groups have hardware _Float16
    Marius: Intel supports _Float16 to some extent on 3rd gen Cores, 
limited to store now, with _Float32 evaluation
    Jim: We can come back to _Float16
    Mike: Do we want to make the arithmetic vs non-arithmetic distinction 
in C?
    Rajan: Can we remove non-arithmetic types?
    *AI*: Mike to respond to Jim's reset email
    Jim's "reset part 3" email comments:
      5) generic -> general
      "general" could mean any floating point type
      How about classic, traditional, standard, basic floating?
      We could just not use the term and list the types wherever we have 
generic
      *AI*: Jim to send an email to WG14 asking for the one term change of 
"generic" to "traditional". Can also list the terms we rejected.
      Can we not make an allowance of float32/64 being float/double and 
macro definition of the functions to allow the "traditional" type 
functions to be used (can be done for extended types as well)
        Would not work with constant rounding modes and macro suppression
      Require the new types, but allow #defines, or make them optional to 
simplify Part 3, or keep it the way it is with the encoding change?

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at ca.ibm.com, Rajan Bhakta/Toronto/IBM
Telephone: (905) 413-3995
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130516/5ad521f3/attachment-0001.html