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