[Cfp-interest 2718] Re: definition of "floating types"

[Vincent Lefevre]

On 2023-02-28 14:25:53 -0800, Jim Thomas wrote:
> > On Feb 28, 2023, at 9:33 AM, Vivian Van Loan <vanloanm at outlook.com> wrote:
> > 
> > Rajan and I were discussing it in the chat during the meeting and
> > came to a possible solution of "and for other values of
> > FLT_EVAL_METHOD, they are otherwise implementation-defined
> > floating types
> 
> This seems to require the _t types to be defined to
> implementation-defined types. An implementation might define
> FLT_EVAL_METHOD to -1 because it sometimes evaluates float to double
> and sometimes to float; the implementation should be able to define
> float_t to float or double.

Is the "evaluation format" associated with float (resp. double)
necessarily a fixed type?

For instance, with

  float f1, f2, f3, f4;

are f1 + f2 and f3 + f4 necessarily evaluated using the same type?
If not, ugly things may occur, such as what may be the evaluation
type of

  (f1 + f2) * (f3 + f4)

if this gives x86_extended_prec * double_double? There may be no types
as wide as both x86_extended_prec and double_double.

Similar issue (even when the type is fixed) with

  float f1, f2;
  double d1, d2;
  /* ... */
  (f1 + f2) * (d1 + d2);

IMHO, the standard should require that the evaluation format
associated with float be float_t, and similarly for double and
long double.

Would this break actual implementations?

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