[Cfp-interest] format - subgroup meeting 20100107 notes

[Jim Thomas]

Raymond Mak wrote:

> >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 ?
>
Yes, we can give this agenda time in the next subgroup teleconference.
-Jim

> 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
>
>