[Cfp-interest] format - type names issue

[Ian McIntosh]

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

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


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