[Cfp-interest 2591] Re: Floating point rounding modes

[Hans Boehm]

On Thu, Jan 5, 2023 at 12:47 AM Paul Zimmermann <Paul.Zimmermann at inria.fr>
wrote:

>        Dear Hans,
>
> > From: Hans Boehm <boehm at acm.org>
> > Date: Wed, 4 Jan 2023 11:08:22 -0800
> >
> > [I'm not sure whether this will reach cfp-interest; feel free to forward
> if
> > not. ]
> >
> > Disclaimer: I have no confidence in my ability to design an API here that
> > would actually make it through the various C++ subcommittees. Hence the
> > vague nature of the initial proposal. My plan is to have the next
> revision
> > contain a more specific syntax proposal. But:
> >
> > The simplest acceptable (to me) proposal would be to change the above to:
> >
> >    double x, y;
> >    y = cr_sin_explicit(x, FE_TOWARDZERO);
> >
> > (This uses the atomics-inspired _explicit syntax to get around the
> absence
> > of overloading. That's not great, but there is a precedent.)
> >
> > At least in C++, I think there are reasons to do something a bit more
> > elaborate. There may also be reasons not to, especially based on C
> > compatibility.
> >
> > Does C23 have a way to specify rounding of decimal constants to binary
> > floating point? My impression was no. I think that's another usability
> > obstacle that should be addressed if we really want to make directed
> > rounding usable to get a bound on the true result.
>
> as far as I know, the answer is no. Indeed something like
> double x = 0.1downward would be nice. The workaround is to use
> strtod() assuming it is correctly rounded and evaluated at compile time
> (is it?). Setting x = 0.1 after fesetround (FE_UPWARD) does not seem to
> work (I just tried with gcc).
>
> > My concern with this kind of syntax in a C++ context is that it's rather
> > easy to accidentally mix in an operation or conversion that does not obey
> > the intended rounding rules. That's why the current strawman C++ proposal
> > instead introduces a new type. With that approach. the C syntax might
> look
> > more like
> >
> >    cr_double x, y;
> >    y = sin_explicit(x, FE_TOWARDZERO);
> >
> > or perhaps just
> >
> >    cr_double x, y;
> >    y = sin(x, FE_TOWARDZERO);
> >
> > A major goal here is really to make the value of floating point
> expressions
> > independent of the context in which they appear. That problem showed up
> in
> > the constexpr discussions this morning.
>
> if I follow your proposal, we should do the same for basic arithmetic
> operations for coherence:
>
>    double x, y, z;
>    z = cr_add_explicit (x, y, FE_TOWARDZERO);
>
> If you disallow the current writing z = x + y, C programs will become
> very difficult to read!
>
I would argue for continuing to allow the operators for cr_double et al.,
at least of all operands are of the same type. If you do that, you would
always get round-to-nearest. cr_add() and the like would require a rounding
mode, so "_explicit" may not be required.

In the explicit rounding mode case, I agree the syntax is not beautiful. On
the other hand, for an isolated instance, in the best (AFAICT, not yet
implemented?) case, I think we currently have something like:

{
  #pragma STDC FENV_ROUND FE_TOWARDZERO;
  z = x + y;
}

I would prefer

z = cr_add (x, y, FE_TOWARDZERO);

unless lots of consecutive operations use the same rounding mode, for which
I haven't seen a particularly strong use case.


> Best regards,
> Paul
>
> PS: I didn't see anything about this topic in the notes of the meeting
> yesterday.
>
> The issue that came up yesterday was constexpr floating point expressions.
They're precisely what raised this issue in C++. "Constant" floating point
expressions are not really constant, since their value currently depends on
the rounding mode.

When I had to leave, the conclusion seemed to be to restrict floating point
constexpr initializers to those for which each subexpression produces an
exact result. That's probably fine for C23, but based on C++ trends, I
don't think it will stick. Explicitly passed rounding modes would fix the
problem in a much more realistic way. Also note that we're penalizing
constexpr, a very useful facility that's used everywhere in C++, for
non-standard floating-point rounding modes, which appear to be very rarely
used, at least in any code base that I've seen. (I did use them ages ago,
so I agree that they are occasionally needed.)

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230105/00d9f576/attachment.htm>