[Cfp-interest 2709] Re: WG14 IEEE 754-C binding meeting minutes 2023/01/31

[Jim Thomas]

> On Feb 9, 2023, at 4:48 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> On 2023-02-06 12:25:25 -0800, Jim Thomas wrote:
>>>>> Note that at least 6.3.1.8 "Usual arithmetic conversions" needs to
>>>>> be updated to take that into account (and H.4 too?).
>>>> 
>>>> Why? They are intended to have the behavior of the real type they
>>>> are defined to be.
>> 
>> Some clarification may well be needed, but I think the *_t types are
>> intended to defined (as if) by typedef.
> 
> Not always. This is what the GNU C library does:
> 
> $ printf "#include <math.h>\ndouble_t\n" | gcc -E -xc - | grep double_t
> typedef double double_t;
> double_t
> 
> But...
> 
>> 6.7.8 says "A typedef declaration does not introduce a new type,
>> only a synonym for the type so specified.” They are synonyms for the
>> real types they are defined to be. This is reflected in their
>> specification with the standard evaluation methods, e.g. "If
>> FLT_EVAL_METHOD equals 0, float_t and double_t are float and double,
>> respectively.”
> 
> This is well-defined in 7.12 when FLT_EVAL_METHOD is 0, 1 or 2.
> Otherwise, they may be entirely new types.

One interpretation might be: yes, they may be extension types but those must be extension real types, as with the interchange types in Annex H. 

This wouldn’t allow evaluation to internal formats that weren’t supported as extension real types, e.g. formats with extra exponent range that might be available in the hardware. To allow that sort of evaluation, maybe the _t types should just be types with the qualification that if they are not real floating types their behavior is implementation-defined.

> 
>>> BTW, 7.12 "Mathematics <math.h>" says about these types:
>>> "floating types at least as wide as float and double", where "real"
>>> will be added. However, "as wide as" has not been defined, AFAIK.
>>> IMHO, it should be required that these types have the same radix
>>> (this is important if FLT_EVAL_METHOD is not 0, 1 or 2, since they
>>> are implementation-defined) and the requirement should be about
>>> the "range and precision" as for FLT_EVAL_METHOD in 5.2.4.2.2.
>> 
>> The intended meaning of type A is wider than type B is that the
>> values of A are a superset of the values of B and A has greater
>> range and/or precision than B. It’s used this way in other places in
>> the standard, e.g. 7.6.2 #4 has "(including the conversion of a
>> value represented in a format wider than its semantic types to its
>> semantic type …)” and 7.12.3.1 #2 has "an argument represented in a
>> format wider than its semantic type is converted to its semantic
>> type.” A clear statement of meaning would be good, but I believe it
>> is generally understood as intended.
> 
> I think that I saw some discussions about the exact meaning, and this
> was not completely obvious (in particular if a normal value can become
> a non-normal one in a "wider" type). So I'm wondering whether there
> should be a definition in Clause 3.
> 
> Moreover, this could mean that in practice, double-double and binary64
> could not be supported at the same time due to the lack of a widest
> floating type, as required by the standard (I would not expect a
> double-binary64 format to be implemented in practice).

Good point. Would a definition requiring just inclusion work? That would be:  type A is wider than type B iff the values of A are a superset of the values of B. Then double-double would be wider than binary64, even though binary64 has the greater exponent range (for full precision of the types). Are there places where use of the wider type terminology depends on wider exponent range? 

I agree a definition is needed.

- Jim Thomas

> 
> -- 
> Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest