<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 12, 2013, at 8:21 AM, Rajan Bhakta <<a href="mailto:rbhakta@ca.ibm.com">rbhakta@ca.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><font size="2" face="sans-serif">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:</font>
<br>
<br><font size="2" face="sans-serif">I have four alternatives I'd like to
propose in order of preference for the quantexpdN and quantexpdNx functions:</font>
<br>
<br><font size="2" face="sans-serif">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.</font>
<br></blockquote><div><br></div>The quantum exponent for _Decimal256 exceeds int16 and for _Decimal512 exceeds int32. So it doesn't look like integer types will do.</div><div><br><blockquote type="cite">
<br><font size="2" face="sans-serif">2) Use a _DecimalN return type.</font>
<br><font size="2" face="sans-serif">int quantexpdN(_DecimalN x); -> _DecimalN
quantexpdN (_DecimalN x);</font>
<br><font size="2" face="sans-serif">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.</font>
<br></blockquote><div><br></div>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.</div><div><br><blockquote type="cite">
<br><font size="2" face="sans-serif">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):</font>
<br><font size="2" face="sans-serif">Ex. __DECIMAL1024_HAS_LARGE_QUANTUM_EXPONENT
quantexpd1024_returns_long</font>
<br></blockquote><div><br></div>Presumably the return type is a scalar type? Would need to specify the radix. Seems clunky (not that that always stops us).</div><div><br><blockquote type="cite">
<br><font size="2" face="sans-serif">4) Use int_leastN_t types where the
implementation has to define new int_leastN_t types.</font>
<br><font size="2" face="sans-serif">This has the drawback of having to potentially
introduce new int types (ex For _Decimal128 since not all implementations
have 128 bit integer types).</font>
<br></blockquote><div><br></div>See 1) above. </div><div><br></div><div>-Jim</div><div><br><blockquote type="cite">
<br><font size="2" face="sans-serif">Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: <a href="mailto:rbhakta@ca.ibm.com">rbhakta@ca.ibm.com</a>, Rajan Bhakta/Toronto/IBM<br>
Telephone: (905) 413-3995</font>
<br>
<br>
<br>
<table width="100%">
<tbody><tr valign="top">
<td><font size="1" color="#5f5f5f" face="sans-serif">From:</font>
</td><td><font size="1" face="sans-serif">Rajan Bhakta/Toronto/IBM@IBMCA</font>
</td></tr><tr valign="top">
<td><font size="1" color="#5f5f5f" face="sans-serif">To:</font>
</td><td><font size="1" face="sans-serif">CFP <<a href="mailto:cfp-interest@ucbtest.org">cfp-interest@ucbtest.org</a>>,
</font>
</td></tr><tr valign="top">
<td><font size="1" color="#5f5f5f" face="sans-serif">Date:</font>
</td><td><font size="1" face="sans-serif">04/11/2013 03:07 PM</font>
</td></tr><tr valign="top">
<td><font size="1" color="#5f5f5f" face="sans-serif">Subject:</font>
</td><td><font size="1" face="sans-serif">[Cfp-interest] Meeting minutes for 2013/04/11
C FP Study Group</font>
</td></tr><tr valign="top">
<td><font size="1" color="#5f5f5f" face="sans-serif">Sent by:</font>
</td><td><font size="1" face="sans-serif"><a href="mailto:cfp-interest-bounces@oakapple.net">cfp-interest-bounces@oakapple.net</a></font></td></tr></tbody></table>
<br>
<hr noshade="">
<br>
<br>
<br><font size="2" face="sans-serif">Attendees: Fred, Jim, Marius, Ian, David</font><font size="3">
<br>
</font><font size="2" face="sans-serif"><br>
Old action items:</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Jim to post spreadsheet: Done</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Jim to check if a new WG14 document number is needed: Yes. Done</font><font size="3">
</font><font size="2" face="sans-serif"><br>
Ian and Rajan to review intro: Good as it is. Done</font><font size="3">
</font><font size="2" face="sans-serif"><br>
Jim to describe more changes: Done</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
Next meeting: May 16th, 2013</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
New action items:</font><font size="3"> </font><font size="2" face="sans-serif"><br>
AI: Jim to check with David to go back to old conference number</font><font size="3">
</font><font size="2" face="sans-serif"><br>
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.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
AI: Jim to send new words for Part 1 comment 17.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
AI: Jim to send new words for Part 1 comment 25.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
AI: Everyone to review Part 2 to make sure it is ready for full
official WG14 review</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
Discussion:</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Fred: Have we resolved how we are working as a subgroup of WG14?
Two wikis for example.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Jim: Not going very well since he is still doing double posting.
Awkward situation.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Rajan: Is Secure C doing this? They seem to be doing their own on
the side without too much WG14 impact.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Fred: Prefer keeping this separate</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
Part 1 comments:</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Jim: Proposed new text is what the comment submitter posted. John
Benito suggested we add a column for our response.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
Comment from Willem Walker: Change all "Suggested changes to
C11" to "Changes to C11" in our document. Consensus is to
make the change.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Comment from Joeseph Myers regarding Table 2 and wchar functions
and atof. Consensus is to make the change.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Spreadsheet comments and consensus:</font><font size="3"> </font><font size="2" face="sans-serif"><br>
1-2: Make the changes</font><font size="3"> </font><font size="2" face="sans-serif"><br>
3: Remove first line only</font><font size="3"> </font><font size="2" face="sans-serif"><br>
4: No main doc changes</font><font size="3"> </font><font size="2" face="sans-serif"><br>
5: Remove the second instance.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
6: Fred: Reorder the 5 section for all 3 documents.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
7: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
8 (wprintf, wscanf): Accept changes.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
9: Discussion about how to format. Decided on round dark
bullets and no punctuation.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
10: Accept changes. Change line number to 24 in the comment.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
11 (log function typeface): Accept changes.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
12: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
13: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
14: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
15: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
16: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
17 (llogb): Need to reword this. AI for Jim to do.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
18: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
19: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
20: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
21: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
22 (real floating): Rajan: math.h so shouldn't have complex.
Jim: Consistent with others if we do not accept complex. Accept changes.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
23: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
24 (four macros vs three): Accept changes.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
25: David: Need a way to find out if it is signalling without
signalling.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Jim: Wide evaluation is the issue. <br>
David: Should only apply to variables, not expressions.
<br>
Jim: Works for variables and expressions generally.
<br>
David: Add a reference to F.3. <br>
Fred: How about F.3#5? <br>
Jim: The standard never references paragraph numbers.
<br>
AI: Jim to show the words of the F.3 reference being
a footnote.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
26: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
27 (imput): Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
28: Accept changes. Add parenthesis for clarity as well.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
29: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
30: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
31 (old): Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
32: Accept changes.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
33: Accept changes except the line 25 change. Also remove
the bold and typeface of "and" on line 11.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
<br>
Part 2 review:</font><font size="3"> </font><font size="2" face="sans-serif"><br>
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.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
Example 3 on page 29: Output is in "e" format now.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
Jim: A number of other editorial changes made.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
<br>
Part 3:</font><font size="3"> </font><font size="2" face="sans-serif"><br>
This Spring 2013 meeting will be the first time the full WG14 will
see Part 3.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
This means we need Part 4 draft for early September to get into
the October mailing.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
The changes to the type system is risky so needs to be looked at
closely.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Issue: quantexpd* functions may have the exponent > INT_MAX so
the return type would not work (overflow)</font><font size="3"> </font><font size="2" face="sans-serif"><br>
*I can send a note suggesting _DecimalN as the return type</font><font size="3">
</font><font size="2" face="sans-serif"><br>
Type generic should be looked at still.</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: <a href="mailto:rbhakta@ca.ibm.com">rbhakta@ca.ibm.com</a>, Rajan Bhakta/Toronto/IBM<br>
Telephone: (905) 413-3995</font><tt><font size="2">_______________________________________________<br>
Cfp-interest mailing list<br>
<a href="mailto:Cfp-interest@oakapple.net">Cfp-interest@oakapple.net</a><br>
</font></tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><tt><font size="2">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</font></tt></a><tt><font size="2"><br>
</font></tt>
<br>
<br>_______________________________________________<br>Cfp-interest mailing list<br><a href="mailto:Cfp-interest@oakapple.net">Cfp-interest@oakapple.net</a><br>http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br></blockquote></div><br></body></html>