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

[Vincent Lefevre]

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.

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.

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