<html><body>
<p><tt>>Issue: Should _Binary128 be required? As an arithmetic type?<br>
>RESOLVED: Yes and Yes. However, questions remained about whether the <br>
>need would justify the cost.</tt><br>
<br>
Jim,<br>
I might have misspoken in the meeting about _Binary128. I tend to agree that it can be an arithmetic type, but I still have reservation that it be required (how about making it optional ?). The benefit may not justify the cost. Would it be ok if we still give agenda time for this issue in the next meeting ?<br>
Sorry about the churn.<br>
<br>
Thanks again.<br>
Regards,<br>
Raymond<br>
<br>
<font size="2" color="#800080">----- Forwarded by Raymond Mak/Toronto/IBM</font><font size="2" color="#800080"> on 01/08/10 10:13 PM</font><font size="2" color="#800080"> -----</font><br>
<br>
<br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">From:</font></td><td width="100%"><img width="1" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2">Jim Thomas <jwthomas@cup.hp.com></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">To:</font></td><td width="100%"><img width="1" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2">"cfp-interest@ucbtest.org" <cfp-interest@ucbtest.org></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Date:</font></td><td width="100%"><img width="1" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2">07/01/2010 08:11 PM</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Subject:</font></td><td width="100%"><img width="1" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2">[Cfp-interest] format - subgroup meeting 20100107 notes</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Sent by:</font></td><td width="100%"><img width="1" height="1" src="cid:1__=0ABBFC35DF8239AA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="2">cfp-interest-bounces@oakapple.net</font></td></tr>
</table>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt>Please send me any corrections or additions.<br>
<br>
-Jim<br>
<br>
*** Notes from Formats subgroup meeting 07 Jan 2010 ***<br>
<br>
Present were Mathew, Fred, Marius, Steve, Ian, Raymond, and Jim.<br>
<br>
Picking up from the last subgroup meeting, beginning at section 6, we <br>
complete a first pass through the Formats.htm paper posted on the <br>
Formats subgroup wiki page.<br>
<br>
6.1 Type-specific function names are needed, not just tgmath support. <br>
This fits the more usual C programming style and is necessary for taking <br>
the function addresses.<br>
<br>
Suffixes bNx are for 754-2008 extended binary types (dNx for decimal <br>
types), where N is the width of the basic type that the extended type <br>
extends. For example, expb64x() is a double extended function.<br>
<br>
6.2 Conversions with non-arithmetic (storage-only) interchange formats <br>
are supported by assignment (including casts, argument passing, and <br>
function return). This was deemed more convenient for users and what <br>
they'll expect, vs the alternative of conversion functions. Also, this <br>
avoids adding even more to the library interface.<br>
<br>
7. Usual arithmetic conversion for floating types will be specified so <br>
that promotion is to the floating type that is a superset of the other <br>
(for numeric data). If neither is a superset of the other, and both have <br>
the same radix, then the behavior is implementation defined. This rule <br>
will apply to 754 extended types and non-754 floating types, as well as <br>
754 interchange types.<br>
<br>
Then we went through the issues in the notes from our last meeting. We <br>
resolved some issues and opened a few more. RESOLVED, of course, does <br>
not mean final at this point and issues may be reopened as more effects <br>
comes to light.<br>
<br>
Issue: Add support for user remapping of float, double, and long double?<br>
RESOLVED: No. Need doesn't seem to justify the complexity for <br>
implementers and users.<br>
<br>
Issue: What type names to use? Alternatives:<br>
<br>
1 _BinaryN<br>
_DecimalN<br>
_BinaryN_Complex<br>
_DecimalN_Complex<br>
_BinaryN_Imaginary<br>
_DecimalN_Imaginary<br>
<br>
2 _FloatN<br>
_DecimalN<br>
_FloatN_Complex<br>
_DecimalN_Complex<br>
_FloatN_Imaginary<br>
_DecimalN_Imaginary<br>
<br>
3 _Real_BinaryN<br>
_Real_DecimalN<br>
_Complex_BinaryN<br>
_Complex_DecimalN<br>
_Imaginary_BinaryN<br>
_Imaginary_DecimalN<br>
<br>
With 1 and 3, macros are BINN_xxx (DECN_xxx) and suffixes are bN (dN).<br>
With 2, macros are FLTN_xxx (DECN_xxx) and suffixes are fN (dN).<br>
<br>
1 and 3 are parallel for binary and decimal<br>
1 and 2 match C decimal FP TR<br>
2 is less FP centric<br>
2 is more consistent with C legacy in use of Float vs Binary<br>
3 is parallel for type domains<br>
1 and 2 are more consistent with C legacy ordering of domain before <br>
associated real type<br>
3 is consistent in having width last<br>
<br>
No resolution. We need to look at some code using the different schemes.<br>
<br>
Issue: Do we need another category (other than xxx_IS_ARITH) for support <br>
of 754 Clause 5, but not<br>
full library support?<br>
RESOLVED: No. Need doesn't seem to justify another switch.<br>
<br>
Issue: Should _Binary128 be required? As an arithmetic type?<br>
RESOLVED: Yes and Yes. However, questions remained about whether the <br>
need would justify the cost.<br>
<br>
Issue: Should _Binary16 be required?<br>
RESOLVED: Yes, as a non-arithmetic (storage) type<br>
<br>
Noted: Macros and functions for the CFP API, as in other C TRs, will be <br>
under a "want" switch, in the spirit of __STDC_WANT_CFP__.<br>
<br>
Issue: How to provide I/O for the interchange types? Alternatives:<br>
1 With PRI and SCN macros, as in inttypes.h.<br>
2 With new width specifiers recognized by printf and scanf.<br>
3 With conversion functions, for each type, which take the format <br>
specifier string as an input argument.<br>
No resolution: More details needed.<br>
<br>
Issue: Do we need widest, fastest, or least types (analogous to stdint.h)?<br>
RESOLVED: No. Expected use doesn't seem to justify the addition API.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Cfp-interest mailing list<br>
Cfp-interest@oakapple.net<br>
</tt><tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a></tt><tt><br>
</tt><br>
<br>
</body></html>