[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZorivAkDDZZEAc8k4sjGhFMCUGJc8YPznRgVkBcGWFH6AA@mail.gmail.com>
Date: Thu, 25 Jul 2024 12:08:23 -0400
From: enh <enh@...gle.com>
To: libc-coord@...ts.openwall.com
Subject: Re: #pragma STDC FENV_ACCESS ON
On Thu, Jul 25, 2024 at 11:06 AM Joseph Myers <josmyers@...hat.com> wrote:
>
> On Thu, 25 Jul 2024, enh wrote:
>
> > btw, see also https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2746r0.pdf
> > where the guy down the hall is suggesting that rather than copy
> > FENV_ACCESS into C++, C++ should just say "the <fenv.h> rounding mode
> > stuff is too broken --- let's replace it with _types_ that carry a
> > rounding mode".
>
> Rounding modes are logically a property of operations, not types (and in
> particular, for interval arithmetic you may want to do operations on the
> same value but with different rounding modes).
types is the best you're going to get in C++ though... unless you want
to forego operator overloading and have a Java BigInteger style of
api. (though as i've said, i don't see enough code that care to know
whether add_round_minus_infinity() would actually be a negative, or
seen as a positive for readability...)
> The FENV_ROUND pragma (in
> TS 18661-1 / C23), assigning a constant rounding direction to a region of
> source code, is better fitted to practical uses of rounding modes than
> dynamic rounding modes are (it's unfortunate that IEEE 754-1985 was rather
> influential in processors tending to support dynamic and not constant
> modes).
>
> --
> Joseph S. Myers
> josmyers@...hat.com
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
