[Cfp-interest] Meeting minutes for 2013/04/11 C FP Study Group
James W Thomas
jaswthomas at sbcglobal.net
Wed May 15 09:53:37 PDT 2013
On Apr 12, 2013, at 8:21 AM, Rajan Bhakta <rbhakta at ca.ibm.com> wrote:
> I left in a private note (the *'d part) in the notes I sent out yesterday. Please ignore that line since I'll elaborate here:
>
> I have four alternatives I'd like to propose in order of preference for the quantexpdN and quantexpdNx functions:
>
> 1) For the common (and likely only) cases where int is large enough, leave it as is. i.e. We explicitly list the "too large for int" case as unspecified what the implementation does.
The quantum exponent for _Decimal256 exceeds int16 and for _Decimal512 exceeds int32. So it doesn't look like integer types will do.
>
> 2) Use a _DecimalN return type.
> int quantexpdN(_DecimalN x); -> _DecimalN quantexpdN (_DecimalN x);
> The _DecimalN return value would be a canonical value. The hope is that larger N values will give larger ranges in the return value automatically and there is no need to introduce new types.
I like this. Although extended types could have arbitrarily large range, I believe the likelihood of a commercial extended type that is not able to represent its quantum exponents is small enough that we could leave that case implementation defined. The down side of this approach is incompatibility with the decimal TR. We could use a different function name.
>
> 3) Have the implementation define a macro for extended types if the exponent is out of range of an int with the value of a function name that can handle the larger types (and no macro defined for ones that fit in int):
> Ex. __DECIMAL1024_HAS_LARGE_QUANTUM_EXPONENT quantexpd1024_returns_long
Presumably the return type is a scalar type? Would need to specify the radix. Seems clunky (not that that always stops us).
>
> 4) Use int_leastN_t types where the implementation has to define new int_leastN_t types.
> This has the drawback of having to potentially introduce new int types (ex For _Decimal128 since not all implementations have 128 bit integer types).
See 1) above.
-Jim
>
> 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
>
>
> From: Rajan Bhakta/Toronto/IBM at IBMCA
> To: CFP <cfp-interest at ucbtest.org>,
> Date: 04/11/2013 03:07 PM
> Subject: [Cfp-interest] Meeting minutes for 2013/04/11 C FP Study Group
> Sent by: cfp-interest-bounces at oakapple.net
>
>
>
>
> Attendees: Fred, Jim, Marius, Ian, David
>
> Old action items:
> Jim to post spreadsheet: Done
> Jim to check if a new WG14 document number is needed: Yes. Done
> Ian and Rajan to review intro: Good as it is. Done
> Jim to describe more changes: Done
>
> Next meeting: May 16th, 2013
>
> New action items:
> AI: Jim to check with David to go back to old conference number
> AI: Jim to send out an email to see if 12:30-2:30 pm EST (30 minutes earlier than the original time) is OK for time - Consensus to do this on the call so no email needed.
> AI: Jim to send new words for Part 1 comment 17.
> AI: Jim to send new words for Part 1 comment 25.
> AI: Everyone to review Part 2 to make sure it is ready for full official WG14 review
>
> Discussion:
> Fred: Have we resolved how we are working as a subgroup of WG14? Two wikis for example.
> Jim: Not going very well since he is still doing double posting. Awkward situation.
> Rajan: Is Secure C doing this? They seem to be doing their own on the side without too much WG14 impact.
> Fred: Prefer keeping this separate
>
> Part 1 comments:
> Jim: Proposed new text is what the comment submitter posted. John Benito suggested we add a column for our response.
> Comment from Willem Walker: Change all "Suggested changes to C11" to "Changes to C11" in our document. Consensus is to make the change.
> Comment from Joeseph Myers regarding Table 2 and wchar functions and atof. Consensus is to make the change.
> Spreadsheet comments and consensus:
> 1-2: Make the changes
> 3: Remove first line only
> 4: No main doc changes
> 5: Remove the second instance.
> 6: Fred: Reorder the 5 section for all 3 documents.
> Accept changes.
> 7: Accept changes.
> 8 (wprintf, wscanf): Accept changes.
> 9: Discussion about how to format. Decided on round dark bullets and no punctuation.
> 10: Accept changes. Change line number to 24 in the comment.
> 11 (log function typeface): Accept changes.
> 12: Accept changes.
> 13: Accept changes.
> 14: Accept changes.
> 15: Accept changes.
> 16: Accept changes.
> 17 (llogb): Need to reword this. AI for Jim to do.
> 18: Accept changes.
> 19: Accept changes.
> 20: Accept changes.
> 21: Accept changes.
> 22 (real floating): Rajan: math.h so shouldn't have complex. Jim: Consistent with others if we do not accept complex. Accept changes.
> 23: Accept changes.
> 24 (four macros vs three): Accept changes.
> 25: David: Need a way to find out if it is signalling without signalling.
> Jim: Wide evaluation is the issue.
> David: Should only apply to variables, not expressions.
> Jim: Works for variables and expressions generally.
> David: Add a reference to F.3.
> Fred: How about F.3#5?
> Jim: The standard never references paragraph numbers.
> AI: Jim to show the words of the F.3 reference being a footnote.
> 26: Accept changes.
> 27 (imput): Accept changes.
> 28: Accept changes. Add parenthesis for clarity as well.
> 29: Accept changes.
> 30: Accept changes.
> 31 (old): Accept changes.
> 32: Accept changes.
> 33: Accept changes except the line 25 change. Also remove the bold and typeface of "and" on line 11.
>
> Part 2 review:
> Jim: I want to make this follow Part 1 by one WG14 meeting. This means we can have a WG14 review in May or June for this.
> Example 3 on page 29: Output is in "e" format now.
> Jim: A number of other editorial changes made.
>
> Part 3:
> This Spring 2013 meeting will be the first time the full WG14 will see Part 3.
> This means we need Part 4 draft for early September to get into the October mailing.
> The changes to the type system is risky so needs to be looked at closely.
> Issue: quantexpd* functions may have the exponent > INT_MAX so the return type would not work (overflow)
> *I can send a note suggesting _DecimalN as the return type
> Type generic should be looked at still.
>
> 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_______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>
>
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130515/b15ec481/attachment.html
More information about the Cfp-interest
mailing list