[Cfp-interest] a term for float, double, and long double

[James W Thomas]

On Jun 3, 2013, at 10:23 AM, Ian McIntosh <ianm at ca.ibm.com> wrote:

> "Standard" has two meanings here.  Float, double and long double are required by the C standard, but not necessarily follow the IEEE 754 standard.  _Float32 and _Float64 are proposed to be in the C standard but not required by it, but are required by and defined by 754.
> 
> I don't really object to calling float, double and long double "standard real floating types" but it isn't ideal when they're standard in one way but not necessarily in the other.
> 
I agree, it's not ideal. Also, standard can mean "definitive" and the float, double, and long double types are less definitive than the 754 ones. On the other hand, standard can mean "garden variety", which is appropriate for float, double, and long double. I think the support for "standard" comes from wanting to follow the naming scheme for integer types that's already in the Standard. BTW, the standard integer types are less definitive than the exact-width integer types. 
> 
> Since they're required and the new ones aren't, how about "required real floating types"?
> 
It might be confusing because we would be requiring (albeit conditionally) real floating types that would not be "required real floating types". 

I don't think we'e going to find an ideal term. My sense is that "standard" will be more readily accepted by WG 14 (Fred and Rajan, what do you think?). Yet another approach would be to avoid adding a term to refer to the float, double, and long double types and just write "the float, double, and long double types" in all the places we now refer to the generic floating types. Part 2 use generic in a lot of places, but if there is strong feeling against "standard", I can try out the no-term approach.

-Jim
> 
> 
> If we were defining C from scratch I would strongly recommend distinguishing between conceptual versus implementation types.  A program may have many conceptual integer types, each referring to a different kind of thing - a part number, and employee number, am order number, a subscript in an array, and those should never be mixed.  Under them, their implementation types would be int, unsigned int, short, long, unsigned long long, char, etc. or even better int32_t etc. so you have easier control over their required size.  Those implementation types should never  be used except as the implementation of a conceptual type in a typedef (preferably a string or opaque typedef).  I've used that approach in an internal language and it makes code more readable and with a strong typedef helps detect bugs at compile time.  Defining each conceptual type in only one place also vastly simplifies portability.
> 
> For floating point, the conceptual types might be temperature, distance, angle, etc., and they each should be defined in one place to be some implementation type - either float, double or long double, or even better one of the 754 types so you have easier control over their required precision, range and size.  Each implementation should also define float, double and long double as a weak typedef to either one of the 754 types or to one of that implementation's nonstandard types (eg _CDC6600_60).
> 
> With that approach, I think the names of the groups of types would end up different again, and likely wouldn't have "standard" as part of their names.
> 
> - Ian McIntosh          IBM Canada Lab         Compiler Back End Support and Development
> 
> 
> <graycol.gif>James W Thomas ---05/31/2013 09:42:20 PM---On the question of a name (generic, general, traditional, classical, etc.) for the float, double, an
> 
> <ecblank.gif>
> From:
> <ecblank.gif>
> James W Thomas <jaswthomas at sbcglobal.net>
> <ecblank.gif>
> To:
> <ecblank.gif>
> CFP <cfp-interest at ucbtest.org>
> <ecblank.gif>
> Date:
> <ecblank.gif>
> 05/31/2013 09:42 PM
> <ecblank.gif>
> Subject:
> <ecblank.gif>
> Re: [Cfp-interest] a term for float, double, and long double
> <ecblank.gif>
> Sent by:
> <ecblank.gif>
> cfp-interest-bounces at oakapple.net
> 
> 
> 
> On the question of a name (generic, general, traditional, classical, etc.) for the float, double, and long double types, the two responses from WG 14 members stated a preference for "standard real floating types", to reflect the C naming model for integer types. I recall we didn't take that approach originally because we are proposing new types for the Standard (and shouldn't they be called "standard" too?). On second thought, since our new types are either conditionally normative or optional, it seems reasonable to have "standard" apply to the types the Standard requires of all implementations, and not to the types we're adding.
> 
> A second issue is whether "real" is needed as part of the name (for float, double, and long double), or would "standard floating types" be better. Since C11 made complex a conditionally normative feature, the types float, double, and long double are the only floating types the Standard now requires for all (hosted) implementations. If we did include "real" in the name, would we need to include it in the names of the new real floating types we'll be adding (decimal real floating types, etc.)? A minimalist scheme might be
> 
> real floating types
> standard floating types: float, double, long double
> decimal floating types: _Decimal32, _Decimal64, _Decimal128
> interchange floating types: _FloatN, _DecimalN
> extended floating types: _FloatNx, _DecimalNx
> 
> A modification that calls out IEC 60559 types might be
> 
> real floating types
> standard floating types: float, double, long double
> IEC 60559 floating types
> decimal floating types: _Decimal32, _Decimal64, _Decimal128
> IEC 60559 interchange floating types: _FloatN, _DecimalN
> IEC 60559 extended floating types: _FloatNx, _DecimalNx
> 
> where the IEC 60559 qualified types are introduced in Part 3.
> 
> Your thoughts?
> 
> -Jim
> 
> 
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
> 
> 
> 
> _______________________________________________
> 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/20130604/c7d300ee/attachment.html