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

[Jim Thomas]

> On Feb 6, 2023, at 2:12 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> I'm resending this mail since I think that Jim did not receive
> the version I sent on "Mon, 6 Feb 2023 10:47:17 +0100", due to
> an annoying default option of mailman. I suggest that you set
> "Avoid duplicate copies of messages?" to "No" (which means that
> you may receive duplicates, but no mail should be lost, and this
> would allow the list-reply feature of some mail software to work
> as expected).
> 
> About the messages I send to Jim, I always get an error like
> (AT&T has always been annoying, putting many legitimate addresses
> in their own RBL):
> 
> <jaswthomas at sbcglobal.net>: host al-ip4-mx-vip1.prodigy.net[144.160.235.143]
>    said: 553 5.3.0 alph735 DNSBL:ATTRBL 521< 155.133.131.76 >_is_blocked.For
>    assistance forward this error to abuse_rbl at abuse-att.net (in reply to MAIL
>    FROM command)
> 
> so that Jim receives neither the personal copy nor the copy sent to
> the list if "Avoid duplicate copies of messages?" is set to "Yes".

Vincent, thanks for following up on this. I had not seen the message.
> 
> On 2023-02-05 21:40:20 -0800, Jim Thomas wrote:
>>> On Feb 1, 2023, at 6:05 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
>>> 
>>> On 2023-01-31 20:45:29 +0000, Rajan Bhakta wrote:
>>>>   Definition of “floating types”
>>>>     See [Cep-interest 2654]
>>>>     Rajan: As long as float_t and double_t have to be standard floating types, then we are good and there is no contradiction since real floating types contains standard floating types.
>>>>     Fred: We should change float_t and double_t to be real floating types since right now they could be complex.
>>>>     Needs to be looked at further.
>>> 
>>> Yes, float_t and double_t should probably be real floating types,
>> 
>> Yes.
>> 
>>> but "real floating types" should properly be defined. In N3088,
>>> there is 6.2.5p14 saying
>>> 
>>> The standard floating types and the decimal floating types are
>>> collectively called the real floating types.
>>> 
>>> where "real floating types" is *not* in italics. So it looks like
>>> a definition, but it isn't really. This is confusing.
>> 
>> We can propose italicizing “real floating types” in 6.2.5 #14.
>> 
>>> BTW, there
>>> is also an issue with H.2.4 Classification of real floating types,
>>> in particular #6 ("real floating types are classified as follows"),
>>> which does not include float_t and double_t.
>> 
>> It does because float_t and double_t are real types. This was
>> assumed, and the change above makes it explicit.
> 
> I don't understand this answer. H.2.4p6 currently contains:
> 
> Thus, in this annex, real floating types are classified as follows:
>  — standard floating types, composed of float, double, long double;
>  — decimal floating types, composed of _DecimalN, _DecimalNx;
>  — binary floating types, composed of _FloatN, _FloatNx;
>  — interchange floating types, composed of _FloatN, _DecimalN; and,
>  — extended floating types, composed of _FloatNx, _DecimalNx.
> 
> But since it is proposed to make float_t and double_t real floating
> types, they should appear in their own item above.
> 
>>> 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. 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.” 

> 
> For instance, 6.3.1.8 starts with the rule
> 
>  If one operand has decimal floating type, the other operand shall
>  not have standard floating, complex, or imaginary type.
> 
> But float_t and double_t are not a "standard floating, complex,
> or imaginary type". So, they are currently allowed with a decimal
> floating type as the other operand. But since they are similar to
> the standard floating types (at least if FLT_EVAL_METHOD is 0, 1
> or 2), they should follow the same rules.
> 
> 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.

- 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