[Cfp-interest] format - subgroup meeting 20100107 notes

[Jim Thomas]

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.