[Cfp-interest] format - type names issue

[Jim Thomas]

Ian McIntosh wrote:

>
> I agree that "_Real" is redundant and would not be welcomed by most 
> programmers.  Also C TR1 already defines the decimal types as 
> _DecimalN and at least IBM and gcc have already implemented that. 

HP too.

> There are other options to consider.  One is similar to #3 but without 
> the "_Real":
>
> 4  _BinaryN
>     _DecimalN
>     _Complex_BinaryN
>     _Complex_DecimalN
>     _Imaginary_BinaryN
>     _Imaginary_DecimalN
>
> You can divide this into orthogonol decisions:
>         1. Do we use _Binary or _Float ?
>         2. Do we use _Real or omit it ?
>         3. Do we put  _Complex and _Imaginary first or last, or do we 
> omit _Binary or _Float when used with _Complex and _Imaginary ?  (a 3 
> way choice)
> which means there are 8 combinations.
>
> My preferences (subject to change after discussion) are:
>         1. Undecided, leaning towards _Float.
>                 I prefer _Binary because while _Float feels more 
> C-like, it could be confusing that _Float64 and _Float128 don't match 
> the precision of the typical float.

I don't think it would be confusing. It's like int16_t not matching int.

>                 I prefer _Binary because it matches IEEE better.
>                 I prefer _Float because _Binary doesn't imply floating 
> point as well as _Float does.
>                 Some might prefer _Float because it's one character 
> shorter.  I don't care about one character.
>         2. Omit it.
>                 _Real is redundant, would not be welcomed by most 
> programmers, and TR1 already defines the decimal types as _DecimalN.
>         3. _Complex and _Imaginary first.
>                 Adjectives normally precede nouns, and I think of 
> Complex and Imaginary as adjectives, and _Float, _Binary and _Decimal 
> as being closer by usage to being nouns.
>                 A C++ implementation using templates would have to use 
> Complex <_BinaryN> not _BinaryN <Complex>, etc.,
>                 because the template parameter must be an existing 
> type and the template name must not be..
>                 I think complex and imaginary are uncommon enough that 
> consistency wins over brevity.

Given that the existing names for imaginary and complex types have the 
associated real type first (e.g., float complex), it seems more 
consistent with C style to place _Complex and _Imaginary last.

-Jim

>
> That leads me to choice #6 (or maybe #10) of the 12 possible:
>
> *6  _FloatN*
> *    _DecimalN*
> *    _Complex_FloatN*
> *    _Complex_DecimalN*
> *    _Imaginary_FloatN*
> *    _Imaginary_DecimalN*
>
> 10 _FloatN
>     _DecimalN
>     _ComplexN
>     _Complex_DecimalN
>     _ImaginaryN
>     _Imaginary_DecimalN
>
> Yes, I omitted the other 6 types.  That's an exercise for somebody who 
> prefers one of them.     8<)
>
> - Ian McIntosh          IBM Canada Lab         Compiler Back End 
> Support and Development
>
>
>
> From: 	Jim Thomas <jwthomas at cup.hp.com>
> To: 	"cfp-interest at ucbtest.org" <cfp-interest at ucbtest.org>
> Date: 	02/02/2010 11:55 AM
> Subject: 	[Cfp-interest] format - type names issue
> Sent by: 	cfp-interest-bounces at oakapple.net
>
>
> ------------------------------------------------------------------------
>
>
>
>  >> 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
>
> 1 and 2 are more in the style of the existing C floating types. C
> doesn't qualify the names of floating types with "real". It's just float,
> not "real float" or "float real". The imaginary and complex types can be
> thought of as constructed from their corresponding real types, so it
> makes sense to explicitly name the domain for imaginary and complex but
> not for real. I'm unaware of any confusion caused by this naming approach.
>
> 99.9[...]% of programs and programmers will deal only with real types.
> Programmers wouldn't thank us for lengthening the names of the real
> types (as with 3):
>
> _Real_Binary256 fmab256 (_Real_Binary256, _Real_Binary256, 
> _Real_Binary256);
>
> vs
>
> _Float256 fmaf256 (_Float256, _Float256, _Float256);
>
> 3 is inconsistent with the existing C decimal FP TR (_Real_DecimalN vs
> _DecimalN). This would mean that current implementations of the TR would
> need to support two naming schemes for their decimal floating types.
>
> _FloatN is easily thought of as the binary floating type of width N. The
> existing C float type must be binary for Annex F (IEEE) implementations
> and is binary in almost all implementations. Existing implementations
> (including gcc) currently use __floatN to designate binary floating
> types (__float80, __float128). I'm unaware of any C history that would
> associate _BinaryN with floating point.
>
> I think this argues that 2 is the best choice.
>
> -Jim
>
>
>
>
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>
>