[Cfp-interest] Reminder and Re: Reset for TS 18661 Part 3?

[James W Thomas]

Remember, today's teleconference begins at 9:30 AM PDT.

More stewing about the reset for Part 3 and the encodings described below …

IEC 60559 requires initialization (as well as conversions) for encodings. One approach would be to add initialization functions that take character sequence arguments, like strtod. (This wouldn't cover signaling NaNs, unless we added a symbol.) IEC 60559 doesn't say initializers must represent all values of the encoding, but that was probably intended.

A possible simplification would be to specify the IEC 60559 floating types only for optional extensions. Make _Float128 distinct from long double and optional (even if long double uses the binary128 format). Make other _FloatN types be distinct types and optional. Make extended types be distinct types and optional. This approach reduce the size of the interface, but would not so well support models of portable programming with the new types.

With the minimalist approach above, what encodings would be required? All decimal floating types would require encodings, in order to handle re-encoding. Such encodings already have their requisite functionality through the corresponding types. But they might need the functions anyway for consistency  with other encodings. Should we require encodingf16? encodingf128? Would we also need encodings for the existing binary types? Or for just the optional extension types (so that support for _FloatN or _DecimalN implies support for the corresponding encodings)?

-Jim

On May 11, 2013, at 4:50 PM, James W Thomas <jaswthomas at sbcglobal.net> wrote:

> 
> 
> Begin forwarded message:
> 
>> From: James W Thomas <jaswthomas at sbcglobal.net>
>> Subject: Reset for TS 18661 Part 3?
>> Date: May 11, 2013 4:49:42 PM PDT
>> To: SC22 WG14 <sc22wg14 at open-std.org>
>> 
>> 
>> At the WG 14 meeting in Delft, TS 18661 Part 3 met with confusion and concern about data-interchange types vs interchange floating types. Why are they named the same (_FloatN, _DecimalN)? Why are data-interchange types named _FloatN when they aren’t floating types? Why do non-arithmetic interchange formats need types at all? Following is an outline of a different approach to supporting the IEC 60559 non-arithmetic interchange formats, intended to address these issues. We will discuss this approach at the May 16 CFP teleconference. Email discussion beforehand is encouraged, especially from WG14 members who were at Delft.
>> 
>> - Jim Thomas
>>  
>> 1. Replace data-interchange types with data-interchange encodings. (We already have these for decimal.)
>>  
>> Typedef names:
>> encodingfN_t
>> decencodingdN_t
>> binencodingdN_t
>> represent encodings for IEC 60559 interchange formats
>> If Part 1 …
>> Required for binary: encodingfN_t for N = 16, 32, 64, and 128
>> Optional for binary: encodingfN_t for N > 128 and a multiple of 32
>> If Part 2 …
>> Required for decimal: decencodingdN_t and binencodingdN_t for N = 32, 64, 128
>> Optional for decimal: decencodingdN_t and binencodingdN_t for N = 96 and for N > 128 and a multiple of 32
>>  
>> 2. Rename interchange floating types to IEC 60559 interchange floating types. (Yes, this still has “interchange” in the name, but I don’t know what else to call them that wouldn’t be a serious mismatch with IEC 60559 terminology. Note that item 4 below means the use of this term would be limited.)
>>  
>> Types (as now):
>> _FloatN
>> _DecimalN
>> provide IEC 60559 arithmetic interchange formats
>> If Part 1 …
>> Required for binary: _FloatN, N = 32, 64
>> Optional for binary: N = 16 and N >= 128 and a multiple of 32
>> If _FloatN is supported, so shall be encodingfN_t.
>> If Part 2 …
>> Required for decimal: _DecimalN, N = 32, 64, 128
>> Optional for decimal: N = 96 and N > 128 and a multiple of 32
>> If _DecimalN is supported, so shall be decencodingdN_t and binencodingdN_t
>>  
>> 3. Rename extended floating types to IEC 60559 extended floating types.
>>  
>> Types (as now):
>> _FloatNx
>> _DecimalNx
>> provide IEC 60559 (arithmetic) extended formats
>> If Part 1 …
>> Required for binary: N = 32
>> Optional for binary: N = 64, 128
>> If Part 2 …
>> Required for decimal: N = 32, 64
>> Optional for decimal: N = 128
>>  
>> 4. Define: the IEC 60559 interchange floating types and the IEC 60559 extended floating types are collectively referred to as IEC 60559 floating types.
>>  
>> 5. Rename generic floating types to general floating types (in Parts 2 and 3). This is intended to address committee concern about different meanings of the term “generic”.
>>  
>> 6. Define: the general floating types and IEC 60559 floating types are collectively called the real floating types.
>>  
>> 7. Do not provide classification and totalOrder operations for the encodings. We currently have classification macros and totalorder functions for all the data-interchange types, but for non-arithmetic formats these operations are only recommended in IEC 60559, not required. If the functionality is desirable, we could include it (interfaces TBD) in Part 4 (Supplementary functions).
>>  
>> 8. Provide functions for all the IEC 60559 required mappings to and from the encodings. Here’s where this approach might seem cumbersome. IEC 60559 requires formatOf operations (conversions) between all its floating-point formats (which incudes arithmetic and non-arithmetic). Thus we might have something like
>>  
>> void srcTypeAbbrtodstTypeAbbr(const srcType * x, dstType * y);
>>  
>> where srcTypeAbbr (srcType) is one of:
>> encfM (encodingfM_t), decencdM decencodingdM_t), binencdM (binencodingdM_t)
>>  
>> and dstTypeAbbr (dstType) is one of:
>> encfN (encodingfN_t), decencdN (decencdoingdN_t), binencdN (binencodingdN_t), fN (_FloatN), fNx (_FloatNx), dN (_DecimalN), dNx (_DecimalNx)
>>  
>> and where srcTypeAbbr is one of:
>> fM (_FloatM), fMx (_FloatMx), dM (_DecimalM), dMx (_DecimalMx)
>>  
>> and dstTypeAbbr is one of:
>> encfN (encodingfN_t), decencdN (decencdoingdN_t), binencdN (binencodingdN_t)
>>  
>> Conversions among the arithmetic types are still done by assignment, cast, etc.
>>  
>>  
>>  
>>  
>>  
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130516/df72611f/attachment.html