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

[Vincent Lefevre]

On 2023-03-01 20:58:57 -0800, Jim Thomas wrote:
> On Mar 1, 2023, at 8:39 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
> > 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?
> 
> Maybe yes. In the past, there were implementations that evaluated
> expressions in wider registers but (when they ran out of registers)
> stored intermediate values into narrower storage formats.

However, a narrower storage format, e.g. float, could be regarded as
the evaluation format (e.g. double), but with a reduced accuracy of
the operation (as the accuracy is implementation-defined). With an
x86 processor, this is similar to an operation performed on double
but where the processor is configured to round in single precision
(even though no float type is involved).

> Requiring what you suggest would be a substantive change. Would a
> recommendation be helpful?

I'm not sure what could be recommended.

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